深入了解通用應用程序（Universal Application）

通用應用程序（Universal Application）的基石之一是.NET Native。這是微軟的“云端編譯器”，它能夠把Windows應用商店中的程序編譯成所支持的每種設備的機器代碼。

.NET Native不使用JIT編譯器，其結果是，用戶可以在冷啟動中節約最多達60%的時間，而在熱啟動中則最多達40%。編譯器將查看整個應用程序，從而可以去掉用不到的功能，這在一些應用程序中可以節約最多達30%的空間。

第二塊基石是叫做“自適應應用程序（adaptive app）”的概念。這個概念是指當應用程序所運行的設備上的一些功能和API并不存在時，仍然能夠正常運行。只要遵循正確的模式，原生編譯器就會去掉對那些在用戶設備上不存在的API的引用。

.NET Native的另一個好處是，它允許微軟以更快的節奏運轉。應用程序靜態鏈接到大部分框架庫，這意味著你不太可能看到已發布應用程序的破壞性改動。開發人員必須明確選擇可能破壞應用程序的新版本，這意味著微軟不必過于擔憂破壞性改動的問題。

最后，.NET Native使得微軟在框架庫中發現安全漏洞或者需要支持新的CPU架構時，可以自動重新編譯應用程序。后者不僅僅停留在理論上，微軟透露他們計劃在今年秋天支持第四代CPU架構。

調試的工作流程

默認情況下，Windows 10應用程序在調試模式會編譯成IL，而在發布模式會編譯成原生代碼。這可以通過項目屬性窗口中的編譯器標志來改變。開發人員大部分時間應該使用調試模式，因為.NET Native的構建時間明顯要更長。

在設備上調試時，Visual Studio需要推送一個額外的庫CoreCLR。這包括許多應用程序通常不需要的功能，所以當應用程序從Windows應用商店安裝時不包括這個庫。

版本號設置

在通用應用程序中，將不允許開發人員使用四位數字的版本號碼。雖然開發人員還可以使用前三位數字，但是第四位數字保留由.NET Native編譯器使用。

任何CPU

對通用應用程序，開發人員不能夠指定任何CPU（Any CPU）為目標架構。微軟要求應用程序的開發人員確實已針對目標硬件測試了他們的應用程序。

AppX打包選項

調試版本的程序包包含基于MSIL的庫。調試模式的構建不適合設備上的旁加載（side-loading），因為設備上可能沒有安裝框架庫的正確版本。

發布版本的程序包包含原生編譯的庫，帶有發布所需的元數據。

運行時指令（rd.xml）

運行時指令（Runtime Directives）用于告訴編譯器你要通過反射訪問什么類型。如果你沒有正確地列出類型，優化器可能會刪除類型的元數據、甚至類型本身。

在運行時指令文件中指定過多信息的壞處是，你會無謂地增加應用程序的大小。如果這一點不成問題，那么你可以保留所有的默認設置。

.NET Native的最佳實踐

在調試模式開發你的應用程序，可以獲得更快的構建和測試周期。

定期在發布模式進行測試，以確保不會引入涉及.NET Native的錯誤。不要等到項目臨結束時，才來解決原生的問題。

.NET Native的工作計劃

對于將來的計劃，微軟打算減少原生編譯應用程序的構建時間。他們也想要找到分享框架程序包的辦法，從而減小應用程序在硬盤上的大小。

事后調試

如果你的應用程序在你無法訪問的設備上崩潰，你就要從開發者門戶獲取調試符號（debug symbols）。使用這些符號需要匹配的源代碼，因此請確保你有一個匹配的分支。

庫

Windows 10通用應用程序與Windows 8.1將具有相同的外圍應用（surface area）。“是的，WCF將可以在Windows Phone上運行。”未來版本的通用應用程序將通過NuGet隨時發布。

便攜式類庫如果以.NET核心4.5.1為目標，則將照常工作。

行動呼吁

微軟希望盡快知道在普通編譯和.NET Native編譯的行為之間是否有任何不同。請把問題報告到dotnetnative@microsoft.com。

欲知更多關于通用應用程序的信息，請觀看Channel 9的視頻， 深入了解XAML和.NET通用Windows應用程序的開發 。

查看英文原文： Deep Dive into Universal Applications