對於開發 .NET MAUI 的工程師來說，底層運行時 Runtime 的變更是一個極其重大的技術轉折。在 .NET 11 的開發週期中，微軟正式將 .NET MAUI 在 Android、iOS 與 Mac Catalyst 上的預設運行時從 Mono 遷移至 CoreCLR。這不僅僅是更換一個執行引擎，而是將行動端開發的基礎設施與伺服器端、桌面端全面統一。
理解運行時的差異
在進入細節前，我們需要先釐清 Mono 與 CoreCLR 的角色。Mono 是一個開源的 .NET 實作，在過去十五年中，它讓 .NET 能在行動裝置上運行，其核心特點是輕量化且對行動端環境有極佳的適配性。而 CoreCLR 則是現代 .NET（如 .NET 6/7/8/9）的核心運行時，也是 ASP.NET Core 等高效能雲端服務背後的引擎。
將 CoreCLR 引入行動端，意味著行動端 App 現在能使用與伺服器端相同的垃圾回收機制 GC、即時編譯 JIT 以及診斷工具。這種統一化能大幅降低開發者在不同平台間切換時的認知負荷，並讓行動端 App 獲益於 CoreCLR 近年來的效能優化。
效能表現與實際影響
這次遷移對 App 效能的影響在不同平台上有所差異。在 iOS 與 Mac Catalyst 上，CoreCLR 的執行速度普遍優於原先的 Mono。而在 Android 平台上，啟動時間與安裝包大小與 Mono 相比，差距維持在 10% 以內，表現相當穩定。
除了執行速度，開發體驗的提升更為明顯。由於 CoreCLR 的統一，開發者現在可以直接在行動裝置上使用 dotnet-trace 和 dotnet-counters 等診斷工具。這在過去是極其困難的，現在你可以在手機上直接監控記憶體使用量或追蹤效能瓶頸，就像在伺服器端除錯一樣。
此外，這次變更也為 NativeAOT（原生提前編譯）在 Android 上的落地打下基礎。NativeAOT 能夠將程式碼直接編譯為機器碼，跳過 JIT 編譯過程，進而大幅縮短啟動時間並降低記憶體佔用。
開發流程的變更與限制
從 .NET 11 Preview 6 開始，CoreCLR 已成為唯一的選擇，原先允許開發者手動切換回 Mono 的建置屬性已被移除。這意味著所有針對 net11.0-android、net11.0-ios 或 net11.0-maccatalyst 的建置都將強制使用 CoreCLR。
需要注意的是，Blazor WebAssembly 並不受此影響，它將繼續使用 Mono，因為 WebAssembly 的執行環境有其特殊性。
在開發工具方面，雖然 Debugging 與 Hot Reload（熱重載，允許在不重新啟動 App 的情況下更新程式碼）已在 Visual Studio 與 VS Code 中恢復運作，但 XAML Hot Reload 以及部分 iOS 路徑仍處於完善階段，開發者在預覽版本中可能會遇到一些不穩定現象。
工程實務建議：如何驗證你的 App
對於將 App 升級至 .NET 11 的工程師，不能單純假設效能會全面提升或下降，必須進行實測。建議採取以下驗證步驟：
首先，針對 Release 模式進行建置並發布，在真實裝置上測量 Cold Startup（冷啟動，App 完全關閉後啟動）與 Warm Startup（暖啟動，背景仍有殘留後啟動）的時間，並與 .NET 10 的基準數據對比。
其次，檢查安裝包大小，比對 Android 的 APK/AAB 檔案以及 iOS 的 IPA 檔案是否有異常增長。
最關鍵的是驗證第三方函式庫。由於 CoreCLR 的運行機制與 Mono 不同，任何大量使用 Reflection（反射，在執行期檢查物件型別）或 Dynamic Code Generation（動態程式碼生成）的套件，都可能在遷移後出現行為異常，必須重點測試。
來源：devblogs.microsoft.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。