多年來，基於 XAML 的 UI 框架已經有了很大的發展，下面的圖表是最好的說明。這些框架主要包含：支援跨平臺應用的 Avalonia UI, Uno Platform 和 .NET MAUI。事實上，除了 Avalonia UI 之外，對跨平臺 XAML 的需求是其發展的主要驅動力。如果微軟早點推出一個類似 Flutter 這樣的跨平臺 UI 框架，我們可能就不會有這麼多的選擇。這樣有利有弊：好處在於我們有很多跨平臺方案可以選擇，壞處在於不同的框架有不同的物件模型以及各自特有的 XAML 語法（dialect of XAML）。
在關注各種 .NET UI 框架時，我們會提出同一個問題：應該使用哪一個 XAML UI 框架來開發我們的應用？這是一個合理且重要的問題。迄今為止還沒有一個明確的答案。但是，對於每個具體的應用，這個問題很容易回答，因為可以針對特定的應用需求比較分析每一種框架的優點和缺點。透過概述基於 XAML 的主要 UI 框架的優點和缺點，本文件旨在幫助公司和開發人員回答以下問題：
應該選擇哪一個 XAML 框架開發我的跨平臺應用？
從宏觀角度來看，可以從架構上描述這些基於 XAML 的跨平臺 UI 框架的差異。這些框架都是基於相同的 .NET（以前的 Mono）工具。不容忽視的是，Xamarin 對 .NET 的貢獻使得這些框架存在。此外，在 .NET 6+ 中，這些框架在每個平臺上都使用相同的執行階段和核心程式庫。
- Avalonia UI : 完全自己呈現控制項和使用者介面元素，這一點和 Flutter 相同。
- .NET MAUI : 標準化一組名稱、屬性、事件，並將它們應用/連結到特定平臺的原生控制項。如果單個平臺不支援某項功能，該功能則不會出現在所有平臺的 MAUI 中（不涉及特定平臺的程式碼）
- Uno Platform : 使用選定的幾個特定於平臺的基本元素來建構和渲染控制項。 對於進階控制項，這提供了近乎像素完美的結果。這意味著 Uno Platform 像 Avalonia UI 和 Flutter 那樣完全渲染控制項；不過，它還支援直接嵌入特定平臺的原生控制項，是一個混合架構。
因為 WPF 和 UWP/WinUI 這些基於 XAML 的微軟框架不是跨平臺的，所以這裡不進行詳細比較。但是 WPF 可以透過Wine Mono 或者 Avalonia XPF跨平臺執行。WinUI/UWP 已透過接下來討論的 Uno Platform 支援跨平臺執行。
專案連結
| Project | Website | GitHub | Docs |
|---|---|---|---|
| Avalonia UI | avaloniaui.net | github.com/AvaloniaUI/Avalonia | docs.avaloniaui.net |
| .NET MAUI | maui | github.com/dotnet/maui | docs.microsoft.com/en-us/dotnet/maui/ |
| Uno Platform | platform.uno | github.com/unoplatform/uno | platform.uno/docs/ |
其他框架
還有一些其他可用於 .NET 跨平臺開發的解決方案在本文不再詳細描述。即便本文不會進行詳細對比，這些框架或者解決方案也值得瞭解一下：
- WPF : 正如上文所講，WPF 可以透過Wine Mono 或者 Avalonia XPF跨平臺執行。對於 WPF 程式碼量較大的現有應用，可以考慮這種跨平臺解決方案。
- Eto.Forms : 一個類似於 .NET MAUI 的 UI 框架，使用平臺原生控制項建構 UI，XAML 也可以用於序列化和建構 UI。
- Noesis GUI : 用於遊戲開發， Noesis GUI 重新建立 WPF，用於遊戲引擎（如 Unity）以建構使用者介面。Noesis GUI 對 XAML 的支援非常廣泛，可以和 Microsoft Blend 一起使用。 如果它可以在遊戲引擎之外工作，並且對較小的應用程式有更好的許可，那麼它將是一項早於其他跨平臺 XAML 實現的有趣技術。
- .NET MAUI + Blazor Hybrid : .NET MAUI 可以託管 Blazor Web 應用（在 BlazorWebView 控制項內），使其更像是應用程式和服務容器。對於那些希望將現有 Web 應用程式重新打包並分發為行動應用程式的人來說，這是一個非常有吸引力的選擇。
- .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 模式 | ❌ | ✔️ ｜ ⭐⭐ | ✔️ ｜ ⭐ |
| Pixel-perfect rendering | ✔️ ｜ ⭐⭐⭐ | ❌ | ✔️ ｜ ⭐⭐ |
| 控制項 | ✔️ ｜ ⭐⭐⭐ | ❌ | ✔️ ｜ ⭐⭐⭐ |
| 樣式和主題 | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ |
| 支援統一的外觀 | ✔️ ｜ ⭐⭐⭐ | ❌ | ✔️ ｜ ⭐⭐⭐ |
| 平臺原生外觀 | ❌ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐ |
| 平臺一致性 | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐ |
| 原生控制項整合 | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐⭐⭐ |
| XAML 語法和程式碼共用 | ✔️ ｜ ⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ |
| C# 程式碼後置共用 | ✔️ ｜ ⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ |
| 熱重載 | ❌ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐⭐⭐ |
| 第三方支援 | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐⭐ |
| 進階文字格式 | ✔️ ｜ ⭐⭐⭐ | ❌ | ❌ |
| 非使用者介面功能 | ❌ | ✔️ ｜ ⭐⭐ | ✔️ ｜ ⭐⭐⭐ |
| ▶ 策略與開發 | |||
| 效能（理論） | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| 行動應用穩定性 | ⭐ | ⭐⭐ | ⭐⭐ |
| 桌面應用穩定性 | ⭐⭐⭐ | ⭐⭐ | ⭐ |
| 可用控制項 | ⭐ | ⭐⭐ | ⭐⭐⭐ |
| 程式碼許可證 | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| 免費支援 | ⭐ | ⭐⭐ | ⭐⭐⭐ |
| 付費支援 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| 專案速度 | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| 易於貢獻 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| 程式碼庫可讀性 | ⭐⭐⭐ | ⭐ | ⭐ |
| 開發人員體驗 | ⭐⭐⭐ | ⭐⭐ | ⭐ |
| 企業支援 | ⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| ▶ IDE 和整合工具 | |||
| Visual Studio | ✔️ ｜ ⭐⭐ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐⭐ |
| Visual Studio Code | ✔️ ｜ TBD | ✔️ ｜ ⭐⭐ | ✔️ ｜ ⭐⭐⭐ |
| Rider | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐ |
| Design tool integration | ❌ | ❌ | ✔️ ｜ ⭐⭐ |
| ▶ 平臺支援 | |||
| iOS | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐⭐ |
| Android | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐ |
| Windows 桌面應用 | ✔️ ｜ ⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ |
| macOS 桌面應用 | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐ |
| Linux 桌面應用 | ✔️ ｜ ⭐⭐⭐ | ❌ | ✔️ ｜ ⭐ |
| Web Browser (WASM) | ✔️ ｜ ⭐ | ❌ | ✔️ ｜ ⭐⭐⭐ |
| ▶ 整體平臺支援 | |||
| 行動端 | ✔️ ｜ ⭐ | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐⭐ |
| 桌面程式 | ✔️ ｜ ⭐⭐⭐ | ✔️ ｜ ⭐ | ✔️ ｜ ⭐ |
| Web | ✔️ ｜ ⭐ | ❌ | ✔️ ｜ ⭐⭐⭐ |
該表格最近一次更新是在 2023 年 7 月。
備註
MVU 模式
.NET MAUI 對傳統上認為的帶有 C# Markup and Comet的 MVU 模式具有最完整的支援。這是一個活躍的試驗性和開發領域，預計未來將得到和 MVVM 的相同級別的支援。Uno Platform 開發了自己的 MVU 變體，稱為 MVU-X。這與其他產品有很大不同，並且具有更高的學習曲線，但確實與 XAML 資料繫結整合得更好。MVU 模式這一全新方法的長期可行性還有待觀察，在這實驗性的方案穩定之前，最好謹慎選擇。Avalonia 沒有直接的支援 MVU 模式。但是，它提供了兩個類庫支援使用宣告式語法替代 XAML 編寫 UI 介面。Avalonia.Markup.Declarative透過在 Avalonia 上提供幫助方法和擴展來支援許多 C#標記概念。這提供了一種用 C#編寫 UI 介面的好方法，該方法可以遵循 MVU 模式而不需要使用 XAML。F# 開發人員的另一個選擇是Avalonia.FuncUI，它專門為 F#語言提供了類似的支援。值得注意的是，在所有框架中，Avalonia 對 F# 的支援最好（由社群提供）。
Pixel-Perfect Rendering
在這三個框架中，只有 Avalonia 支援真正的“pixel-perfect”渲染。這是由於架構的原因，只有 Avalonia 完全繪製了自己的使用者介面和控制項。雖然 Uno Platform 試圖實現“pixel-perfect”，但由於使用原生的基本控制項，在不同平臺之間經常存在差異。Uno Platform（skia 除外）從未完全繪製自己的控制項，因此只是趨近於“pixel-perfect”。
無固定外觀控制項(Lookless Controls)，樣式 & 主題
當開發人員想到 XAML 時，他們通常會想到無固定外觀控制項（lookless controls）。能夠完全變更控制項的樣式和預設範本以將其轉換為完全不同的內容是 WPF 的一個主要功能。Avalonia 和 Uno Platform 都完整支援自己版本的無固定外觀控制項（lookless controls）和範本重定義。但是，MAUI 不具備此功能，僅支援變更一些常見的屬性。在這方面，可以把 MAUI 看作是 Windows Forms 這類較舊的介面工具包。例如，這意味著在 MAUI 中不支援在按鈕內放置圖示或圖形，而在其他的 XAML 框架中則很容易實現。什麼是Lookless Controls WPF 控制項的行為是固定的。例如，按鈕有一組固定的事件，包括單擊事件。不管你用按鈕控制項做什麼操作，它仍然會有一個點選事件。 WPF 控制項沒有固定的“外觀”。Lookless 這個詞恰好可以簡潔的表達這個意思。 按鈕的預設外觀是由預設的 XAML 範本定義的，可以替換一個完全不同的範本，從而完全改變按鈕控制項的外觀。
平臺一致性
在使用跨平臺框架進行開發時，應用程式和程式碼的一致性非常重要。您不想在一個平臺上開發和驗證的功能，然後發現它在另一個平臺上的執行效果不同。在這方面，.NET MAUI 非常差，因為它連結到每個平臺上的原生控制項。這不僅需要對所有地方進行驗證，而且需要多次編寫自訂控制項，同時花費大量時間調整內容以使其看起來一致（類似於讓網頁在所有瀏覽器上正確呈現）大多數情況下，Uno Platform 比 MAUI 表現得更好。但是，它也存在一些嚴重的問題，一些功能並不是在所有平臺上都支援。那些所有平臺上都有的功能通常表現一致，但也可能存在很難修復的細微差異。由於架構差異，Avalonia UI 在平臺一致性的問題上很容易超越其他框架。Avalonia 完全自己渲染，因此它在每個平臺上看起來總是完全相同（字型、輸入差異、彈出視窗等除外）。
原生控制項整合
.NET MAUI 和 Uno Platform 都建立在 Xamarin Native 之上，並與之完全整合。這意味著兩個框架都可以透過 c#繫結存取特定於平臺的原生控制項。這對於存取原生平臺功能和控制項來說非常強大，幾乎沒有任何妥協。可以直接在 XAML 和程式碼後置中加入原生控制項，就像框架本身內建的任何其他控制項一樣。相比之下，Avalonia UI 是它自己的 UI 層，它不直接與 Xamarin Native(及其特定於平臺的控制項)整合。作為替代，Avalonia 提供了一個允許在 Avalonia 應用程式中嵌入本地控制項的 NativeControlHost。但是，這並不像 MAUI 或者 Uno Platform 中那樣簡潔。類似於 WPF 中的 WindowsFormsHost，但與之不同的是，Avalonia UI 還使用 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 的一些改變（樣式，bool 型別的 IsVisible，簡化的網格行/列語法等），使得一些操作在 Avalonia 中更容易。與 MAUI 相比，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 有必備的軟體包，Uno Platform 是繼 UWP 之後的一個完整的應用開發平臺。可以說.NET MAUI 和 Uno Platform 都不僅僅是一個 UI 框架。這意味著在.NET MAUI 和 Uno Platform 中諸如持久化設定、檔案處理、身份驗證、本地化和裝置許可權等內容都可以立即使用，但在 Avalonia 不行。Uno Platform 甚至具有一些僅在 UWP 中才能找到的音訊相關的進階 API，並且可以跨平臺。Uno Platform 試圖覆蓋整個 UWP 的對外公開的 API（API-surface），這包含大量的 API。整個 API 是自動產生的，其中許多功能未實現 stubs。這意味著大多數非 UI 的 API 不可用，如果在應用中使用它們，則會引發異常。這確實會在開發過程中產生一些問題，但編譯器會顯示正在使用哪些未實現的 API。儘管如此，Uno Platform 依然比其他框架擁有更多的非 UI 功能。
效能
XAML 源自於桌面應用，本身也相當消耗資源。WPF(最初的 XAML 框架)通常在執行階段從 XAML 標記中構建整個檢視，這在首次載入時可能會嚴重影響效能。此外，使用 MVVM 是透過反射繫結把控制項繫結到 viewmodel 上，相比於編譯後的程式碼，反射繫結本來就慢一些。最重要的是，傳統的 XAML 控制項具有更高的效能和系統要求，這可能是行動平臺或雲平臺需要考慮的問題。UWP 和 Uno Platform 透過 x:Load 允許懶載入來改進這一點。它們都支援使用 x:Bind 進行編譯繫結。MAUI 的體系結構透過使用原生控制項完全避免了第一個問題。Avalonia UI 已在很大程度上切換到預編譯的 XAML 和編譯繫結，這也解決了這兩個問題。這三種框架理論上效能都優於 WPF。與效能相關的 MVU 模式不應被忽視。UI 不是由 XAML 標記構造的，它通常是在程式碼中和程式碼後置中的業務邏輯一起構造。預設情況下，這意味著控制項和使用者介面元素只有在被程式碼引用並需要顯示時才會構造。透過這種方式，使用 MVU 模式的效能有望超過 MVVM 模式應用程式的效能。MAUI 和 Uno Platform 都支援 MVU 模式。Avalonia 也完全支援在程式碼中建立 UI，而不使用 XAML，從而獲得同樣的效能優勢。MAUI 的效能並非故意評為兩顆星，低於 Avalonia 的三顆星。其原因是：MAUI 使用原生控制項，是互操作。本機編譯在很大程度上緩解了這一問題，但 C#和 Android 控制項整合都會降低效能。然而，Avalonia 完全渲染自己，並且不與 android 原生控制項互動(除非託管本機檢視)。這意味著 Avalonia 基本上可以擁有視訊遊戲（video game）的效能。Uno Platform 的效能在大部份平臺上通常都是足夠的。但是，在 Android 上，.NET 執行階段和 Java 執行階段之间存在嚴重的互操作效能問題。這是.NET 和 Android 本身的問題。然而，由於 Uno Platform 的體系結構(與本機控制項整合)，這種互操作總是必需的。這意味著，在 Android 上，Uno Platform 的效能從根本上不如其他框架，並且 Android 上的高效能 Uno Platform 應用程式目前是不可能實現的。
應用穩定性
MAUI 的行動應用穩定性與 Uno Platform 排名相同；但是，在不同平臺上遇到需要用大量針對特定情況的程式碼和標記來處理的佈局問題是很常見的。Uno Platform 還有許多沒有處理的情況和一些 bug，這些都會在整個開發過程中出現。這在很大程度上是快速開發速度優於正確性和穩定性的策略帶來的結果。相比之下，Avalonia UI 從一開始就考慮到穩定性：它的功能是完整的。在實踐中，Avalonia UI 可能是最穩定和最容易開發的。
程式碼的許可協議
Uno Platform 採用的不是 MIT license，而是 Apache 2.0。Apache license 不像 MIT 那樣寬鬆。除了別的方面，這阻止了程式碼共用回其他 MIT 許可的框架。Uno Platform 可以使用 MIT 許可專案（如 WinUI、WPF 和 Avalonia）的原始碼，但這些專案基本上不能使用 Uno Platform 的程式碼。這就是為什麼 Uno Platform 在這裡排名較低。Avalonia UI 最初完全是 MIT 授權的，並獲得了三星評級。但是，隨著 re-licensing of the composition renderer，禁止以原始二進位制形式以外的任何形式進行修改和分發，這降低了分數。合成渲染器（composition renderer）是 Avalonia 版本 11+中唯一支援的渲染器，其他渲染器已被刪除。這使得修改 Avalonia 並在您自己的應用程式中分發它被禁止。該團隊已經澄清，該許可證將“在 v11 進入 GA 時恢復到 MIT”。（此部分於 2023 年 7 月廢棄，有下一段內容替代。） Avalonia UI 完全是 MIT 授權的，可以在大多數.NET 基金會和 WinUI 專案之間免費共用程式碼。對於需要完全掌控 UI 框架以達到快速推送修復，確保特定應用穩定性的目的，甚至是想替換自訂的內部元件的公司來說，Avalonia UI 是一個理想的選擇。
支援
儘管 MAUI 是由 Microsoft 開發的，Avalonia 和 Uno Platform 在付費支援方面的排名依舊都高於 MAUI。這主要是由於小公司的敏捷性。Microsoft 現在高度官僚主義，任何反饋或變化，即使是微小的，都需要廣泛的討論才能採取行動。這與 Avalonia 形成鮮明對比，Avalonia 可以非常快速地採用新功能，Uno Platform 溝通速度也非常快。在免費支援方面，Uno Platform 社群的回應次數與更為龐大的 MAUI 社群相當。但是 Uno Platform 通常可以更快的解決 bugs 並實現功能。
程式碼庫的易讀性和易於貢獻
Avalonia UI 擁有最乾淨的程式碼庫，大大降低了公眾貢獻的門檻。Uno Platform 和 .NET MAUI 的要複雜得多，可以從程式碼上看出這點。從長遠來看，複雜性的增加通常在維護和穩定性方面成本變得很高。在 Uno Platform 中，這種複雜性對於滿足體系結構目標和支援原生控制整合是必要的。
開發體驗
Avalonia UI 擁有最好的整體開發體驗。程式碼庫易於閱讀，使用 Rider 的開發除錯體驗是一流的(在其他 IDE 上則要差一些)。.NET MAUI 緊隨其後，因為它現在與 Visual Studio 的整合超過了所有的其他框架。由於需要在每個平臺上分別驗證/調整每個特性/檢視，.NET MAUI 在整體開發體驗方面存在不足。Uno Platform 的開發體驗很差，與 Visual Studio 的整合較少，編譯時間長，除錯也很困難。有關開發體驗的更多詳細資訊，請參閱 IDE 整合部分。
企業支援
乍一看，Microsoft 開發的 .NET MAUI 似乎擁有最強大的企業支援。然而，Microsoft 並沒有在這個專案上投入大量資源，根據 Microsoft 放棄 UI 框架的歷史，對 MAUI 的支援也存在不確定性。Avalonia 雖然最初是完全開源的，但現在得到了一些核心團隊成員的公司的支援。這為維持專案提供了良好的穩定性和收入衡量標準。但是，需要謹慎的是企業對其影響的增加以及程式碼庫閉源的進展。例如，合成渲染引擎現在不是可以修改的自由許可證（而其餘程式碼是 MIT 許可的），這一點會在 V11 正式版釋出後改回來。Uno Platform 憑藉創新和令人難以置信的溝通和回應次數，在企業贊助方面依然獨樹一幟。值得注意的是，它們與 Microsoft 有著合作以及密切的溝通。
Visual Studio 整合
沒有一個框架在 Visual Studio 整合方面有三星。這是因為 Visual Studio 歷來專注於 windows 平臺框架，如 WinForms、WPF、UWP 和 WinUI，並以不可擴充套件的方式對這些框架進行硬編碼支援。但是，.NET MAUI 的支援有了很大的改進（從釋出時幾乎無法使用開始）。Uno Platform 的 Visual Studio 整合還有很多需要改進的地方，顯然是三者中開發體驗較差的一個。這不是他們的錯，因為 Microsoft 不合理地支援使用 .xaml 檔案的任何其他專案型別。Visual Studio 中的 Avalonia 支援提供了可靠的預覽器支援，並且大多數功能都可以工作- 透過使用特殊的.axaml 副檔名 - 但 XAML 並不像其他 IDE（如 Rider）那樣流暢。
Visual Studio Code 整合
Uno Platform 團隊為Visual Studio Code 開發了一個擴充套件，支援開發，更重要的是，可以除錯行動和 Web 應用程式。這是 VS Code 工具向前邁出的一大步，而 VS Code 工具作為 C#/.NET 應用程式的 IDE 歷來對開發人員不友好。令人驚訝的是，該擴充套件還支援.NET MAUI 應用程式。Uno Platform 團隊確實在這方面邁出了一步，填補了 VS Code 支援 C#/.NET 應用程式方面長期存在的空白，因此 Uno Platform 在這款 IDE 整合方面獲得了三顆星的評價。Uno Platform 應用程式現在在 Visual Studio Code 中得到了最好的支援(除非在 Windows 上開發 WinUI，其中 Visual Studio 仍然是最好的)。請注意，這個擴充套件不是開源的。Avalonia UI 於 2023 年 7 月公佈 了一個支援 XAML 預覽和程式碼補全的Visual Studio Code 外掛預覽版。這使得 Avalonia UI 在 Visual Studio Code 中更易於開發，並將使其成為一個可選的 IDE。
設計工具整合
目前只有 Uno Platform 支援設計工具(Figma)來構建 UI。這種支援是由一個閉源 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 上尤其如此，Uno Platform 在上次測試（2021 年）時執行極差。如今，使用 macCatalyst 構建 macOS 應用通常會更好，因為 Uno Platform 對 iOS 的支援明顯更好、更完整。Skia 後端也適用於所有桌面平臺(甚至是舊版本的 Windows)。請記住(如效能部分所述)Uno Platform 在 Android 上的效能不如 iOS。Avalonia UI 遠遠領先於 macOS 和 Linux 桌面平臺的其他框架。Avalonia 在 Windows 桌面平臺上的得分也很高，但沒有使用原生 UI 工具包，所以得分比 Uno Platform 低一些。行動端和 Web 支援是 11.0 版中新發布的，可能需要一些時間才能穩定下來，因此目前得分較低。Avalonia 的 Web 實現呈現為 HTML5 canvas。這永遠不會像 Uno Platforms 架構那樣好，在 Uno Platforms 中，它完全整合為 HTML 元素。.NET MAUI 根本不支援 Linux 或 Web。在平臺覆蓋面上明顯不如其他兩個框架。
各平臺框架推薦
在每個平臺上，都有效能最佳的框架。這也是主觀的； 但是，總體而言，評估應該是正確的，並考慮到所有的因素。
| 平臺 | 最佳框架 | |
|---|---|---|
| Windows | WPF/WinUI | |
| macOS |  |
Avalonia UI |
| Linux | ||
| Android | ||
| iOS |  |
|
| Web/Wasm |
如果一個應用程式隻需要用於桌面平臺，Avalonia 是一個非常好的選擇。它對 Windows 的支援是一流的，只是因為不是原生 UI，所以排在 WinUI 或 WPF 之後。然而，Avalonia 在桌面應用程式中沒有明顯的短板，許多桌面應用程式已經在使用它了。事實上，Avalonia 甚至支援在 WPF 中無法完成的操作，例如在 DirectX 表面上覆蓋 XAML 控制項。
如果應用程式需要跨平臺，可以先用 WinUI 或 WPF 編寫。在 Windows 上使用 WPF 程式碼庫可以很好地轉換為 Avalonia，但仍然需要三種不同的 XAML 變體。出於這個原因，通常最好使用 WinUI，因為它可以與 Uno Platform 的程式碼 100%共享。這樣就只需要兩種 XAML 變體。
另請注意：
- Web/Wasm 是 Uno Platform 的一個明顯優勢。由於架構差異（完全使用 Skia 渲染），Avalonia 很難在這個方面競爭。
- Avalonia UI 更像是 Flutter 的競爭對手。它使用 Skia（或者選用 Windows 上的 Direct2D）在每個平臺上完全渲染自己。這比 UnoPlatform 有很大的效能優勢，尤其是在 macOS 和 Android 上。透過這種方式，Avalonia 擁有所有框架中最純粹的架構和最低的社群參與門檻。
- Avalonia UI 被定位為下一代 WPF，它重新實現了大部份功能。Avalonia 從 WPF(Grid， text formatting)和 WinUI (ItemsRepeater， touch input APIs)中汲取思想和程式碼，同時仍然有一些其他 XAML 框架中沒有的獨特想法(在某些方面更接近 CSS 的進階樣式系統)。它現已為桌面應用開發人員準備就緒，尤其是那些已有 WPF 程式碼的開發人員。對於 UWP/WinUI 開發人員來說，這個過渡不太平滑，但在版本 11 中新增了 UWP/WinUI 的最新功能以改進過渡。對於不想變更現有 WPF 程式碼的企業應用程式，Avalonia 還提供了 Avalonia XPF，它在 Avalonia 渲染引擎之上實現了開源的 WPF 程式碼庫。
- .NET MAUI 特意沒有列為任何平臺最佳方案。它對於沒有複雜 UI 的小型應用程式最有用。即便是在中等複雜程度的應用程式中，它的實用性以及在不同平臺之間共用程式碼的能力，很快就要落後於其他的框架。然而，在某些業務線或更簡單的應用程式中，MAUI 可能是更好的選擇。MAUI 最近還能夠同時託管 Blazor 和 Avalonia UI，這為某些場景提供了一個有趣的選擇。
- Windows 10 之前的版本最合適的選擇是 Avalonia。雖然 Uno Platform 也有依託 Skia 的解決方案，但它在功能，穩定性和完整性方面遠遠落後。
- 如上表所示，使用兩種 XAML 方言（dialects of 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?
結論
我們花費了數年時間才走到這一步，但我們終於有了一些涵蓋所有用途的強大的 .NET UI 框架。有趣的是，這些框架都發展了一些各自特有且幾乎互補的功能。您可能想要嘗試的所有內容都包含在其中一種方法中。今天，我們可以編寫執行良好的跨平臺 XAML/C# 應用程式。大多數這項技術（除了 UI 層）都是基於 Mono 的，所以大部分功勞都歸功於 Xamarin。
每個框架所取得的成就都是了不起的。然而，沒有一個在所有平臺上都佔據主導地位，每個框架都有自己的優勢和劣勢。Uno Platform 源自於 Android/iOS，它在行動平臺和 web 端是最強的。Avalonia 源自桌面應用程式，在 Windows/Linux/macOS 上執行效果最好，但行動裝置支援上正在迅速發展。截至 2023 年，Uno Platform 的 macOS 支援充其量只是實驗性的，只能用於開發簡單的應用程式。截至 2023 年，Avalonia 最初僅支援行動裝置，但實際上在所有平臺上都更加穩定。不過，目前可能還是需要使用兩種不同的 UI 框架實現基於 XAML 的跨平臺 UI。
原文連結：https://github.com/robloo/PublicDocs/blob/master/XAMLFrameworkComparison.md
作者：czwy
出處：https://www.cnblogs.com/czwy/p/17572226.html
版權：本作品採用「署名-相同方式共享 4.0 國際」許可協議進行許可。