.NET 跨平台界面框架和为什么你首先要考虑再三

​​​原文地址

现在用 C# 来开发​跨平台应用已经有很成熟的方案，即共用非界面代码，而每个操作系统搭配特定的用户界面代码。这个方案的好处是可以直接使用操作系统原生的控件和第三方控件，还能够和操作系统深度集成。

这里的深度集成主要是指一些 Windows 专有的系统特性：

• Windows 托盘
• Windows 跳转列表
• Windows 系统主题

也包括一些移动平台的特性，例如 iOS 的原生滑动。

​由于操作系统上其他程序一般都使用原生控件，于是只有当你的程序采用同样技术时，它才能很好地保持一致。这是一个大家一般遵守的界面开发约定。苹果公司有详细的界面设计准则，供开发者参考。

游戏程序一般全屏，也不需要遵守这个约定。其他程序，例如 RealPlayer、QQ，也是违背这种约定。个人观点是，尽量不要搞特殊化。

​因此如果你决定采用这个方案，那么在不同的操作系统上你需要学习不同的界面框架：

• Windows：Windows Forms *
• macOS：Xamarin.Mac（封装 Cocoa） **
• Linux：GTK#（封装 GTK+）***
• iOS：Xamarin.iOS（封装 CocoaTouch）
• Android：Xamarin.Android（封装 Android UI)

值得注意的是：

* Windows 平台正在经历整体界面设计的变化，未来标准的界面框架应该是 UWP。WPF 虽然也是微软官方支持的技术，但是和 WinForms 相比，它依然是自己绘制，算不上原生界面框架。

​** MonoMac 因为各种原因已经废弃 参见。

*** QtSharp 等框架都不太成熟。

​市场上很多成功的项目都是这个方案的受益者。下面举几个例子：

• 国家仪器的 LabView 官方网站 在 iOS 平台使用 Xamarin.iOS 移动版地址，在 Windows 平台使用 Windows Forms（这个不是特别确定）。
• Plastic SCM 官方网站 在 Linux 平台使用 GTK#，在macOS 使用 Xamarin.Mac，而在 Windows 上使用 Windows Forms。
• iCircuit 官方网站 在 macOS 使用 Xamarin.Mac，在 iOS 使用 Xamarin.iOS，在 Android 使用 Xamarin.Android，在 Windows 和 Windows Phone 上使用微软的技术。

不过总有程序员希望能够使用跨平台界面框架，来简化自己的工作。所以这篇文章也介绍一些业已存在的跨平台界面框架，以供参考。它们虽然各不相同，但是大体都使用了下面三种设计思想中的一个：

• 控件完全自己绘制，在不同操作系统上模拟系统控件的效果。
• 在某个操作系统上是原生框架，在其他操作系统上通过模拟实现显示。
• 设计时抽象，运行时映射到原生控件。

Unity/MonoGame

设计思想：完全自己绘制（不过没有什么标准控件概念）

操作系统：桌面和移动设备（还包括游戏终端等）

显示效果：和操作系统没关系

三方控件：谈不上

这两个都是游戏引擎。非要用它们来设计跨平台应用技术上是可行的，但是因为没有操作系统控件之类的东西，完全需要自己绘制，所以开发非游戏应用，难度还是有的。至于和操作系统深度集成，就更加麻烦。

GTK#

设计思想：在 Linux 上是原生框架，在其他操作系统上也能模拟运行。

操作系统：桌面

显示效果：Linux 上深度集成

三方控件：有一些，但没有非常活跃的提供商

GTK 本来就是一个针对桌面程序开发的跨平台界面框架，所以 GTK# 封装之后也是很好用的。然而，它在非 Linux 操作系统上的显示效果是很差的（比如 Windows 上和系统主题很不搭）。

MonoDevelop 是采用 GTK# 的 IDE。当微软/Xamarin 将它改造为 Visual Studio for Mac 时，很多界面部分就已经换成了系统原生的 Xamarin.Mac 了。

​Windows Forms

​设计思想：在 Windows 上是原生框架，在其他操作系统上也能模拟运行。

操作系统：桌面

显示效果：Windows 上深度集成

这是绝大部分 C# 程序员入门时学习的界面框架，能够快速集成 Windows 各种控件。虽然也支持 Windows CE 移动平台，但是基本没什么用。Mono 从2.0版本开始将它迁移到 Linux 等操作系统。Plastic SCM 最初也是使用 Mono Windows Forms 将自己的 Windows 客户端迁移到其他操作系统。但是 Mono 的实现在很多细节上并不完美，还需要很大精力去改进。Plastic SCM 后期就放弃了跨平台 Windows Forms 这条路。

​Windows Forms 在 Windows 平台拥有大量第三方控件，而这些控件基本都不支持 Linux 等操作系统。尽管最近微软开始将 System.Drawing 变成一个跨平台技术，也使得官方的 Windows Forms 有可能成为一个跨平台界面方案，但是在非 Windows 平台的显示效果如何抑或是三方市场会不会跟随都还未知。

最为重要的是 Windows Forms 本来就是为桌面设计，它没法很好的支持移动平台。早在 MonoTouch 最初开发阶段，Mono 团队就有想过将 Windows Forms 变成 iOS 平台的界面框架 相关文章。当然，最后他们很明智地放弃了这个想法，而是采用了封装 Cocoa Touch 的原生方案。

WPF/Avalonia/UWP

设计思想：完全自己绘制。

操作系统：桌面（UWP 支持 Windows 移动版，Avalonia 有移动支持）

显示效果：Windows 上深度集成

三方控件：Windows 平台很多

WPF 和 UWP 都是微软官方的技术，而 Avalonia 官方网站尝试将类似的设计变成一个跨平台的技术。

Delphi 有一个非常像 WPF 的界面框架 FireMonkey，已经完全跨平台（桌面和移动设备），所以 WPF 相关技术想跨平台技术上是完全可行的，但是挑战也是很多的。

虽然微软想了很多办法来改进 WPF 和系统的集成（包括多套主题），但是它始终不能像 Windows Forms 那样原生显示。当然从 Windows 10 开始，微软干脆用 UWP​ 来开发系统自带的程序，这样 UWP 最后还是会成为原生框架的。

Xamarin.Forms

设计思想：原生控件映射。

操作系统：移动平台（开始尝试桌面支持）

显示效果：总是和原生系统深度集成

三方控件：快速发展中

Xamarin 开发这个技术，最开始是为了跨平台移动应用，但是最近它已经开始走向桌面场景，比如 macOS（WPF 和 GTK# 的集成也在开发中）。

和完全自己绘制技术不同的是，Xamarin.Forms 程序在设计时使用的是抽象控件。设计时的按钮、列表等控件，到运行时会映射到操作系统原生的按钮、列表等控件上。所以从显示效果来看，这是最好的一项技术。

更为重要的是，Xamarin.Forms 新版本已经支持直接嵌入原生控件，也支持原生程序嵌入 Xamarin.Forms 界面，为开发者带来更多的灵活性。

但是这个技术暂时也是有局限的，就是它的控件都还是为移动应用设计。假如你的目标是设计一个 Office 或者 Visual Studio 那样的标准桌面应用，那么就会遇到困难。好在也不是所有场景我们都需要那么复杂的界面。

现在已经有很多第三方为 Xamarin.Forms 提供控件：

• ComponentOne
• Telerik
• Synfusion
• Infragistics
• DevExpress

越来越多三方的加入也使得这个技术更加活跃。

xwt/Eto.Forms

设计思想：原生控件映射。

操作系统：桌面（开始尝试移动支持）

显示效果：总是和原生系统深度集成

三方控件：暂时不多

这两个技术都和 Xamarin.Forms 相似，但是它们都是从桌面平台开始的。

xwt 官方网站 是 Mono 项目的一部分。我个人认为它启发了 Xamarin.Forms 的设计。Eto.Forms 官方网站 相对比较新，而且开始进入移动平台。

这两个框架会不会最后到达 Xamarin.Forms 的热度还有待观察。​

翻译原文