【譯】.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 的熱度還有待觀察。

 

原文做者：Lex Li

原文地址：The Story About .NET Cross Platform UI Frameworks

 

擴展閱讀

應用程序開發: Cordova vs React Native vs Xamarin vs DIY