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.6、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 的工作方式：
當安裝一個 NuGet 包時，project.json 文件中將會自動添加一個引用，可以在 SolutionExplorer > References 下查看它。
在 Build 之前，VS 確保所有的 NuGet 包（以及相關文件）成功的下載到用戶設備上的緩存中心內，由它選擇當前項目目標/架構所要使用的包。
在 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.6、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 遇到問題，尋求解決方法的最好方式是發送電子郵件到 [email protected]。
總結
今天 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
+