Avalonia UI的演進邏輯與Qt生態深度對比

一 引言：跨平台圖形介面的歷史張力與技術真空

在軟體工程的演進史中，跨平台圖形使用者介面（GUI）的開發始終是一個充滿了妥協、權衡與技術博弈的領域。長久以來，開發者被迫在「一次編寫，到處執行」的效率願景與「原生級效能與體驗」的品質要求之間做出艱難抉擇。在這一漫長的探索週期中，C++與其王牌框架Qt長期佔據了工業級、嵌入式及高效能桌面應用開發的統治地位。Qt以其底層的控制力、強大的元物件編譯器（MOC）以及對作業系統API的深度抽象，成為了衡量跨平台框架的黃金標準。

然而，隨著.NET生態系統的崛起，特別是 C# 語言在生產力、記憶體安全性以及執行時最佳化方面的長足進步，一個巨大的市場真空逐漸顯現：.NET開發者渴望一個能夠媲美Qt的跨平台能力，同時又能保留 C# 高效開發體驗的 UI 框架。微軟雖然先後推出了Windows Forms、WPF（Windows Presentation Foundation）、UWP以及最近的MAUI，但這些技術主要聚焦於Windows生態，或在跨平台策略上採取了「包裝原生控制項」（Wrapper）的路徑，導致了平台間表現不一致的頑疾。

正是在這種技術與市場的雙重張力下，Avalonia UI應運而生。本文將以Avalonia UI現任執行長Mike James的職業歷程為敘事線索，深度剖析從Qt時代的工業積澱到Avalonia時代的架構創新。我們將探討這位曾經的Qt開發者如何將對C++框架的深刻理解轉化為.NET生態中的顛覆性力量，並詳細對比Avalonia與Qt在渲染引擎、狀態管理、綁定機制等核心維度的技術差異。同時，本文將深入研究AvaloniaUI OÜ獨特的商業化路徑——如何在拒絕外部風險投資的前提下，透過「核心開源+商業閉源（XPF）」的混合模式，成功挑戰Qt在嵌入式與企業級市場的霸主地位。

二 軌跡的交匯：Mike James與跨平台哲學的演變

2.1 Qt時期的技術洗禮：工業級嚴謹性的初識

Mike James的技術生涯始於大學畢業後的第一份工作，彼時他置身於C++與Qt（他習慣稱之為「Cute」）構建的跨平台開發環境中 1。在那個時期，Qt已經是跨平台開發的代名詞，特別是在對效能要求極高的桌面與嵌入式領域。

這段經歷對Mike James產生了深遠的影響，主要體現在對「自繪UI」（Drawn UI）架構優勢的早期認知。Qt Widgets（當時的主流技術，即「Cute Four」時代）並不依賴作業系統的原生控制項來渲染按鈕或文字框，而是透過自身的繪圖引擎在畫布上繪製像素 1。這種設計哲學保證了應用程式在Windows、Linux和macOS上擁有絕對一致的視覺表現和行為邏輯，消除了「原生包裝器」常見的佈局錯位和API差異問題。

然而，C作為一種系統級語言，其記憶體管理的複雜性（儘管Qt引入了物件樹機制來輔助管理）和編譯速度的瓶頸，讓Mike James開始思考開發效率的重要性。他提到了自己「錯過了Qt轉向QML的階段」 1，這意味著他在Qt生態中的經驗主要集中在命令式的C邏輯上，而非後來引入的宣告式UI（QML）。這種「錯過」在某種程度上成為了後來擁抱XAML（.NET生態的宣告式語言）的契機，他意識到宣告式UI在建構複雜介面時的優越性，但同時也看到了強型別語言在大型工程維護中的必要性。

2.2 轉向.NET與Xamarin：行動端跨平台的探索與反思

離開Qt開發環境後，Mike James加入了Xamarin（後被微軟收購），這標誌著他從C++向C#/.NET生態的徹底轉型 1。Xamarin的使命是將.NET帶入iOS和Android開發領域，其核心技術是Mono執行時。

在Xamarin和隨後的微軟任職期間，Mike James深入接觸了行動端跨平台開發的另一條技術路線——原生控制項包裝（Native Wrapping）。Xamarin.Forms（以及後來的.NET MAUI）透過抽象層呼叫iOS的UIKit和Android的Views。這種方式雖然能提供「原生外觀」，但卻帶來了巨大的維護成本：

• API「最大公約數」問題

  ：框架只能暴露所有平台共有的功能，導致特定平台的特性難以利用。

• 渲染不一致

  ：同一個XAML佈局在不同OS上可能有完全不同的渲染結果，導致開發者需要編寫大量的平台特定程式碼（Custom Renderers）來修復UI bug。

這段經歷讓Mike James更加懷念Qt式的「自繪」模式。他意識到，.NET生態需要一個像Qt一樣完全控制渲染管線，但又能利用 C# 語言優勢的框架。這為他後來全身心投入Avalonia項目埋下了伏筆。

2.3 從貢獻者到掌舵人：Avalonia的商業化轉型

Avalonia（原名Perspex）最初由Steven Kirk於2013年創建，旨在創建一個跨平台的WPF 2。Mike James並非創始人，但他作為核心貢獻者深度參與了項目的早期發展，並在2019年創立了AvaloniaUI OÜ，出任CEO 3。

Mike James的加入不僅帶來了技術上的貢獻，更重要的是帶來了商業上的戰略視野。他面臨的核心挑戰是：如何在一個由巨頭（微軟、Google、Qt Company）把持的紅海市場中，讓一個開源項目生存並盈利？他拒絕了外部風險投資（VC）的誘惑 5，堅持認為引入VC會迫使公司追求短期增長而犧牲開源社區的利益。相反，他制定了一條「服務驅動產品，產品反哺開源」的獨特路徑，透過為企業解決WPF遷移的痛點（Avalonia XPF）來獲取資金，從而維持核心框架的獨立性和開源純度。

三 深度技術對決：Avalonia UI vs. Qt 架構解析

Avalonia常被視為「.NET版的Qt」，二者在設計哲學上有諸多相似之處（如自繪渲染），但在底層架構、語言特性及通訊機制上存在本質差異。本章將從微觀層面剖析這兩大框架的技術基因。

3.1 渲染引擎架構：Skia與QPainter的較量

3.1.1 Qt的渲染演進：從光柵化到場景圖

Qt的渲染歷史悠久且複雜，主要分為兩個階段：

• QPainter (Widgets)

  ：這是Qt傳統的命令式2D繪圖引擎 6。它透過統一的API抽象了底層的繪圖上下文（Windows GDI, X11, macOS Quartz）。雖然穩定，但在現代高解析度螢幕和複雜動畫場景下，QPainter基於CPU的光柵化能力逐漸顯露出瓶頸。

• Qt Quick / Scene Graph

  ：隨著QML的引入，Qt構建了基於場景圖（Scene Graph）的渲染管線。它能夠將UI元素構建為節點樹，並直接利用底層圖形API（OpenGL, Vulkan, Metal）進行GPU加速渲染。

3.1.2 Avalonia的渲染策略：SkiaSharp與平台抽象

Avalonia採取了更為現代和統一的策略，其渲染架構更接近於Google的Flutter：

• Skia為核心

  ：Avalonia預設使用Skia圖形庫（透過SkiaSharp綁定）作為跨平台渲染後端 7。Skia也是Chrome瀏覽器和Android介面的渲染引擎，這意味著Avalonia天生具備了高效能的2D向量繪圖能力。

• 像素級控制

  ：與MAUI依賴原生控制項不同，Avalonia透過Skia在作業系統的視窗（Window）上直接繪製所有UI元素。這種「自繪」機制保證了在Linux、Windows、macOS乃至WebAssembly上，像素的渲染結果是完全一致的 8。

• 風險管理與「保險策略」

  ：Mike James透露，Avalonia團隊為了規避SkiaSharp維護者單一的風險，曾在內部開發了自己的Skia綁定 7。這一細節展示了商業公司在技術選型上的成熟度——不僅追求效能，更關注供應鏈安全。

• 未來架構（Impeller與GPU優先）

  ：受到Flutter轉向Impeller渲染器的啟發，Avalonia v12計劃引入實驗性的GPU優先渲染管線 7。目前的Skia主要依賴CPU進行路徑光柵化（儘管可以上傳紋理到GPU），在高負載下可能導致掉幀。新的渲染架構旨在消除著色器編譯引起的卡頓（Jank），利用GPU的計算能力直接處理幾何圖形，這將使Avalonia在動畫流暢度上進一步逼近甚至超越原生Qt Quick的表現。

3.2 通訊與狀態管理：編譯綁定 vs. 信號與槽

3.2.1 Qt的信號與槽（Signals & Slots）與MOC

Qt最引以為傲的機制是信號與槽，它解耦了物件間的通訊。

• 元物件編譯器（MOC）

  ：由於C缺乏原生的反射機制，Qt必須透過MOC預處理頭檔，生成包含元資料的額外C程式碼，以支援執行時的方法查找和連接 10。

• 效能代價

  ：雖然MOC非常強大，但信號槽的呼叫（特別是跨執行緒的佇列連接）涉及參數的編組（Marshalling）和記憶體複製，存在不可忽視的執行時開銷。此外，MOC增加了建置系統的複雜性，使得Qt項目難以與標準C++建置工具鏈無縫整合。

3.2.2 Avalonia的編譯綁定（Compiled Bindings）

Avalonia繼承了WPF的MVVM（Model-View-ViewModel）模式，但徹底解決了WPF資料綁定的效能痛點。

• 反射的詛咒

  ：傳統的WPF綁定依賴執行時反射（Reflection）來解析屬性路徑，這在處理包含成千上萬個物件的大型列表時，會導致嚴重的效能下降和記憶體壓力。

• 編譯綁定的革新

  ：Avalonia引入了x:CompileBindings 11。編譯器在建構階段解析XAML中的綁定路徑（如），並將其直接編譯為強型別的 C# 程式碼。這意味著執行時不再需要反射，綁定的執行速度接近於手寫的 C# 賦值程式碼。

• 型別安全

  ：與Qt QML（基於JavaScript的動態型別）相比，Avalonia的編譯綁定在編譯時就能發現型別不匹配錯誤（例如將字串綁定到整型屬性），極大地提升了大型企業級應用的開發穩定性和可維護性 1。

• 響應式程式設計（ReactiveUI）

  ：Avalonia與ReactiveUI深度整合，支援基於Rx.NET的函數響應式程式設計（FRP）。相比於Qt的命令式信號處理，ReactiveUI允許開發者以宣告式的方式組合非同步資料流，處理複雜的事件序列（如「防抖」、「節流」、「合併」），這在現代互動密集的應用中具有顯著優勢 13。

3.3 邏輯樹與樣式系統：CSS化的XAML

Avalonia對WPF的邏輯樹（Logical Tree）和視覺樹（Visual Tree）概念進行了擴展，引入了極具創新性的樣式選擇器系統 15。

• 類CSS選擇器

  ：在Qt中，QSS（Qt Style Sheets）雖然存在，但與QML的樣式系統是割裂的。Avalonia允許開發者在XAML中使用類似CSS的選擇器，如Style Selector="Button.primary:pointerover TextBlock"。這使得樣式的定義與控制項結構解耦，設計師可以像寫Web頁面一樣定義全域主題，而無需修改控制項程式碼 17。

• 偽類（Pseudo-classes）

  ：Avalonia的樣式系統支援自訂偽類。開發者可以在 C# 程式碼中觸發偽類狀態（如:invalid, :syncing），UI會自動響應樣式變化。這種機制比Qt的屬性狀態綁定更為靈活和解耦。

3.4 架構對比總結表

下面的表格總結了Avalonia UI與Qt Framework在關鍵技術維度的對比：

四 商業決策與創業故事：開源與生存的辯證法

Mike James領導下的AvaloniaUI OÜ並非典型的矽谷創業故事。它沒有巨額融資，沒有燒錢擴張，而是走出了一條「技術變現反哺開源」的務實路線。

4.1 拒絕外部資本：保持獨立的代價與收益

在Avalonia初創期，團隊面臨著開源項目普遍的困境：核心開發者需要養家糊口，單純依靠捐贈無法維持全職開發。儘管有投資人拋出橄欖枝，Mike James及其團隊最終決定不接受外部風險投資 5。

• 決策邏輯

  ：引入VC意味著必須追求高成長和退出機制（IPO或被收購），這往往會導致公司在後期對開源社群進行「收割」（如修改開源協議）。Mike James希望Avalonia保持MIT協議的純粹性，確立了「可持續開源」（Sustainable Open Source）的願景。

• 自造血模式

  ：公司透過提供企業級支援協議（SLA）和客製化開發服務（Development Services）賺取了第一桶金 18。許多從WPF遷移到.NET Core的企業需要專家指導，Avalonia團隊利用這一需求實現了收支平衡。

4.2 從服務到產品：商業模式的進化

單純依靠賣「人時」的服務模式難以規模化（Scaling）。Mike James敏銳地捕捉到了市場中的「棕地」（Brownfield）機會——那些不僅需要新開發，更需要維護和遷移舊系統的企業。

• Avalonia XPF的誕生

  ：這是公司最關鍵的戰略轉折點。團隊意識到，雖然Avalonia UI很強大，但重寫數百萬行WPF程式碼對許多企業來說是不可能的。於是，他們開發了Avalonia XPF——一個與WPF二進位相容的商業產品 19。

• 商業邏輯

  ：XPF是閉源且收費的。它利用了Avalonia的跨平台渲染引擎，但在上層完全模擬了WPF的API。企業無需重寫程式碼，甚至無需重新編譯部分依賴，就能將WPF應用執行在Linux和macOS上。這種「降維打擊」不僅解決了企業的歷史遺留問題，也為AvaloniaUI OÜ提供了高利潤率的標準化產品收入，從而有資金僱用更多的核心開發者維護開源版Avalonia UI。

4.3 戰略融資：Devolutions的300萬贊助

2025年，Avalonia宣布獲得Devolutions提供的300萬美元贊助 21。

• 非股權融資

  ：這筆交易的關鍵在於它不是股權投資，而是「贊助」（Sponsorship）。Devolutions作為Avalonia的重度用戶（其遠端桌面管理軟體基於Avalonia構建），需要確保這個框架的長期穩定和演進。

• 資金用途

  ：這筆資金被指定用於改進文件、開發工具（Accelerate）以及提升核心框架的穩定性。對於Mike James來說，這是對其「不賣身」策略的最大肯定——透過證明技術的不可替代性，讓生態中的受益者自願為基礎設施買單。

五 戰略級產品：Avalonia XPF的技術護城河

Avalonia XPF不僅僅是一個商業產品，它代表了Avalonia在技術架構上的極致靈活性，也是其區別於Qt、Flutter等競爭對手的最大護城河。

5.1 二進位相容的魔法：如何實現WPF的跨平台

WPF長期以來被認為是Windows獨佔的，因為它深度依賴DirectX和User32.dll。Avalonia XPF打破了這一神話。

• 架構替換

  ：XPF透過替換WPF底層的PresentationCore和MilCore（WPF的渲染核心），將WPF的繪圖指令重定向到Avalonia的Skia渲染後端 20。這意味著上層的WPF控制項（Button, DataGrid等）並不「知道」自己執行在非Windows環境下。

• 第三方控制項支援

  ：這是XPF最恐怖的殺手鐧。由於保持了API和二進位相容性，XPF能夠執行DevExpress、Telerik、Infragistics等第三方廠商的WPF控制項庫 20。這些控制項庫是企業級開發的基石，Qt完全無法觸及這一領域（因為這些庫是基於.NET的）。XPF使得Avalonia能夠直接繼承WPF二十年積累的龐大生態資產。

5.2 市場定位：收割WPF的存量市場

Mike James將目光鎖定在「WPF遺留資產遷移」這一特定的市場切片上。

• 典型客戶

  ：如施耐德電氣、特斯拉、波音等公司，擁有海量的內部WPF工具。隨著雲端運算和DevOps的普及，這些公司迫切需要將這些工具遷移到Linux容器中，或者讓研發人員在macOS上使用這些工具。

• 成本對比

  ：重寫一個中型WPF應用可能需要數年時間和數百萬美元。而購買XPF許可證並進行簡單的適配（主要處理P/Invoke呼叫），成本僅為重寫的幾十分之一 26。這種巨大的ROI（投資報酬率）使得XPF在企業市場極具吸引力。

5.3 許可模式的演變與爭議

XPF的推出並非一帆風順，其許可模式經歷了多次調整。

• 初期困惑

  ：最初XPF採用「按應用、按平台」收費，導致計算複雜，且對於小微企業價格過高，引發了社群關於「Avalonia變得不再自由」的擔憂 27。

• 簡化與妥協

  ：響應社群回饋，Mike James調整了策略，推出了包含所有桌面平台的單一許可證，並承諾核心框架永遠開源 29。這種快速的市場響應機制體現了Avalonia作為創業公司的靈活性。

六 生態擴張：從桌面霸主到嵌入式新貴

Avalonia UI的影響力已經超越了單純的桌面開發，正在向嵌入式、Web及行動端全域滲透。

6.1 企業級桌面的統治力：JetBrains的背書

在桌面端，Avalonia獲得了一個里程碑式的勝利：JetBrains的背書。

• IDE的UI基石

  ：JetBrains在其著名的.NET效能分析工具dotMemory和dotTrace中使用了Avalonia 30。甚至其旗艦IDE Rider的某些各種跨平台視圖也是基於Avalonia構建的。

• 象徵意義

  ：JetBrains作為全球最頂級的開發工具廠商，對UI框架的效能、穩定性和可擴展性有著極其苛刻的要求。他們的選擇向全球開發者傳遞了一個強烈信號——Avalonia已經具備了支撐世界級複雜應用的能力。

6.2 嵌入式Linux的突圍：挑戰Qt的腹地

嵌入式Linux一直是Qt的傳統腹地，但Avalonia正在撕開缺口。

• DRM (Direct Rendering Manager) 支援

  ：Avalonia支援Linux DRM模式，這意味著它可以不依賴X11或Wayland桌面環境，直接在幀緩衝（Framebuffer）上渲染UI 32。

• 施耐德電氣案例

  ：施耐德選擇Avalonia將其Harmony系列HMI（人機介面）遷移到Linux。原因在於 C# 的高開發效率結合 Avalonia 的高效能渲染，使得在樹莓派級別的硬體上也能實現流暢的、類似智慧型手機的觸摸體驗，且無需支付Qt高昂的執行時版稅（Runtime Royalties）33。

• 效能最佳化

  ：針對低功耗設備，Avalonia進行了大量最佳化，包括裁剪未使用的程式碼（Trimming）以減小包體積 34，以及透過SIMD指令集加速Skia的繪圖操作。

6.3 行動端與Web的追趕：2025年的現狀

相比於桌面端的強勢，Avalonia在行動端（iOS/Android）和Web（WebAssembly）仍處於追趕階段 1。

• 行動端

  ：v11版本帶來了對iOS和Android的正式支援。Avalonia的優勢在於「真·跨平台」——UI程式碼復用率可達99%，且外觀完全一致。但在呼叫原生API（如相機、感測器）的便利性上，生態豐富度暫不如MAUI或React Native。

• WebAssembly (WASM)

  ：Avalonia支援將整個應用編譯為WASM執行在瀏覽器中。雖然實現了「一套程式碼覆蓋Web」，但WASM的載入體積（通常幾十MB）和首屏啟動速度仍是挑戰。Google Play在2025年提出的16KB頁面對齊要求等新標準，也迫使Avalonia團隊持續最佳化底層記憶體佈局 35。Qt也在WASM上發力 36，二者在Web端的競爭更多是關於二進位體積和啟動速度的硬核比拼。

七 社區博弈與未來挑戰：v12、Accelerate與開源的可持續性

7.1 Avalonia Accelerate：生產力工具的商業化

為了進一步增強盈利能力並補齊生態短板，Avalonia推出了Accelerate套件 37。

• 功能矩陣

  ：包含進階的可視化設計器、WebView控制項、高效能媒體播放器以及樹形資料網格（TreeDataGrid）的增強版。

• 商業與開源的邊界

  ：這是一個敏感的領域。TreeDataGrid等組件原本是開源的，後來被歸入Accelerate（儘管仍有免費版或許可變更），這在社群引發了關於「功能剝離」的爭議 27。Mike James需要小心翼翼地平衡付費用戶的特權與開源用戶的權益，避免出現類似Redis或Elasticsearch的許可協議危機。

7.2 技術路線圖：v12與未來十年

面向2025年及以後，Avalonia的技術演進方向非常清晰：

• GPU優先渲染（Impeller-like）

  ：v12將引入新的渲染架構，旨在徹底解決Skia在極端場景下的效能瓶頸，利用GPU計算能力處理2D路徑，為高刷新率螢幕提供極致流暢體驗 7。

• 行動端成熟化

  ：繼續完善Android和iOS的平台整合，目標是讓Avalonia成為.NET開發者構建「超級App」的首選，無論是在桌面還是行動端。

7.3 結論：後發者的逆襲邏輯

回顧Mike James從Qt用戶到Avalonia創造者的歷程，我們看到的是一個經典的「後發者逆襲」故事。Avalonia沒有Qt三十年的歷史包袱，也沒有微軟MAUI那樣的內部政治鬥爭。它利用了.NET Core的跨平台紅利，結合了Skia的渲染優勢，並透過XPF這一神來之筆解決了商業化難題。

在2025年的技術版圖中，Avalonia已不再僅僅是WPF的替代品，而是一個具備獨立哲學、強大生態和自我造血能力的頂級UI框架。它向行業證明：在巨頭林立的時代，一個由社區驅動、商業閉環的開源項目，依然能夠憑藉技術創新和精準的市場定位，開闢出一片屬於自己的廣闊天地。

資料來源說明：本文基於截至2025年10月的公開資料、技術文件、部落格文章及社群討論整理而成。所有引用均已於文中標示。

創新敢破行慣

，贊3

引用的著作

1. Episode 120 - Inside Avalonia's Cross-Platform UI Toolkit and the Quest for Quality Documentation with Mike James - The Modern .NET Show, 訪問時間為 十二月 10, 2025， https://dotnetcore.show/episode-120-inside-avalonias-cross-platform-ui-toolkit-and-the-quest-for-quality-documentation-with-mike-james/
2. Avalonia (software framework) - Wikipedia, 訪問時間為 十二月 10, 2025， https://en.wikipedia.org/wiki/Avalonia_(software_framework)
3. About Avalonia UI, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/about
4. 10 years of Avalonia!, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/10-years-of-avalonia
5. Supporting Avalonia UI Growth - Seeking constructive feedback and suggestions #11279, 訪問時間為 十二月 10, 2025， https://github.com/AvaloniaUI/Avalonia/discussions/11279
6. Performance of QPainter? - Qt Forum, 訪問時間為 十二月 10, 2025， https://forum.qt.io/topic/160428/performance-of-qpainter
7. The Future of Avalonia's Rendering, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/the-future-of-avalonia-s-rendering
8. Avalonia vs .NET MAUI: the pragmatic choice for fast, unified .NET apps, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/maui-compare
9. Avalonia Partnering with Google's Flutter Team to Bring Impeller Rendering to .NET, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/avalonia-partners-with-google-s-flutter-t-eam-to-bring-impeller-rendering-to-net
10. Does large use of signals and slots affect application performance? - Stack Overflow, 訪問時間為 十二月 10, 2025， https://stackoverflow.com/questions/10838013/does-large-use-of-signals-and-slots-affect-application-performance
11. Improving Performance | Avalonia Docs, 訪問時間為 十二月 10, 2025， https://docs.avaloniaui.net/docs/guides/development-guides/improving-performance
12. Compiled Bindings - Avalonia Docs, 訪問時間為 十二月 10, 2025， https://docs.avaloniaui.net/docs/basics/data/data-binding/compiled-bindings
13. ReactiveUI not a cup of tea worth drinking? Anything else with bad taste to never touch (again)? : r/AvaloniaUI - Reddit, 訪問時間為 十二月 10, 2025， https://www.reddit.com/r/AvaloniaUI/comments/1h78mc1/reactiveui_not_a_cup_of_tea_worth_drinking/
14. greater/deeper use of Rx & observables · AvaloniaUI Avalonia · Discussion #6312 - GitHub, 訪問時間為 十二月 10, 2025， https://github.com/AvaloniaUI/Avalonia/discussions/6312
15. Control Trees - Avalonia Docs, 訪問時間為 十二月 10, 2025， https://docs.avaloniaui.net/docs/concepts/control-trees
16. UI Composition | Avalonia Docs, 訪問時間為 十二月 10, 2025， https://docs.avaloniaui.net/docs/concepts/ui-composition
17. What are your experiences with the various UI frameworks? : r/csharp - Reddit, 訪問時間為 十二月 10, 2025， https://www.reddit.com/r/csharp/comments/1cnxwpg/what_are_your_experiences_with_the_various_ui/
18. How we make money - Avalonia UI, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/handbook/how-we-make-money
19. AvaloniaUI/Avalonia: Develop Desktop, Embedded, Mobile and WebAssembly apps with C# and XAML. The most popular .NET UI client technology - GitHub, 訪問時間為 十二月 10, 2025， https://github.com/AvaloniaUI/Avalonia
20. Avalonia XPF - Take your WPF apps cross-platform., 訪問時間為 十二月 10, 2025， https://avaloniaui.net/xpf
21. Avalonia Accelerate Backed by $3 Million Deal from Devolutions - Press release - Devolutions, 訪問時間為 十二月 10, 2025， https://devolutions.net/company/press-release/avalonia-accelerate-backed-by-3-million-deal-from-devolutions/
22. Three-Year Sponsorship Accelerates Avalonia's Open-Source Roadmap, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/three-year-sponsorship-accelerates-avalonia-s-open-source-roadmap
23. .NET MAUI is Coming to Linux and the Browser, Powered by Avalonia - Avalonia UI, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/net-maui-is-coming-to-linux-and-the-browser-powered-by-avalonia
24. Welcome | Avalonia Docs, 訪問時間為 十二月 10, 2025， https://docs.avaloniaui.net/xpf/welcome
25. Introducing Hybrid XPF: Bridging Avalonia and WPF Controls, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/introducing-hybrid-xpf-bridging-avalonia-and-wpf-controls
26. Avalonia XPF, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/handbook/avalonia-xpf
27. Avalonia is getting less free (as in freedom, and as in price). - Reddit, 訪問時間為 十二月 10, 2025， https://www.reddit.com/r/AvaloniaUI/comments/1k1pozw/avalonia_is_getting_less_free_as_in_freedom_and/
28. When will wpf be cross-platform · Issue #3952 · dotnet/wpf - GitHub, 訪問時間為 十二月 10, 2025， https://github.com/dotnet/wpf/issues/3952
29. Avalonia XPF - License Changes - Avalonia UI, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/avalonia-xpf-license-changes
30. JetBrains Rider: The only cross-platform IDE for Avalonia, 訪問時間為 十二月 10, 2025， https://www.jetbrains.com/lp/rider-avalonia/
31. Is AvaloniaUI good option for multiplatform GUI in 2024? : r/dotnet - Reddit, 訪問時間為 十二月 10, 2025， https://www.reddit.com/r/dotnet/comments/1al38a1/is_avaloniaui_good_option_for_multiplatform_gui/
32. What is the difference between Avalonia Linux DRM/embedded Linux/Android? #17088, 訪問時間為 十二月 10, 2025， https://github.com/AvaloniaUI/Avalonia/discussions/17088
33. Unleashing .NET on Embedded Linux - Avalonia UI, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/unleashing-net-on-embedded-linux
34. Welcome to the New Era of App Development: Introducing Avalonia v11, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/welcome-to-the-new-era-of-app-development-introducing-avalonia-v11
35. Preparing Your Avalonia Apps for Android's 16 KB Page Size Requirement, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/blog/preparing-your-avalonia-apps-for-android-s-16-kb-page-size-requirement
36. Qt and WebAssembly Takes Client Development Mainstream to the Web | #QtWS22, 訪問時間為 十二月 10, 2025， https://www.qt.io/resources/videos/qt-and-webassembly-takes-client-development-mainstream-to-the-web
37. Welcome to the Avalonia Accelerate Docs, 訪問時間為 十二月 10, 2025， https://docs.avaloniaui.net/accelerate/welcome
38. Avalonia Accelerate, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/accelerate
39. Avalonia Accelerate, 訪問時間為 十二月 10, 2025， https://avaloniaui.net/handbook/avalonia-accelerate