XAML 框架橫向對比
多年來，基於 XAML 的 UI 框架有了很大的發展。下面的圖表很好地證明了這個觀點。XAML UI 框架的三大巨頭：Avalonia UI、Uno Platform 和 .NET MAUI 都支持跨平臺的應用。事實上，除了 Avalonia UI，對跨平臺 XAML 的需求是它們發展的主要動力。如果微軟早一點介入，在幾年前就創建一個真正的類似 Flutter 的跨平臺 UI 框架，我們很可能永遠不會有所有這些選擇。這既是好事也是壞事：好的是我們現在有很多選擇，壞的是這些選擇都有不同的對象模型和 XAML 的“方言”（或者叫“變體”）。
在關注各種 .NET UI 框架的同時，有一個問題是老生常談的：我應該用哪個 XAML UI 框架來編寫應用程序？這是一個有意義且重要的問題。今天我們有這麼多的選擇，說明沒有絕對正確的解決方案。也就是說，在開發某個具體應用的語境下，這個問題比較容易，因爲每個框架都有明確的優勢和劣勢，可以與具體的應用需求進行比較。本文通過對比主流的基於 XAML 的 UI 框架的優勢和劣勢，旨在幫助公司和開發者回答這個問題：
我應該用哪個 XAML 框架來開發我的跨平臺應用程序？
高屋建瓴地來看，三個跨平臺的 XAML 框架的區別可以用架構來描述。所有的框架都是基於相同的 .NET（以前的 Mono）工具。Xamarin 對 .NET 的貢獻使所有這些框架得以存在，這一點不容忽視。此外，通過 .NET 6+，所有這些框架都在每個平臺上使用相同的運行時和核心庫。
- Avalonia UI : 完全自渲染控件和用戶界面元素本身。這也是 Flutter 使用的方法。
- .NET MAUI : 將一組名稱、屬性和事件標準化，並將它們應用/鏈接到特定平臺的本地控件。與本地控件的映射相當於是一種“取最大公因數”的方法。如果一個平臺不支持某項功能，那麼它很可能不會出現在 MAUI 的標準庫中（即 MAUI 標準庫的功能都可以被完美映射到平臺本地功能，而不需要用戶編寫平臺特定代碼）。
- Uno Platform : 使用一些特定的平臺基礎設施來構建和渲染控件。對於高層級的控件來說，這可以提供幾乎完美的像素結果。這意味着 Uno Platform 的行爲像 Avalonia UI 或 Flutter 一樣，完全渲染界面控件；但是，它也支持直接嵌入平臺特定的本地控件。這是一個混合架構。
其他基於微軟 XAML 的框架，如 WPF 和 UWP/WinUI 在此處不討論，因爲它們在歷史上不是跨平臺的。然而，WPF 現在可以使用 Wine Mono 或 Avalonia XPF 跨平臺運行。WinUI/UWP 本身已經可以使用下面討論的 Uno Platform 支持跨平臺。
相關項目鏈接
| 項目 | 網站 | GitHub | 文檔 |
|---|---|---|---|
| Avalonia UI | http://avaloniaui.net | http://github.com/AvaloniaUI/Avalonia | http://docs.avaloniaui.net |
| .NET MAUI | maui | http://github.com/dotnet/maui | http://docs.microsoft.com/en-us/dotnet/maui/ |
| Uno Platform | platform.uno | http://github.com/unoplatform/uno | platform.uno/docs/ |
其他框架
在本文中沒有介紹的其他的 .NET 跨平臺 UI 開發選項。這些其他的框架或方法值得一提，儘管它們沒有被包括在完整的比較中。
- WPF ：如前所述，WPF 現在可以使用 Wine Mono 或 Avalonia XPF 跨平臺運行。對於擁有大型 WPF 代碼庫的現有應用程序來說，這種可能性不應該被忽視。
- Eto.Forms ：一個 UI 框架，類似於 .NET MAUI，使用平臺原生控件構建 UI。XAML 的一個版本也可以用來序列化和構建 UI。
- Noesis GUI ：用於遊戲開發，Noesis GUI 重新創建了 WPF，以便在遊戲引擎（如 Unity）中使用，構建用戶界面。Noesis GUI 對 XAML 的支持非常完善，它甚至可以與 Microsoft Blend 一起工作。如果它能在遊戲引擎之外工作，並且對小型應用有更好的許可，這是一個非常有趣的技術，比其他一些跨平臺的 XAML 實現要早。
- .NET MAUI + Blazor Hybrid：.NET MAUI 可以承載 Blazor 網絡應用（在 BlazorWebView 控件中），使其更像是一個“應用+服務”的容器。對於那些希望將現有網絡應用重新打包並作爲移動應用發佈的人來說，這是一個非常有吸引力的選擇。
- .NET MAUI + Avalonia UI Hybrid : .NET MAUI 也可以承載 Avalonia UI 視圖（在 AvaloniaView 控件中），這使得它更像是一個“應用+服務”的容器。由於 Avalonia 只是一個 UI 框架，這是一個有吸引力的選擇，可以輕鬆獲得 .NET MAUI 的所有額外的平臺抽象功能（Essentials），以及更容易的移動打包和部署。
更多地將 .NET MAUI 用作“應用+服務”的容器，然後託管其他 UI 框架，如 Blazor 或 Avalonia UI，是一個有吸引力的選擇。這種架構有可能在未來獲得更多的吸引力，而且絕對是一個需要密切關注的領域。
對比表格
每個框架的表現都不一樣——尤其是在某些特定的地方。下面的表格強調了這些差異，重點是影響大的領域或特徵。在所有框架都表現相同的情況下，該項條目可能被忽略（即我們只關注差異）。
這種比較是基於大量的研究和對各種框架的經驗；但是，它是主觀的。還要注意的是，作者對 .NET MAUI 的經驗是三者中最少的，這可能會使排名出現偏差。
- ✔️ 表示支持該功能，❌ 表示不支持。
- ⭐⭐⭐ 是最高/最好的評價，⭐是最低/最差的評價。
| Avalonia | .NET MAUI | Uno Platform | |
|---|---|---|---|
| ▶ 特點 | |||
| MVVM 模式 | ✔️｜⭐⭐⭐ | ✔️｜⭐⭐ | ✔️｜⭐⭐⭐ |
| MVU 模式 | ❌ | ✔️｜⭐⭐ | ✔️｜⭐ |
| 像素級精確的渲染 | ✔️｜⭐⭐⭐ | ❌ | ✔️｜⭐⭐ |
| 無外觀控件 | ✔️｜⭐⭐⭐ | ❌ | ✔️｜⭐⭐⭐ |
| 樣式和主題 | ✔️｜⭐⭐⭐ | ✔️｜⭐ | ✔️｜⭐⭐⭐ |
| 統一的觀感和體驗 | ✔️｜⭐⭐⭐ | ❌ | ✔️｜⭐⭐⭐ |
| 平臺特色的觀感和體驗 | ❌ | ✔️｜⭐⭐⭐ | ✔️｜⭐ |
| 平臺一致性 | ✔️｜⭐⭐⭐ | ✔️｜⭐ | ✔️｜⭐⭐ |
| 原生控件整合 | ✔️｜⭐ | ✔️｜⭐⭐⭐ | ✔️｜⭐⭐⭐ |
| XAML 語法和代碼共用 | ✔️｜⭐⭐ | ✔️｜⭐ | ✔️｜⭐⭐⭐ |
| C# 代碼共用 | ✔️｜⭐⭐ | ✔️｜⭐ | ✔️｜⭐⭐⭐ |
| 熱重載 | ❌ | ✔️｜⭐⭐⭐ | ✔️｜⭐⭐⭐ |
| 第三方支持 | ✔️｜⭐ | ✔️｜⭐⭐⭐ | ✔️｜⭐⭐ |
| 富文本支持 | ✔️｜⭐⭐⭐ | ❌ | ❌ |
| 非 UI 的功能 | ❌ | ✔️｜⭐⭐ | ✔️｜⭐⭐⭐ |
| ▶ 策略與開發 | |||
| 理論性能 | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| 移動端 APP 穩定性 | ⭐ | ⭐⭐ | ⭐⭐ |
| 桌面端 APP 穩定性 | ⭐⭐⭐ | ⭐⭐ | ⭐ |
| 可用控件 | ⭐ | ⭐⭐ | ⭐⭐⭐ |
| 代碼協議（License） | ⭐ | ⭐⭐⭐ | ⭐⭐ |
| 免費支持 | ⭐ | ⭐⭐ | ⭐⭐⭐ |
| 付費支持 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| 項目活躍度 | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| 貢獻的容易程度 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| 源代碼的可讀性 | ⭐⭐⭐ | ⭐ | ⭐ |
| 開發體驗 | ⭐⭐⭐ | ⭐⭐ | ⭐ |
| 背後公司 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| ▶ IDE 與工具整合 | |||
| Visual Studio | ✔️｜⭐⭐ | ✔️｜⭐⭐⭐ | ✔️｜⭐⭐ |
| Visual Studio Code | ❌ | ✔️｜⭐⭐ | ✔️｜⭐⭐⭐ |
| Rider | ✔️｜⭐⭐⭐ | ✔️｜⭐ | ✔️｜⭐⭐ |
| 設計工具整合 | ❌ | ❌ | ✔️｜⭐⭐ |
| ▶ 平臺支持情況 | |||
| iOS 移動端 | ✔️｜⭐ | ✔️｜⭐⭐⭐ | ✔️｜⭐⭐ |
| Android 移動端 | ✔️｜⭐ | ✔️｜⭐⭐⭐ | ✔️｜⭐ |
| Windows 桌面端 | ✔️｜⭐⭐ | ✔️｜⭐ | ✔️｜⭐⭐⭐ |
| macOS 桌面端 | ✔️｜⭐⭐⭐ | ✔️｜⭐ | ✔️｜⭐ |
| Linux 桌面端 | ✔️｜⭐⭐⭐ | ❌ | ✔️｜⭐ |
| 瀏覽器網頁端 (WASM) | ✔️｜⭐ | ❌ | ✔️｜⭐⭐⭐ |
| ▶ 總體平臺支持情況 | |||
| 移動端 | ✔️｜⭐ | ✔️｜⭐⭐⭐ | ✔️｜⭐⭐ |
| 桌面端 | ✔️｜⭐⭐⭐ | ✔️｜⭐ | ✔️｜⭐ |
| 網頁端 | ✔️｜⭐ | ❌ | ✔️｜⭐⭐⭐ |
上述比較的最後一次更新是在2023年初。
關於比較的一些說明
MVU 模式
.NET MAUI 對傳統上被認爲是MVU模式的 [C# Markup](https://learn.microsoft.com/en-us/dotnet/communitytoolkit/maui/markup/markup) 和 [Comet](https://github.com/dotnet/Comet) 有最完整的支持。這是一個活躍的實驗和開發領域，預計今後會得到與 MVVM 相同水平的支持。
Uno Platform 已經開發了他們自己的 MVU 變體，稱爲 [MVU-X](https://platform.uno/docs/articles/external/uno.extensions/doc/Overview/Reactive/overview.html)。這與其他的產品有很大的不同，有一個更高的學習曲線，但確實與 XAML 數據綁定整合得更好。一個全新的 MVU 模式的方法的長期可行性將不得不看。在這個領域的實驗穩定下來之前，最好還是謹慎行事。
Avalonia 沒有提供第一方產品來支持 MVU 模式。然而，有兩個庫爲使用聲明式語法而不是 XAML 編寫 UI 提供了支持。[Avalonia.Markup.Declarative](https://github.com/AvaloniaUI/Avalonia.Markup.Declarative) 通過在 Avalonia 之上提供幫助方法和擴展，支持大量的 C# 標記概念。這爲用 C# 編寫 UI 提供了一個很好的方法，可以遵循 MVU 模式，不需要 XAML。F# 開發者的另一個選擇是 [Avalonia.FuncUI]（https://github.com/fsprojects/Avalonia.FuncUI），它專門爲 F# 語言提供了類似的支持。值得一提的是，在所有的框架中，Avalonia 對 F# 的支持是最好的（由社區提供）。
像素級精確的渲染
在這三個框架中，只有 Avalonia 支持真正的“像素完美”的渲染。這是由於架構的原因，只有 Avalonia 完全繪製了自己的用戶界面和控件。Uno Platform 雖然試圖實現“像素完美”，但由於使用了本地控件基礎設施，所以平臺之間經常會有差異。Uno Platform（除了在 Skia 上）從未完全畫出自己，因此從來沒有“像素完美”，只是一個近似值。
無外觀控件、樣式和主題
當一個開發者想到 XAML時 ，他們通常會想到無外觀的控件。能夠完全改變一個控件的風格和默認模板，將其變成完全不同的東西是 WPF 的一個主要特徵。Avalonia 和 Uno Platform 都完全支持他們自己版本的無外觀控件和重新模板化。然而，MAUI 不具備這種能力，而只支持改變一些常見的屬性。
在這方面，可以把 MAUI 想象成像 Windows Forms 這樣的老式界面工具箱。舉個例子，在 MAUI 中不支持在按鈕中放置圖標或圖形，而在其他 XAML 框架中這是非常容易的。
統一的觀感和體驗
在跨平臺框架的開發過程中，應用程序和代碼的一致性是非常重要的。你不希望在一個平臺上開發和驗證一個功能，然後發現它在另一個平臺上的工作方式不一樣。在這個領域，.NET MAUI 是非常差的，因爲它在每個平臺上都會映射到本地控件。它不僅需要到處驗證，還需要多次編寫自定義控件，同時花費大量的時間來調整事情，使其看起來統一（類似於讓一個網頁在所有的瀏覽器上正確呈現）。
Uno Platform 在大多數情況下都比 MAUI 好；然而，它也有一些嚴重的問題，如果某個功能不是在所有平臺上都存在。那些在所有平臺上都存在的功能通常表現一致，但有一些細微的差別，可能非常難以修復。
Avalonia UI 在這裏很容易超越其他框架，因爲它的架構不同。Avalonia 完全渲染自己，所以它在每個平臺上看起來都是一模一樣的（除了字體、輸入差異、彈出窗口等）。
原生控件整合
.NET MAUI 和 Uno Platform 都是建立在 Xamarin Native 之上，並與之完全集成。這意味着這兩個框架都可以通過 C# 綁定來訪問特定平臺的本地控件。這對於訪問本地平臺的功能和控件來說是非常強大的，幾乎沒有任何妥協。在 XAML 和代碼後臺都可以直接添加一個本地控件，就像框架本身內置的任何其他控件一樣。
相比之下，Avalonia UI 是它自己的 UI 層，不直接與 Xamarin Native（及其平臺特定控件）集成。相反，Avalonia 確實提供了一個 NativeControlHost，允許在 Avalonia 應用程序中嵌入本地控件。然而，這並不像 MAUI 或 Uno Platform 所提供的那樣簡單。Avalonia UI 與 WPF 不同，也解決了 3D 元素的“空域問題”，可以直接在各種表面上繪製 UI。這實際上允許 Avalonia 在遊戲引擎內或在 DirectX 表面上運行，這在其他框架中是不可能的。
XAML 語法和代碼共用
Uno Platform 在代碼共享方面有最高的評價。它使用與 UWP/WinUI 相同的 XAML 變體和對象模型，這使得它在 XAML 和 C# 中 100% 兼容。Avalonia 和 MAUI 都偏離了過去的 XAML 版本，與 WPF 或 UWP/WinUI 都不兼容。也就是說，Avalonia 努力在對象模型中與 WPF 相似，而 MAUI 在其他方面的偏離沒有什麼理由（Height/Width，TextBlock，等等）。Avalonia 在幾個案例中也成功地成爲 WPF 語法和對象模型的更強大的下一代。由於 XAML 的變化，有幾件事在 Avalonia 中更容易做到（樣式，IsVisible 爲 bool，簡化的網格行/列語法，等等）。由於 Avalonia 與現有 WPF 代碼的兼容性和代碼共享性更好，所以總體評價也更高。
富文本支持
最初的 XAML 框架 WPF 有一個極其先進的文本格式化 API（FlowDocument）。這仍然比今天的 WinUI 3 或之前的 UWP 中的內容更先進。事實上，直到 Avalonia UI 11.0 版本，沒有其他 XAML 框架支持高級文本功能。現在，Avalonia UI 幾乎擁有與 WPF 相同的 API，並且可以做一些在 .NET MAUI 和 Uno Platform 中根本不可能做到的文字格式和測量。由於架構上的差異，在可預見的未來，Avalonia UI 可能將繼續成爲唯一支持高級文本的框架（在第三方控件之外）。這包括像 RichTextBox 這樣的控件，在 Avalonia 中可以實現，但在 Uno Platform 中非常困難，在 .NET MAUI 中幾乎不可能。
非 UI 的功能
Avalonia UI 的主要缺點是，它只是一個UI框架。.NET MAUI 有 Essentials 包，而 Uno Platform 是繼 UWP 之後的整個應用開發平臺。.NET MAUI 和 Uno Platform 都可以被認爲不僅僅是一個 UI 框架。這意味着諸如持久性設置、文件處理、認證、本地化和設備權限等東西在 MAUI 或 Uno Platform 中可以立即使用，但在 Avalonia 中卻不能。Uno Platform 甚至擁有 UWP 中才有的先進的音頻相關 API，可以跨平臺使用。
然而，Uno Platform 試圖覆蓋整個 UWP API 體系，這是很龐大的。整個 API 是自動生成的，很多功能都是未實現的空函數。這意味着大多數非用戶接口的 API 是不可用的，如果在應用程序中使用它們，會出現異常。這確實在開發過程中產生了一些問題，但編譯會顯示哪些未實現的 API 正在被使用。即便如此，Uno Platform 仍然比其他框架擁有更多的非 UI 功能。
性能
XAML 來自於桌面，因此資源是相當密集的。WPF（最初的 XAML 框架）通常在運行時從 XAML 標記中構建整個視圖，這在第一次加載時可能是一個嚴重的性能打擊。此外，使用 MVVM 模式將控件綁定到視圖模型上，這使用了反射綁定，與編譯的代碼相比，反射本身就很慢。基礎 XAML 控件傳統上有更高的性能和系統要求，這可能是移動或雲平臺的一個問題。
UWP，也就是 Uno Platform，通過 x:Load 允許懶惰加載來改進這一點。它們也都支持使用 x:Bind 的編譯綁定。MAUI 的架構通過使用本地控件完全避開了第一個問題。Avalonia UI 已經在很大程度上轉向了預編譯的 XAML 和編譯的綁定，這也解決了這兩個問題。這三個平臺都有比 WPF 更好的理論性能。
與性能有關的 MVU 模式不應該被忽視。用戶界面不是由 XAML 標記構建的——它是在代碼中與邏輯和通常是代碼後置的東西一起構建的。默認情況下，這意味着控件和用戶界面元素只有在它們被代碼引用並需要顯示時才被構建。這樣一來，使用 MVU 模式的性能有望超過 MVVM 模式應用的性能。MAUI 和 Uno Platform 都支持 MVU 模式。Avalonia 也支持完全在代碼中創建 UI，沒有 XAML，這也實現了同樣的性能優勢。
.NET MAUI 的性能被評爲兩顆星，低於 Avalonia 的三顆星，這有點不符合常理。儘管 MAUI 使用了本地控件，但其原因是互操作。這在很大程度上被本地編譯所緩解，但任何 C# 與 Android 控件的整合都會帶來性能上的損失。然而，Avalonia 完全渲染自己，不與安卓的本地控件元素互動（除非託管本地控件）。這意味着 Avalonia 本質上可以擁有視頻遊戲的性能。
Uno Platform 的性能在大多數平臺上一般都是足夠的。然而，在 Android 上，.NET 運行時和 Java 運行時之間存在嚴重的互操作性能問題。這是 .NET Android 本身的問題。然而，由於 Uno Platform 的架構（與本地控件集成），這種互操作總是需要的。這意味着，在安卓上，Uno Platform 的性能從根本上不如其他框架，安卓上的高性能 Uno Platform 應用目前還無法實現。
APP 穩定性
MAUI 的移動應用穩定性與 Uno Platform 排名相同；但是，遇到每個平臺的佈局 bug 是很常見的，需要大量的特殊情況下的代碼和標記。Uno Platform 也有一些未處理的案例和一些在整個開發過程中會出現的 bug。這主要是由於快速開發速度優先於正確性和完整性的策略造成的。相比之下，Avalonia UI 的開發從一開始就考慮到了穩定性：它所具有的功能是完全可以實現的。在實踐中，Avalonia UI 可能是最穩定和最容易開發的。
代碼協議
Uno Platform 不是 MIT 許可，是 Apache 2.0。Apache 許可證不像 MIT 那樣寬鬆，除此之外，這也阻止了代碼共享回到其他 MIT 許可的框架中。Uno Platform 可以使用 MIT 許可項目的源代碼，如 WinUI、WPF 和 Avalonia，但這些項目不能使用 Uno Platform 的代碼。這就是爲什麼 Uno Platform 在這裏排名較低。
Avalonia UI 最初是完全由 MIT 授權的，並獲得了三顆星。然而，隨着[重新授權分發合成渲染器](https://raw.githubusercontent.com/AvaloniaUI/Avalonia/master/src/Avalonia.Base/Rendering/Composition/License.md)，禁止以原始二進制形式以外的任何形式進行修改和傳播，這降低了分數。構圖渲染器是 Avalonia 11+ 版本中唯一支持的渲染器，其他的都被刪除了。這使得修改 Avalonia 並在你自己的應用程序中分發它變得很困難。團隊已經澄清了許可證將“在 v11 版本進入 GA 時恢復到 MIT”，本節將在那時更新。
反饋與支持
Avalonia 和 Uno Platform 在付費支持方面都比 MAUI 排名高，儘管 MAUI 是由微軟開發的。這主要是由於小公司的敏捷性。微軟現在高度官僚化，任何反饋或變化，即使是微小的，也需要廣泛的討論纔能有動作。這與 Avalonia 和 Uno Platform 形成鮮明對比，Avalonia 可以非常迅速地採用新功能，而 Uno Platform 則有極快的溝通。在免費支持方面，Uno Platform 有很好的社區響應時間，與較大的 MAUI 社區相當。然而，Uno Platform 一般能更快地解決 bug 和實現功能。
源代碼的可讀性與貢獻的難易
Avalonia UI 擁有最簡潔的代碼庫，大大降低了公衆貢獻的門檻。Uno Platform 和 .NET MAUI 要複雜得多，代碼也顯示了這一點。從長遠來看，複雜性的增加通常會在維護和穩定性方面造成障礙。在 Uno Platform 的情況下，這種複雜性對於滿足架構目標和支持本地控制集成是必要的。
開發體驗
Avalonia UI 擁有最好的整體開發者體驗。代碼庫易於閱讀，使用 Rider 的 IDE 和調試體驗是一流的（在其他 IDE 上較差）。.NET MAUI 是非常接近的第二名，因爲它現在與 Visual Studio 的第一方集成超過了所有其他的。然而，由於需要在每個平臺上分別驗證/調整每個功能/視圖，.NET MAUI 在整體開發者體驗方面有所欠缺。Uno Platform 的開發者體驗很差，在 Visual Studio 中的集成度很低，編譯時間非常長，而且調試困難。關於開發者體驗的更多細節可在 IDE 整合部分找到。
背後公司
乍一看，.NET MAUI 似乎有最強大的企業支持，因爲它是由微軟開發的。然而，微軟並沒有在該項目上投入大量的資源，而且微軟放棄 UI 框架的長期歷史也造成了不確定性。
Avalonia，雖然最初是完全開源的，但現在是由一些核心團隊成員成立的公司支持的。這提供了一個很好的穩定性和收入來維持這個項目。然而，由於公司的影響力越來越大和代碼庫的閉源進展，這裏需要謹慎對待。例如，組成渲染引擎現在不是自由許可的修改（而其餘的代碼是 MIT 許可的）。隨着 v11 發佈，這種情況應該會改變。
然而，由於有 *nventive* 的企業贊助，以及令人難以置信的溝通和響應時間，Uno Platform 仍然處於一個獨立的級別。他們與微軟的合作關係和密切溝通也值得注意。
Visual Studio 整合
沒有一個框架在 Visual Studio 集成方面有三顆星。這是因爲 Visual Studio 在歷史上專注於 Windows 優先的框架，如 WinForms、WPF、UWP 和 WinUI，並以非擴展的方式對這些框架進行硬編碼支持。然而，.NET MAUI 的支持正在得到相當大的改善（從推出時幾乎無法使用）。Uno Platform 的 Visual Studio 集成還有很多需要改進的地方，顯然是三者中最差的，這也是導致開發者體驗不佳的原因。這不是他們的錯，因爲微軟並沒有合理地支持任何其他使用 .xaml 文件的項目類型。Visual Studio 中的 Avalonia 支持提供了堅實的預覽器支持，大多數東西都能工作——通過使用特殊的 .axaml 擴展名--但 XAML 的工作並不像在 Rider 等其他 IDE 上那麼順利。
Visual Studio Code 整合
Uno Platform 團隊開發了一個 [Visual Studio Code的擴展](https://platform.uno/blog/announcing-net-mobile-debugging-in-vs-code-mobile-development-in-vs-code-with-uno-platform-or-net-maui/)，可以實現移動和網絡應用的開發，更重要的是可以進行調試。這是 VS Code 工具的一大進步，因爲作爲 C#/.NET 應用程序的 IDE，VS Code 工具在歷史上對開發者並不友好。令人驚訝的是，該擴展還支持 .NET MAUI 應用程序。Uno Platform 團隊在這裏真正站了出來，填補了 VS Code 支持方面的一個長期空白，從而使這個 IDE 獲得了滿分三顆星。Uno Platform 應用程序現在在 Visual Studio Code 中得到了最好的支持（除非在 Windows 上作爲 WinUI 開發，否則 Visual Studio 仍然是最好的）。請注意，這個擴展不是開源的。
設計工具整合
現在只有 Uno Platform 支持一個設計工具（Figma）來構建用戶界面。這種支持是由一個閉源的 XAML 生成器提供的。在過去，Microsoft Blend 可用於 WPF 以支持同樣的作用。生成的 XAML 的質量和效率可能有所欠缺；但是，對於那些在這些團隊之間有明確分工的公司來說，它有助於設計者向開發者過渡。
.NET MAUI 不支持任何設計工具，而且由於它的結構，可能永遠不會支持。然而，它有開箱即用的對 XAML 的實時編輯的支持，這使設計者可以在代碼添加之前直接在應用程序中調整和添加一些 UI 元素。Uno Platform 也支持 XAML 的實時編輯。
平臺支持
Uno Platform 支持最多的平臺，幾乎可以在任何設備上運行，並取得不同程度的成功（其最強的領域是移動和網絡）。Uno Platform 通過 WinUI/UWP 直接支持 Windows 桌面，所以在 Windows 桌面上獲得了原生的最高排名。值得注意的是，在 Uno Platform 中，某些後端和平臺缺乏其他平臺所具有的功能。這可能導致的問題是，你可以在 iOS/Android 上做一些你在 Linux 上做不到的事情。所以平臺支持並不一致，應該仔細審查。這在 macOS 上尤其如此，在上次測試時（2021年），Uno Platform 的運行情況極差。今天，通常使用 macCatalyst 構建 macOS 應用程序會更好，因爲 Uno Platform 的 iOS 支持明顯更好、更完整。Skia 後端也是所有桌面平臺（甚至是舊版本的 Windows）的一個選擇。請記住（如*性能*部分所述），與 iOS 相比，Uno Platform 在 Android 上的性能較差。
Avalonia UI 在 macOS 和 Linux 桌面平臺上遠遠領先於其他框架。Avalonia 在 Windows 桌面端也有很高的分數，但沒有使用原生 UI 工具包，所以得分比 Uno Platform 低一些。移動端和網頁端支持是在 11.0 版本中新發布的，可能需要時間來穩定，所以目前得分較低。Avalonia 的網頁端實現渲染到一個 HTML5 畫布。這永遠不會像 Uno Platform 的架構那樣好，Uno Platform 將界面整合爲 HTML 元素。
.NET MAUI 完全不支持 Linux 或網頁端。在平臺覆蓋方面，它顯然不如另外兩個。
每個平臺下的框架推薦
在每個平臺的上，有一些框架的表現是最好的。這也是主觀的；但是，總的來說，評估應該是有方向性的，並考慮到所有的因素。
如果一個應用程序只需要在桌面平臺上使用，Avalonia 是一個非常有力的選擇。它對 Windows 的支持是一流的，只是因爲它不是原生 UI，所以排名低於 WinUI 或 WPF。然而，在一個應用程序中，沒有明顯的限制，許多桌面應用程序今天已經使用它。事實上，Avalonia 甚至支持在 WPF 中無法做到的事情，如在 DirectX 表面覆蓋 XAML 控件。
如果一個應用程序需要跨平臺，可以先用 WinUI 或 WPF 編寫。使用 Windows 的 WPF 代碼庫可以很好地轉換到 Avalonia，但仍然需要三種不同的 XAML 變體，它也不是最新的技術。出於這個原因，一般來說，最好使用 WinUI，它可以 100% 與 Uno Platform 共享。這意味着只需要兩種 XAML 的變體。
還要注意的是：
* Web/Wasm是 Uno Platform 的一個明顯優勢。由於架構差異，Avalonia 在這裏很難競爭（用 Skia 完全渲染）。
* Avalonia UI 是最接近 Flutter 的競爭者。它在每個平臺上都使用 Skia（或在 Windows 上可選擇使用 Direct2D）完全渲染自己。這比 Uno Platform 有很大的性能優勢，特別是在 macOS 和 Android 上可見。這樣一來，Avalonia 在所有框架中擁有最簡潔的架構，而且社區參與的門檻最低。
* Avalonia UI 被定位爲下一代的 WPF，它重新實現了大多數功能。Avalonia 從 WPF（Grid，文本格式化）和 WinUI（ItemsRepeater，觸摸輸入 API）中獲得了一些想法和代碼，同時還有其他 XAML 框架中沒有的獨特想法（在某些方面更接近 CSS 的高級樣式系統）。今天，它已經爲桌面應用程序開發者準備好了——特別是那些已有 WPF 代碼的開發者。對於 UWP/WinUI 開發者來說，這是一個比較粗糙的過渡，但在第11版中加入了更多來自 UWP/WinUI 的最新功能，以改善過渡情況。對於不想改變現有代碼的企業 WPF 應用，Avalonia 還提供了Avalonia XPF，它在Avalonia 渲染引擎之上實現了開源的 WPF 代碼庫。
* .NET MAUI 並沒有被列爲任何平臺的最佳選擇。它對沒有複雜 UI 的小型應用程序最有用。它的有用性，以及在平臺之間共享代碼的能力，對於甚至是中等複雜的應用程序來說，很快就會落後於其他框架。然而，在某些業務線或更簡單的應用程序中，MAUI 可能是更好的選擇。最近，MAUI 還能夠同時託管 Blazor 和 Avalonia UI，這爲某些場景提供了一個有趣的選擇。
* Avalonia 最適用於 Windows 10 之前的 Windows 版本。雖然 Uno Platform 也有其 Skia 後臺的解決方案，但它在功能、穩定性和完整性方面大大落後。
* 如上表所示，使用 XAML 的兩種變體可以很好地支持所有平臺：WinUI/UWP 變體用於 Windows 和 Uno Platform 的手機，Avalonia 變體用於其他平臺。
鏈接與引用
- Question: XAML Flavor, Architecture & Roadmap
- The New .NET Multi-platform App UI
- Goodbye Xamarin.Forms
- Putting “Universal” back into UWP
- Evolution of Client Development: Richard Campbell
- [Spec] Slim Renderer Architecture
- Discussion: Compatibility with WPF, UWP and WinUI
- Project Reunion: An End to Microsoft’s UI Madness?
結論
我們花了很多年才走到這一步，但我們終於有了一個好地方，有了強大的 UI 框架，涵蓋了 .NET 的所有用途。有趣的是，所有的框架都發展到了一個非常獨特且功能幾乎是互補的狀態。可能你想嘗試的一切都被其中一個或幾個框架所涵蓋。今天，我們可以編寫跨平臺的 XAML/C# 應用程序，而且運行得相當好。大部分技術（除了 UI 層）都是基於 Mono 的，所以這要歸功於 Xamarin。
每個框架所取得的成就都很了不起。然而，沒有一個框架在所有平臺上都占主導地位，每個平臺都有自己的優勢和劣勢。Uno Platform 來自 Android/iOS 的遺產，這些移動平臺和 Web 平臺是最強大的。Avalonia 來自桌面端遺產，在 Windows/Linux/MacOS 上效果最好，但移動平臺正在迅速發展。截至 2023 年，Uno Platform 對 macOS 的支持充其量只是試驗性的，對於簡單的應用程序來說是無法使用的。Avalonia，截至 2023 年，只對移動端有初步支持，但實際上在所有平臺上都更穩定。儘管如此，現在可能需要利用兩個不同的 UI 框架來實現基於 XAML 的跨平臺 UI。
轉自 https://zhuanlan.zhihu.com/p/638115608