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