使用 .NET 平臺，如何玩轉 Universal Windows 應用？

2015年7月30日

本文做者是 Managed Languages 團隊項目經理 Lucian Wischik。

不久前，Visual Studio 2015上新增 Windows 10 應用的開發工具——Universal Windows App開發工具。這個發佈擁有重大意義：開發者可利用最新的 .NET 技術開發 Universal Windows Platform (「UWP」) 應用，這些應用程序可運行在任一款 Windows 設備上——Windows 手機、平板電腦或者筆記本電腦、PC 機、Xbox 遊戲機，以及 Windows 新出的 HoloLens、Surface Hub 和 Raspberry Pi 2（IoT 設備）等等。

安裝 UWP 工具

開發者可下載安裝免費的 VS2015 的社區版，該版本默認安裝 UWP 工具。如需安裝專業版或是企業版，可從 VisualStudio.com 處下載安裝。在安裝過程當中，選擇「Custom（自定義）」安裝 Universal Windows Apps 開發工具。

若是已經安裝了 Visual Studio 2015，有兩種方式得到 Universal Windows Apps 開發工具：

• 下載並運行 Windows Tools installer。

• 從控制面板打開「程序和功能（Programs and Features）」，選擇 「Visual Studio 2015」並點擊「更改（Change）」。而後在安裝過程當中，點擊「修改（ Modify）」，選擇「Tools for Universal Windows Apps」。

UWP 新功能

只要是 .NET 開發者都會喜歡 UWP 提供的特性——

• UWP 應用在安裝 Windows 10 操做系統的臺式機上以窗口化視圖運行。
• UWP 應用在任一款 Windows 10 設備上都可運行——手機、XBox、HoloLens 甚至是 Raspberry Pi 等物聯網設備。
• UWP 應用利用了最新 .NET Core 的技術優點，經過使用 .NET Core 的最新版本的新加功能簡化應用程序的開發。
• 應用程序和業務邏輯核心的 .NET，一樣可在如 ASP.NET 5 等平臺（支持 .NET Core 的平臺）上運行。
• UWP 應用在程序內部署縮減後的 .NET 副本，以便應用老是使用通過驗證的 .NET 版本 。
• UWP 應用使用 .NET Native 技術，在客戶機下載代碼前，.NET Native 可生成高度優化的原生機器代碼。.NET Native 技術的使用，使得應用程序的啓動時間縮短、電量消耗下降和性能加快。
• 用戶可很方便地在 Windows 商店內購買、安裝和升級 UWP 應用程序。
• UWP 應用程序完美地結合了用於詳細測試和分析的Application Insights插件——一個瞭解用戶需求和提升應用程序質量的重要工具。

新工具帶來的新用途——

• 使用 .NET 編寫 Windows 10 UWP 應用程序。
• 編寫用於 .NET Core 的 Portable Class Libraries
• 相比以前 Windows Store 或 Phone 應用，UWP 應用程序中可使用更多的 .NET 外部工具，包括 System.Net.Sockets、WCF Client、System.Numerics.Vectors 和新的 Diagnostics APIs。
• NuGet 3.1（由文件「project.json」識別）可用於不一樣類型項目項目。

UWP 開發入門

下面是關於 UWP 開發的一些實用的概述和教程：

• 如何開發 Windows 10 通用應用程序[MSDN]——利用自適應 UI 界面和自適應代碼使得 UWP 應用在 Windows 10 設備上看起來更加美觀和運行更加流暢。
• UWP 應用程序指南[MSDN]--「通用」應用程序如何在全部設備上運行的。
• 移植應用程序到 UWP[MSDN]--從 Phone Silverlight、Win8.1 和 VS2015 RC 移植到 UWP 上。
• 利用 C# 和 XAML 編寫 Universal Windows Apps[Microsoft Virtual Academy]——Jerry Nixon 教授發佈的長達22小時實用在線訓練課程。
• 在 VS2015 上開發 UWP 應用程序[BUILD talk]。
• 深刻研究 XAML 和 .NET UWP 開發[BUILD talk]。

在本篇博客中，筆者將會介紹：做爲 .NET 開發者，須要注意的哪些改進的地方——其餘教程不會涉及的內容。首先須要創建平臺，下面十張圖中涵蓋了 .NET UWP 開發過程當中所有 Microsoft 工具。

File > New > C#/VB > Windows > Universal 開始編寫一個全新的 UWP 應用。改進後的 NuGet 比 VS2015 RC 要快得多。開發者一樣可建立一個兼容 UWP、ASP.NET 5 和 .NET 4.6 的 Portable Class Libraries (PCLs) 。

Solution Explorer > References References利用獨特的圖標顯示 NuGet 程序包。「Microsoft.NETCore.UniversalWindowsPlatform」是其中比較重要的一個包；它包含了 .NET Core 運行時和框架。 project.json 文件取代 packages.config 驅動 NuGet 3.0。NuGet 3.0 與 NuGet 2.0 相比，運行速度更快且更加複雜。

Adaptive XAM 開發人員常常設計「自適應的 UIs」以便其適應於不一樣設備、不一樣形式。如今隨着 XAML 的發展，ViewState triggers、更多設備預覽和現場 XAML Tree 調試等方式使得這項任務變得很是容易。一樣， 在高性能數據綁定使用 x:Bind。

Adaptive code 一個優秀的通用應用程序的關鍵在於在不一樣的設備間可儘量多的分享代碼，與此同時還要保障每一個設備上都有最好的應用體驗。開發者可經過調用特定平臺 WinRT APIs，在 .NET 中編寫自適應代碼。這比使用 Reflection（自適應代碼的前沿技術）方式要好的多。

Fast graphics:Win2d和System.Numerics.Vectors。對於快速繪圖，可利用Win2d 庫——是DirectX上 .NET 一個「精緻」的封裝。固然，這裏仍可使用SharpDX 或者 MonoGame。System.Numerics.Vectors 經過 CPU 的 SIMD 指令進行快速矢量和矩陣運算。在來利用這些技術後，在中端 Nokia 635計算 Mandelbrot Fractal 僅需70毫秒。

WCF，HTTP/2 and Sockets目前 .NET 庫包括WCF和 AddServiceReference，二者以前均不適用手機應用程序。HttpClient已被重寫：重寫後性能更好，而且支持HTTP/2協議。這裏一樣須要System.Net.Sockets，Windows Store 應用中期待已久 .NET 特性。

Improved debugging and EnC 如今，開發者在仿真器上調試時可使用「Edit and Continue (EnC)」。整個調製器引擎早已修改——在即時和觀察窗口中支持 lambdas 和 LINQ 表達式，同時與以前相比，在更多地方支持 EnC。一些開發者在 EnC 上編寫整個程序的代碼。快嘗試下吧！

.NET Native 當處於 Release 模式中，應用程序經過新「.NET Native」編輯器編譯。這就將其轉化爲高度優化的原生機器代碼——應用程序啓動時間縮短、電量損耗下降和總體性能加快。

Store submission 開發人員將十分喜好新的統一開發者中心（ Developer Center）。在提交一個應用時，嚮導將會提交應用程序的 MSIL。商店使用 .NET Native 進行編譯，將應用程序優化爲原生機器代碼（這是一個很難的反向工程，就像 C++ 代碼那樣），並將其部署到用戶設備中。

Application Insights and Diagnostics 新項目中默認安裝Application Insights 插件。該插件爲應用程序提供崩潰和使用時的詳細分析。應用商店中排名較高的應用程序都已知曉排名較高的緣由是接收和分析響應。在ETW中有着更爲豐富的追蹤功能。

.NET Native

.NET Native 是預（「AOT」）編譯技術：在編譯的時，它將代碼轉爲機器代碼。這與傳統的 .NET 使用的實時（「JIT」）編譯技術不一樣，在運行時延遲本地編譯直到它第一次執行。.NET Native 更接近與 C++ 編譯器。事實上，它的工具鏈中有 Visual C++ 編譯器，在 Windows Store 中，該工具用於提交應用程序（並不是最終用戶設備）。它可以快速地、精確地、獨立地生成代碼。

.NET Native 對終端用戶有着巨大的好處：應用啓動時間縮短60%，而且優化應用程序的內存佔用。在一些 UWP 應用程序上，筆者曾成功地將啓動時間由1秒縮短到110ms，測試機型號爲 Nokia 635。這都歸功於 .NET Native 和 VS 2015 新的perf-tips 功能和 Diagnostics Tools 窗口。

目前在 .NET 團隊博客上已經發布了不少關於 .NET Native 預覽版的文章。UWP中創新點在於它是第一個使用 .NET Native 的產品。對於大部分狀況而言，.NET Native 是透明的：當在 Release 模式下使用時，它編譯進行的至關隱蔽；Release 版本創建須要更長的時間，而且調試稍微差一點，性能特色也稍微有點不一樣；但除此以外應用程序能繼續正常運行並實現功能。Debug 版本主要依靠 CoreCLR，如你指望的那樣，有着傑出的調試體驗。

儘管 .NET Native 早在一年前就已公開預覽，對於不少人亂來講，這仍將是在 UWP 中第一次使用。出於這個緣由，筆者會更詳細的介紹下它是如何工做的。不只由於以此爲豪，同時也爲了知足讀者的好奇心。

.NET Core Framework

上週的一篇博文中已經討論過了 .NET Core Framework ("CoreFX")：

• .NET Core 是現代化設備和雲工做負載使用的 .NET 最新版本。.NET Core 以通用化爲目的，並採用模塊化部署，可在不一樣環境下的多種工做負載移植和使用。

CoreFX 經常使用於 UWP 應用程序。它是曾用於 Windows Store 開發的 .NET APIs 的擴展包。

這裏重點介紹下 UWP 開發者比較感興趣的 .NET Core FX：

• System.Net.Sockets（曾用於 UDP 通訊）曾用在 WinRT 應用程序上。其方式是使用特定的 WinRT UDP APIs。如今 System.Net.Sockets 已經成爲 .NET Core 的一部分，因此可被 UWP 應用使用。事實上，開發者能夠在其餘的 .NET 應用程序上共享 Sockets 代碼。注：這裏正在致力於 System.Net.Sockets 的開源工做。
• HttpClient（相似許多 .NET Core FX 的低 level 部分）須要進行不一樣的部署才能在不一樣的平臺運行。在 UWP 應用中，它被部署在 WinRT HTTP 棧的頂部。其默認的狀況下使用HTTP/2協議，以得到更低的延遲和更少的往返通訊次數，固然前提是服務器支持該協議。
• WCF Clien（和關聯的Add Service Reference dialog）曾在 Windows Phone Appx 項目中使用。但自從它變成 .NET Core 的一部分後，就常常被用於 UWP 應用程序中了。
• System.Numerics.Vectors提供了向量和矩陣類型，該類型經常使用於 CPU 的 SIMD 操做碼——單指令多數據。矢量和矩陣的運算速度相比於正常的「單指令單數據」操做碼要快得多。 -System.Diagnostics.Tracing。目前調度事件中，EventSource 可發送更豐富的有效負載到 Windows 事件跟蹤（ETW）中。

CoreFX 另外兩個使人興奮的方面是：開源和解除了與 Windows 和 Visual Studio 發佈捆綁。每一個開發者均可以參與其中並做出本身的貢獻，.NET 團隊天天都有所貢獻。該團隊與社區一塊兒致力於擴展 CoreFX，添加更多的 APIs。只要這些接口能加入其中，就能爲 UWP 應用程序所用。因爲 project.json 和 NuGet 存在，任一 UWP 開發人員都能使用最新版 .NET Core FX Packages（只要它們可用）——僅經過「Manage NuGet Packages」對話框便可。

注意：File>New 能夠生成一個具備全套官方 Microsoft NET Core 組件的 UWP 應用程序，這些與 UWP 應用相關組件是用於其測試。若是想其餘的或者還沒有開發的 Microsoft 庫，不能再使用「References > Add References」下——相反地，而是在「References > Manage NuGet References」中。

若是想自行編寫一個 .NET Core 庫，大可試着開發任一 .NET4.六、UWP 或 ASP.NET 5 平臺可用的 PCLs。

Universal Projects

利用 UWP 能夠編寫通用的應用——單一的 VS 項目、單一的代碼庫、單一上傳到 Windows Developer Center --即使其運行在多個「家族設備」（桌面、手機、Xbox 等等）。利用 UWP，應用程序代碼再也不須要使用#ifdefs 或 Shared Projects。經過此方法，應用程序開發和維護將會變得更加容易。

MSDN 上的「UWP 應用程序指南」對如何讓應用程序在不一樣的設備上界面看起美觀這一問題作了很好的解釋。好的方面是，經過 UI 調整能使得應用程序在桌面不一樣大小的窗口看起來都很美觀，在不一樣設備一樣也可作到這一點。

從 .NET 方面來看，最有趣的技術就是採用自適應代碼。例如：

在 Windows 10 電腦桌面上，個人應用程序及其美觀，可是在 Windows 手機界面上，它僅僅顯示 Status Bar（狀態欄）。若是使用了StatusBar.HideAsync，應用程序應該會看起來更好看一點。然而StatusBar是電腦桌面上不存在的類型。處理此狀況的代碼看起來很是簡單——WinRT API： Windows.Foundation.Metadata.ApiInformation.IsTypePresent用於檢測應用程序正運行的設備上有無 WinRT 類型，而且它只會調用該案例中特定平臺方法。

有時候很難記住哪一個 API 須要 IsTypePresent 保護。爲此，這裏開發一個名爲PlatformSpecific.Analyzer的 NuGet 包，開發者能夠將其添加到項目中：若是忘記保護某個接口，它將會在 IDE 中顯示警告信息。

有趣的是，這種自適應代碼目前僅在 UWP 平臺上的 .NET 中可用，而且是隻針對 UWP 類型。剛入門的 .NET 專家可能比較想了解詳情。對於 Debug builds，CoreCLR須要（ JIT）實時編譯 SetupAsync 方法，想要作到這一點必須要清楚代碼主體中每種類型和方法的元數據，同時還要弄明白那些即使不運行的分支中方法類型。 UWP 處理此問題須要創建一個本地應用程序文件「windows.winmd」，該文件包含所有 UWP 設備和各個版本中使用過 WinRT 類型和方法的元數據。對於 Release builds，.NET Native 將必要的元數據最終編譯成機器代碼，其格式通常是 COM IIDs 或者虛擬表形式。

由於將現有的代碼庫移植到 UWP 十分重要，這裏不得不提自適應應用程序中PCLs的最後一個話題。若是編寫一個「8.1 通用PCL」，即能同時在 Windows 8.1 和 Phone 8.1 使用。可參考 UWP 應用程序中使用 PCLs 的方式，將其作的完美。這是由於那些 PCLs 只能稱之爲 WinRT APIs 的子集，全部 UWP 平臺都兼容該子集。

NuGet 3.0和「project.json」

在 .NET 應用程序中，NuGet 事實上已經成爲包管理的標準。這裏本打算將 .NET Core 做爲 NuGet 包進行部署，但現有的 NuGet 2.0 客戶端和 packages.config（儘管前景很好），卻不是擴展到100+子包後 .NET Core的最佳選擇——速度太慢，又不夠靈活。NuGet 3.0解決了這些問題。最初是用於 ASP.NET 5中，如今 UWP 也在使用。

若是一個項目中使用了 project.json 文件而非 packages.config，一樣能夠說該項目使用了 Nuget 3.0。開發人員一樣能夠將 project.json 添加到任一現有的 .NET 項目中，一樣會起做用（首先須要項目卸載再重載）。下面是 project.json 的工做方式：

1. 當安裝一個 NuGet 包時，project.json 文件中將會自動添加一個引用，能夠在 SolutionExplorer > References 下查看它。
2. 在 Build 以前，VS 確保全部的 NuGet 包（以及相關文件）成功的下載到用戶設備上的緩存中心內，由它選擇當前項目目標/架構所要使用的包。
3. 在 Build 時，若是存在 project.json 文件，MSBuild 將會讀取該文件並引用相應的 DLLs 和它包含的 .targets 文件。

這裏看下 project.json 帶來的好處：

• .vbproj/.csproj 將再也不包含任何 NuGet 引用：它們將徹底分開。這將使得源代碼控制和合並衝突解決更加容易！
• 能夠修改應用程序的目標平臺，更改 Debug/Release 以及 x86/x64/ARM/ 任一 CPU，NuGet 將會實現這些設置。
• 在同一個須要 NuGet 的項目中，能夠在兩個不一樣的目錄下分別部署不一樣的解決方案。當須要在兩個庫中工做時，這將十分有效。
• Solution Explorer > References 將會更加簡潔，由於它只包含了安裝時選擇的包而非所有相關的包。卸載 NuGet 包也變得更加方便，一樣是由於只需卸載選定的包而非所有相關的包。
• 包可在全局（每臺機器上的每一個用戶）內緩存，省略了單個解決方案使用時下載+解壓縮的步驟。
• File > New 和Manage NuGet Packages > Install 二者速度都有所加快。
• 在 NuGet 包升級和版本不匹配時，控制更加精確。

請在 NuGet Team Blog 和 NuGet Home repo 查看更多關於 NuGet 的資料。二者均是與該團隊討論 NuGet 變化的最佳場所。現知的一個問題（並指望在將來升級版中解決該問題）：UWP 應用中 Solution Explorer References 節點下顯示 NuGet 包全部相關的文件，正如 ASP.NET 5一樣具備該功能，這是一個好的改變嗎？

一些 NuGet 包安裝在 UWP 應用時，其工做方式會發生變化。若是你發現某些包出現異常狀況時，請在該貼底部的評論區留言。

• SharpDX.Toolkit 2.6.3 升級以後的 SharpDX 3（目前還是 Alpha 版本）在 UWP 應用中表現出色。SharpDX 工具包已被廢棄，並將不會在版本3中添加，同時也將不會安裝到 UWP 應用中。這裏將考慮 Paradox 和 MonoGame 做爲其在 SharpDX 上代替工具包。
• MvvmLight 該 NuGet 包可在 UWP 應用上正常工做，除了在安裝時須要多加一個額外步驟。安裝時能自動修改 App.xaml 文件和向項目中添加其餘一些文件。但這並不適用於 UWP 應用，因此這裏須要手動修改或者使用 MvvmLight VSIX。
• Sqlite-net 儘管 UWP 應用中再也不安裝該 NuGet 包，與其相似的Sqlite.Net-PCL（同一做者）包表現搶眼。
• LiveSDK 該 NuGet 包儘管仍會安裝，但沒有實際引用 DLLs。在短時間工做中，能夠自行手動添加引用 Microsoft.Live.dll（如何肯定 DLL 文件的位置？最簡單的方法是在 UWP 應用中添加 LiveSDK 引用，而後將 NuGet 下載到%USERPROFILE%.nuget\packages\LiveSDK 路徑下）。另外一個選擇，還可使用該文檔描述的 Windows.Security.Authentication.OnlineID，至於 OneDrive，可經過 HttpCliet 使用 REST APIs。

順便說一句，「現代化」PCLs 默認使用 project.json——例如某些可用於 .NET4.六、UWP 和 ASP.NET 5 Core 的 PCLs。

UWP 應用使用 CoreCLR 進行調試，而 .NET Native 使用 CoreCLR Release 下圖顯示了當編譯、調試和提交 UWP 應用到商店時發生的情況。VB 和 C# 編譯器在 MSIL 不斷生成 DLLs 文件。這是接下來發生的變化...

Debug build: CoreCLR. When you build your UWP app in Debug mode, it uses the 「.NET Core CLR」 runtime, the same as used in ASP.NET 5. This provides a great edit+run+debug experience – fast deploy, rich debugging, Edit and Continue. It also means

調試版本：CoreCLR。當在 Debug 模式下編譯 UWP 應用時，運行的是「.NET Core CLR」，在 ASP.NET 5 中一樣如此。這提供了一個 edit+run+debug 極好體驗——快速部署、屢次 Debug、Edit 和 Continue。

發佈版本：.NET Native。當在 Release 模式下編譯程序時，它須要額外的30秒將 MSIL 和引用轉換爲優化的原生機器代碼。這裏正在努力縮短此時間。經過「tree-shaking」方式刪除從未調用過的代碼。並在「Marshalling Code Generation」預編譯序列化代碼以便在運行中無需反射。優化所有程序代碼。本機代碼的優化和編譯生成單一本地 DLL 文件。能夠在 bin\x86\Release\ilc 目錄下找到此文件。

**.NET Core：CoreCLR和 .NET Native 二者均是「.NET Core Runtimes」。它們能夠同時使用和運行相同的 .NET Core 庫（CoreFX），因此在 Debug 模式和 Release 模式下不存在差別。在 Windows 8/8.1 中， .NET Framework 曾用於 .NET 的底層部署。在 Windows 10 中使用 .NET Core，可在調用新 CoreFX 庫的同時提供 Debug 和 Release 兩種模式。

Store submission。當開發了一個準備提交到 Windows Store 商店的 Appx 包時，該 Appx 附加包中包含 MSIL。而後 Windows Store 進行 .NET Native 編譯。這就減輕了一些人對 .NET Core FX「局部應用部署」的擔心。他們擔憂若是在 .NET 中出現安全漏洞怎麼辦。在過去，一般的解決方法是進行 Windows 更新。如今，經過識別 Appx 包是否易受攻擊，而後和其開發者一塊兒進行修復解決。

.NET Native 開發技巧

在發佈模式下測試 請在 Release 模式下按期測試的應用程序。Release 模式使用了 .NET Native。若是按期測試（好比四小時測試一次），將可以及時發現問題，如 Expression.Compile 的不一樣性能。若是在測試中發現問題須要調試時，小心發佈版本是徹底優化的，須要禁用優化以得到最佳的調試效果。

.NET Native 分析器。有一些 .NET Native 不支持的 .NET 功能，例如超過四維度以上的多維度矩陣（！）。當進行 .NET Native 編譯時會了解到這些的。可是想要節約 .NET Native 編譯多出30+秒的時間，能夠經過自行引用 Microsoft.NETNative.Analyzer（NuGet 包）當即獲得警告。

AnyCPU被取消。這是由於 .NET Native 編譯爲原生機器代碼。對於應用程序開發而言，CPU 幾乎毫無分量。開發者僅需牢記在本地設備或者模擬器上部署時選擇 x86；在 Win10 移動設備上部署選擇 ARM ；或者 x64（這並不比 x86 效果好）。當爲應用商店開發 Appx 包時，該向導將會生成三種不一樣的類型並提交到應用商店。

若是正在開發一個類庫或 PCL，應當將其開發成「AnyCPU」類型。這將會使得事情簡單化——可單獨分配一個所有項目都可用的 DLL 文件。

我能找到的最簡單的方式就是：點擊 Build > ConfigurationManager 對話框。能夠這樣設置，對於該庫而言，即便工具欄顯示「AnyCPU」，仍將 builds+deploys應用爲 x86 類型。

調試.NET Native。有時，開發者想在 .NET Native 中設置斷點來調試代碼。但最好請不要在 Release 模式下這樣作，由於調試自己就很困難，.NET Native 的對代碼積極優化將使得其難上加難。結果顯而易見，使用 Debug 模式（關閉優化），而後臨時修改項目配置以便使用 .NET Native（即使是在 Debug 版本也要這樣作）。在 C# 中，在 .NET Native 工具欄中設置方式：Project > Properties > Compile。在 VB 中，設置方式：MyProject > Build > Advanced。

定製 .NET Native 優化。尤爲是在應用程序中，經過巧妙地使用反射方式，.NET Native 能夠刪除多餘的優化。這是可控的。這些博客解釋得很好：

1. 靜態代碼中的動態特性。
2. 求助！我遇到 MissingMetadataException 異常。
3. 求助！我沒遇到 MissingMetadataException 異常。
4. .NET Native 深刻探索：讓庫變得更好。
5. [.NET Native 深刻探索：優化運行指令][1]。

Expression.Compile。之因此介紹它，是由於它在 Newtonsoft‘s Json.Net 內部使用而且對開發者有着深遠的影響。在傳統的 CLR 中，表達樹可在運行時編譯爲 MSIL，而後 JIT 將其轉爲原生代碼。這在 .NET Native 中不會發生，.NET Native 將會解讀這些表達樹。請注意與 Json.Net 相比發生的變化，例如，啓動時間縮短（無需加載 CLR 表達樹架構），但在序列化大的數據文件時速度變慢。若是這對你的應用較爲重要，請親自測量。這一改變使得應用程序啓動時間縮短了200ms。

F#-- 任一 UWP 商店應用程序均不能使用 F# DLLs：目前 .NET Native 不支持該文件。這是將來須要修復的一個問題。若是這對你很重要，請及時通知咱們。

Get help。若是在使用 .NET Native 遇到問題，尋求解決方法的最好方式是發送電子郵件到 dotnetnative@microsoft.com。

總結

今天 Universal Windows Platform 發佈爲 .NET 開發者提供了一個全新的契機。對 UWP 應用而言，這是一筆巨大的財富，開發者可使用最新的 .NET 技術開發應用。

請大膽地作出嘗試並交流你的想法。若是存在任何問題。請在此處或者在Windows Dev Center 的「Developing Universal Apps」論壇上留言。若是經過使用 .NET Native 優化應用程序的啓動時間在200ms如下，請在這裏大膽的炫耀吧！

OneAPM 助您輕鬆鎖定 .NET 應用性能瓶頸，經過強大的 Trace 記錄逐層分析，直至鎖定行級問題代碼。以用戶角度展現系統響應速度，以地域和瀏覽器維度統計用戶使用狀況。想閱讀更多技術文章，請訪問 OneAPM 官方博客。 本文轉自 OneAPM 官方博客

原文連接：http://blogs.msdn.com/b/dotnet/archive/2015/07/30/universal-windows-apps-in-net.aspx