博客 / 詳情

返回

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中的綁定路徑（如{Binding Customer.Name}），並將其直接編譯為強類型的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在關鍵技術維度的對比：

維度 Avalonia UI Qt Framework 深度洞察
核心語言 C# /.NET C++ / QML (JavaScript-like) C#提供了更高的內存安全性和開發效率；C++在極端資源受限的嵌入式設備上仍有微弱的性能優勢。
UI描述語言 XAML QML /.ui (XML) / C++ XAML結合編譯綁定提供了靜態類型安全 1；QML更靈活但缺乏編譯時檢查，易在大型項目中引入隱蔽Bug。
渲染後端 Skia (當前), GPU First/Impeller (未來 v12) QPainter, OpenGL, Vulkan, Metal Avalonia的Skia方案保證了跨平台一致性；Qt允許更底層的圖形API訪問，但在不同OS上的一致性維護成本較高。
通信機制 Compiled Bindings (編譯時), ReactiveUI Signals & Slots (運行時/MOC) 編譯綁定消除了反射開銷，性能優於基於MOC的動態查找；ReactiveUI在處理異步流時比信號槽更具表現力。
二進制兼容性 極高 (.NET Standard/Core) 低 (需針對每種編譯器/平台重新編譯) .NET的中間語言（IL）特性使得Avalonia庫的分發（NuGet）遠比Qt的C++庫鏈接簡單，尤其是在CI/CD流程中。
樣式系統 CSS-like XAML Styles QSS / QML Styling Avalonia將CSS的靈活性帶入了原生桌面開發，樣式複用性極強。

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

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月的公開資料、技術文檔、博客文章及社區討論整理而成。所有引用均已在文中標識。

引用的著作

  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
軟件工程
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.