C# XAML-based UI framework 桌面軟件開發觀察

做者本人是一個在 linux 和 mac 平臺的軟件開發者 (而非 Win 平臺的軟件開發者)，同時 對 Win 平臺的 GUI 組件包 有所瞭解 (WinForms, WPF)、對 linux 上的 GUI 組件包 (GUI toolkits) 有所瞭解 (包括 QT, GTK, Delphi)，藉由對於 C# (CLI 的 C# 實現) 和 GUI 圖形庫 的興趣，結合 C# 在 linux 平臺的歷史(mono, WinForms, GTK#, Avalonia)，來探索出一條 C# 語言支持的 linux 桌面軟件-原生跨平臺-的開發辦法 (GTK#, Xamarin, Avalonia)，同時 試圖從微軟官方的 .NET 發展方向 (現代桌面軟件開發辦法：XAML-based + 代碼堆砌；.NET 平臺：.NET core) 上，獲得 最適合 linux 和 mac 的、原生跨平臺 的桌面軟件開發辦法。

執念：
高權重：桌面軟件 (而非服務器軟件)
高權重：標記語言佈局技術 (文本標記語言 declarative programming) (而非純代碼堆砌)
高權重：微軟官方長期支持 (而非不受微軟官方支持的)
高權重：C# 語言 (CLI 的 C# 實現) (而非其餘語言)
高權重：GUI 組件包 的 目的 (是 原生跨平臺，好比 GTK ，而非 把某一個平臺做爲一等公民、其它平臺做爲二等公民 對待)
高權重：GUI 組件包 的 成熟度

中權重：GUI 組件包 的 目的。最初目的是原生跨平臺 的 GUI 組件包 (而非 最初目的是僅針對某一個平臺(做爲第一公民)然後開放給其餘平臺的 桌面軟件開發辦法)
中權重：源代碼級別的跨平臺，軟件的源代碼 能夠在 另外一個平臺 編譯運行 (而非 須要所有重寫) [1]()
中權重：對於所謂的 某公司專有的 UI Framework (好比 蘋果公司的 Cocoa, Cocoa Touch; 微軟公司的 WinForms, WPF ) 持謹慎態度 (由於它們在定義 UI 的同時也定義了 UI 組件的通訊方式、APP 的生命週期等 獨佔性細節：若是你採用它的 UI Framework 了，那麼你對於 APP 生命週期這麼基本的東西 都要從新學習，這是很大的學習成本 [1]() 2。而節省學習成本的辦法，就是用一層 wrapper (讓 wrapper 自己去處理和 UI Framework 的通訊) (那麼 只要這個 wrapper 能夠適配到各個 UI Framework 那麼 開發者學了它就能夠少學不少東西). )

非執念：
低權重：社區驅動 (活躍但太新 未受到微軟官方支持 等因而 野路子，好比 Avalonia, picoe/Eto, XWT; Flutter Electron )
低權重：現有 Win 平臺桌面軟件的代碼重用性 (等因而 歷史包袱)

https://en.wikipedia.org/wiki...
https://en.wikipedia.org/wiki...
https://en.wikipedia.org/wiki...
https://www.cnblogs.com/leoli...

有欺騙性的文章
https://www.hanselman.com/blo...
爲何它有欺騙性？由於它隻字不提 Xamarin

https://news.ycombinator.com/...
爲何它有欺騙性？由於它隻字不提 Xamarin ，並且大大宣傳所謂的繼承 WPF 精神 的 Avalonia ，並且，它人數衆多

https://www.reddit.com/r/dotn...
爲何它有欺騙性？由於它人數衆多，並且 這種問法十分自做聰明 「What would a cross-platform .NET UI Framework look like? Exploring Avalonia」 由於它在暗示 C#開發者在 Avalonia 出現以前 就沒有 跨平臺的 .NET UI 庫了 而 Avalonia 是第一個跨平臺庫，是 linux-WPF，是救世主 (然而並非。都是 Xamarin 玩剩下的)。好在有人提出了 微軟在 .NET Conf 2017 的時候 就已經給出了跨平臺軟件的推薦辦法：Xamarin

注意幾我的：
騙子陣容：

• Scott Hanselman (.NET Core 核心開發之一，可是 面對跨平臺軟件解決方案卻隻字不提 Xamarin ，供職微軟)(極具欺騙性 提出各類開源 GUI 組件庫的假想 還扯 GTK# 扯 Avalonia ，懂裝不懂？彷佛在刻意討好開源軟件社區，同時大大低估(或但願別人大大低估)作出 一個跨平臺 GUI 組件包 (QT, GTK 等) 的難度)

好人陣營：

• Miguel de Icaza (mono 和 Xamarin 的開創者，目前供職微軟)
• David Ortinau (Xamarin 核心開發之一，瞭解 原生跨平臺 GUI 組件包的實現難度 )
• https://www.dotnetconf.net/ag...

TL;DR

支持利用平臺特定的功能，如 Windows 上的 Windows Forms 和 WPF ，以及 Xamarin 系的特定平臺支持：經過 Xamarin 實現各個平臺的原生支持
Support for leveraging platform-specific capabilities, such as Windows Forms and WPF on Windows and the native bindings to each native platform from Xamarin.

這就是微軟的跨平臺軟件解決方案：Xamarin.

=

幾個事實和事實釋放出來的信號：

MS .NET Standard 實現方面：
可看做受到微軟官方支持的 C# SDK 。三個主流 .NET Standard 實現 是 mono, .NET Framework, .NET Core
1 .NET Core (活躍期：2016-) 是 MS 強推薦的 .NET Standard 實現，目的是 取代 .NET Framework (已初步進入冷藏期)

1.1 這種取代關係的目的，僅限於在 Win 平臺
1.2 MS 在 dnc 3 推出的 WPF, Winforms (System.Windows.Forms) 支持，也僅僅在 Win 平臺 1
1.2.1 Winforms 和 WPF 各執本身的桌面軟件開發辦法
1.2.2 Winforms 背後 是 純代碼堆砌 UI (相似 Java Swing, 它是純代碼堆砌 UI) ，WPF 背後 是 標記語言佈局技術 + 代碼堆砌 UI (相似 Java JavaFX, 它用到了 FXML ：使用 XML 呈現UI)
1.2.3 一樣是 標記語言實現 UI 佈局，WPF 使用 XAML ，JavaFX 使用 XML
1.2.4 XAML-based UI 的開發實現，它的實現有 WPF 、Avalonia 、Xamarin Forms 等
1.2.4.1 XAML-based UI 的 平臺性：在 linux 和 mac 平臺，WPF 暫不可用 ( dnc 不支持，mono 不支持)，Avalonia 可用 (活躍期：2018- 1)

-

2 mono 做爲一個 .NET Standard 實現 (活躍期：2005-2016 1)，用於 把.NET 應用程序移植到 Linux 1 )

2.1 mono 的完備性：1 C# 編譯器、JIT 編譯器、Runtime、.NET 類庫實現 (Winforms (System.Windows.Forms))、可視化開發工具和調試器 (MonoDevelop) 。
2.1.1 爭議: Mono (建立者 Miguel de Icaza，Xamarin 公司，在 mono 活躍開發期 並不受到微軟官方支持) 是不是一個跨平臺的 .NET 實現 1。爭議的理由是：mono 和 .NET Framework 在語言級別上，都是 CLI 的一種實現，後者 是 CLI 的超集，由於 CLI 自己僅僅有 C# 語言特性 它自己不涉及是否跨平臺，沒有定義特定的 GUI 組件庫 (GUI 組件庫 一般是 「平臺敏感」 的，除非 明確說明 是 爲跨平臺而生(好比 GTK, QT, Delphi, Electron 1, 以及 Xamarin Forms )的，它們可被視做 「原生跨平臺(並不會對哪個平臺有偏向)」 )。
2.1.1.1 原生跨平臺 的 GUI 組件庫：GTK, QT, Delphi, Electron, Xamarin Forms, Java Swing, JavaFX
2.1.1.2 非原生跨平臺 的 GUI 組件庫：WinForms, WPF, Cocoa, etc.
2.1.1.3 原生跨平臺 的 GUI 組件庫 + 標記語言實現 UI 佈局：GTK(XML), QT(QML), Delphi, Electron(HTML), Xamarin Forms (XAML), JavaFX(XML)
2.1.1.4 原生跨平臺 的 GUI 組件庫 + 標記語言實現 UI 佈局 + C# ：GTK#, QT#, Delphi, Electron, Xamarin Forms, JavaFX
2.1.2 mono 自己是否有 CLI 以外的、屬於本身的 GUI 組件庫？YES. 它有一套 mono flavor 的 WinForms ，在 API 調用的角度 能夠在源代碼級別 幾乎兼容 Win 平臺 的 WinForms 。
2.1.2.1 mono 是否有本身的 GUI 開發辦法？YES ，即 mono flavor 的 WinForms ；在源代碼級別能夠兼容 Win 平臺的 WinForms App.
2.1.2.2 mono WinForms 是純代碼堆砌 UI (相似 Win WinForms, Java Swing, 它是純代碼堆砌 UI)
2.1.2.3 mono 是否會發展出 兼容 XAML-based 的 UI 開發實現？ mono 最新版本 1 是 目前暫無支持 XAML-based 的 官方開發實現。然而 Avalonia 做爲 原生跨平臺 的 GUI 組件庫，能夠在 mono 上使用 1 ；Xamarin Forms 做爲 原生跨平臺 的 GUI 組件庫，能夠在 mono 上使用 2 (廢話，Xamarin就是mono的人馬開發的)
2.2 mono 的最新版本 1

3 主流技術總結

對於三個主流 .NET Standard 實現 (mono, .NET Framework, .NET Core)，各個平臺的桌面軟件開發辦法的主流技術總結：(按照主流度排序)

對於 dotnet core, 若是想使用 標記語言佈局技術 + 代碼堆砌 的開發辦法：
win: WPF, Xamarin Forms (原生跨平臺), Avalonia (原生跨平臺), GTK# (原生跨平臺)
linux: GTK# (原生跨平臺), Xamarin Forms (原生跨平臺), Avalonia (原生跨平臺)
mac: Xamarin Forms (原生跨平臺), Avalonia (原生跨平臺), GTK# (原生跨平臺)

對於 .NET Framework, 若是想使用 標記語言佈局技術 + 代碼堆砌 的開發辦法：
win: WPF, GTK# (原生跨平臺), Xamarin Forms (原生跨平臺), Avalonia (原生跨平臺)
linux: -
mac: -

對於 mono, 若是想使用 標記語言佈局技術 + 代碼堆砌 的開發辦法：
win: WPF, Xamarin Forms (原生跨平臺), Avalonia (原生跨平臺)
linux: GTK# (原生跨平臺), Xamarin Forms (原生跨平臺), Avalonia (原生跨平臺)
mac: Xamarin Forms (原生跨平臺), GTK# (原生跨平臺), Avalonia (原生跨平臺)

考慮的因素：技術是否成熟(存在多久了,活躍期什麼時候)、開發是否方便(好比 GTK# binding 不是很方便 由於還要安裝 GTK 先)

4 分析：信息失靈
爲何會出現一邊倒的狀況？爲何互聯網上沒有正確的信息？
緣由一：很大一部分 dotnet core 的開發者，是 Win 開發者，他們不關心跨平臺；即便關心跨平臺，也想要優先保障 Win 平臺 app 的軟件 去 向外兼容各個平臺，簡言之：他們歷來沒有把 跨平臺看成第一目標 (由於他們的 app 已經開發成了，它首先是一個 Win app ，而後是一個 跨平臺 app)
緣由二：就 C# 開發者而言，自己 90% 都是沒有 跨平臺需求的，10% 有跨平臺需求 那也是跨手機平臺 ( 他們會去用 Xamarin Forms )
緣由三：有 跨平臺桌面軟件開發者 而言，自己 90% 都是會去選擇 QT, GTK, Delphi 這些 老牌 「原生跨平臺」 並支持標記語言佈局技術的 GUI 組件庫 (GUI toolkit)：他們，跨平臺桌面軟件開發者們，沒有把 C# 看成一個選項 (因此也就看不見 C# 區提供的 原生跨平臺並支持標記語言佈局技術的 GUI 組件庫，如 Xamarin Forms, Avalonia, GTK# --- 誒 有 C++ GTK/QT 就夠了 )。
緣由四：軟件開發自己就是一個細節不少的領域 1
緣由五：有欺騙性的人 (Scott Hanselman 之流，打着微軟的旗號，提跨平臺軟件卻不提 Xamarin 懂裝不懂，這我的太壞了 他失去了技術人的本分，並不能以 ‘迎合開源社區’ 做爲無辜；固然他可能只是一個開源軟件愛好者的縮影，這樣的人千千萬萬
Avalonia 廣告型 1 2
揣着明白裝糊塗型 1 2 3 4
純小白+大驚小怪+眼界狹小型 1 2 3 4
如數家珍 不知所云型 1 2 3
.NET Core 佈道型 1
好人 1 2 3

他們一驚一乍的味 我都能聞到，一驚一乍又不瞭解狀況 ( 有眼不識泰山 ) 因此期望什麼開源社區 哈哈。和他們打交道真的很累，但能夠預見的是 這會是一個長期事實 由於使用微軟C#技術的人的總量太多了 (相反 像 Backbone.js 這種總量是沒什麼人使用的紅極一時的技術 涼了也就涼了 1，而 相似 Avalonia 這種怪胎 涼涼很難 很難真的涼透 )，開源軟件界帶來的噪音 (人多嘴雜的開源社區，人總數多的地方，有眼不識泰山的人 天然也就會比人少的地方多；人多 聰明人就多 傻子也多 兩嘴脣一碰 啥都說出來了，胡說八道須要理由嗎？ 已經見怪不怪了 )

信息失靈的另外一個緣由是：
人的目標不一樣。若是A的目標是 先在W平臺作出一個軟件，而後 把現有的軟件 試圖在L和M平臺也能夠運行(所謂的 porting 移植)；B的目標是 作出一個軟件，而後 在各個平臺均可以運行(原軟件自己就支持各個平臺運行)。那麼 他們選用的 SDK 會同樣嗎？不會的。
換句話說，若是你的目標是 讓軟件自己就支持各個平臺運行，那麼 你的選擇就必定不會和 ‘先在W平臺...再在L和M平臺支持運行’的人的選擇同樣。

換句話說，若是你的目標是 開發跨平臺軟件，那麼你就不該該使用某平臺特定的 SDK (platform-specific SDK)。同時 你應該看清 「使用某平臺特定的 SDK」 和 「使用跨平臺SDK」 是兩羣人。

5
綜上，對於 跨平臺桌面軟件開發者 + C# + 微軟官方支持，最好的選擇是：
操做系統：win / mac / linux
.NET Standard 實現：dotnet core
GUI 組件庫：Xamarin Forms (原生跨平臺) (活躍期：2013-)
不採用：Avalonia (原生跨平臺) (太新)、GTK# (原生跨平臺) (不方便 須要 GTK)

Xamarin Forms (活躍期：11 12 13 2 3 ) 纔是贏家。它纔是一個 C# 跨平臺桌面軟件開發者 的正確的、受到微軟官方支持1 2 的選擇。

這 纔是 一個 C# 跨平臺桌面軟件開發者 應有的 關注點； Xamarin Forms 開發者圈子 纔是他們應該去的圈子。

跨平臺桌面軟件開發者們，微軟早就爲你指出一條明路了：Xamarin
很惋惜，這是一個只有少數人 才知道的祕密 ... 1 2
大多數 linuxer / 開源信仰者 都還在 等待 「社區支持」 的 WPF 開源方案 好比 Avalonia ，咳咳。坐井觀天
固然，分心的理由也不少：mono, WPF, Avalonia, GTK# ... 這麼多東西之間，隱藏着 Xamarin ，還被什麼移動端的光芒掩蓋了 (是爲了怕出觸動那些典型 Win 開發者(腦子裏沒有'原生跨平臺'這根弦 -- 也不須要 由於可能 80% 的 C# 開發者一生都會在 Win 平臺呆着, why bother? )的敏感神經嘛)

支持利用平臺特定的功能，如 Windows 上的 Windows Forms 和 WPF ，以及 Xamarin 系的特定平臺支持：經過 Xamarin 實現各個平臺的原生支持
Support for leveraging platform-specific capabilities, such as Windows Forms and WPF on Windows and the native bindings to each native platform from Xamarin.

這就是微軟的跨平臺軟件解決方案。

-