.NET 跨平台介面架構和為什麼你首先要考慮再三

標籤：developer   git   archive   蘋果   log   gis   平台   linux   最好   

???原文地址

現在用 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 開發這個技術，最開始是為了跨平台行動裝置 App，但是最近它已經開始走向案頭情境，比如 macOS（WPF 和 GTK# 的整合也在開發中）。

和完全自己繪製技術不同的是，Xamarin.Forms 程式在設計時使用的是抽象控制項。設計時的按鈕、列表等控制項，到運行時會映射到作業系統原生的按鈕、列表等控制項上。所以從顯示效果來看，這是最好的一項技術。

更為重要的是，Xamarin.Forms 新版本已經支援直接嵌入原生控制項，也支援原生程式嵌入 Xamarin.Forms 介面，為開發人員帶來更多的靈活性。

但是這個技術暫時也是有局限的，就是它的控制項都還是為行動裝置 App設計。假如你的目標是設計一個 Office 或者 Visual Studio 那樣的標準案頭應用，那麼就會遇到困難。好在也不是所有情境我們都需要那麼複雜的介面。

現在已經有很多第三方為 Xamarin.Forms 提供控制項：

• ComponentOne
• Telerik
• Synfusion
• Infragistics
• DevExpress

越來越多三方的加入也使得這個技術更加活躍。

xwt/Eto.Forms

設計思想：原生控制項映射。

作業系統：案頭（開始嘗試移動支援）

顯示效果：總是和原生系統深度整合

三方控制項：暫時不多

這兩個技術都和 Xamarin.Forms 相似，但是它們都是從案頭平台開始的。

xwt 官方網站 是 Mono 項目的一部分。我個人認為它啟發了 Xamarin.Forms 的設計。Eto.Forms 官方網站 相對比較新，而且開始進入移動平台。

這兩個架構會不會最後到達 Xamarin.Forms 的熱度還有待觀察。?

翻譯原文

.NET 跨平台介面架構和為什麼你首先要考慮再三