2015年7月30日

目前成都創(chuàng)新互聯(lián)已為成百上千的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁空間、網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計、無棣網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

本文作者是 Managed Languages 團隊項目經(jīng)理 Lucian Wischik。

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

安裝 UWP 工具

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

如果已經(jīng)安裝了 Visual Studio 2015，有兩種方式獲得 Universal Windows Apps 開發(fā)工具：

• 下載并運行 Windows Tools installer。

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

UWP 新功能

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

• UWP 應(yīng)用在安裝 Windows 10 操作系統(tǒng)的臺式機上以窗口化視圖運行。

• UWP 應(yīng)用在任一款 Windows 10 設(shè)備上均可運行——手機、XBox、HoloLens 甚至是 Raspberry Pi 等物聯(lián)網(wǎng)設(shè)備。

• UWP 應(yīng)用利用了最新 .NET Core 的技術(shù)優(yōu)勢，通過使用 .NET Core 的最新版本的新加功能簡化應(yīng)用程序的開發(fā)。

• 應(yīng)用程序和業(yè)務(wù)邏輯核心的 .NET，同樣可在如 ASP.NET 5 等平臺（支持 .NET Core 的平臺）上運行。

• UWP 應(yīng)用在程序內(nèi)部署縮減后的 .NET 副本，以便應(yīng)用總是使用經(jīng)過驗證的 .NET 版本 。

• UWP 應(yīng)用使用 .NET Native 技術(shù)，在客戶機下載代碼前，.NET Native 可生成高度優(yōu)化的原生機器代碼。.NET Native 技術(shù)的使用，使得應(yīng)用程序的啟動時間縮短、電量消耗降低和性能加快。

• 用戶可很方便地在 Windows 商店內(nèi)購買、安裝和升級 UWP 應(yīng)用程序。

• UWP 應(yīng)用程序完美地結(jié)合了用于詳細測試和分析的Application Insights插件——一個了解用戶需求和提高應(yīng)用程序質(zhì)量的重要工具。

新工具帶來的新用途——

• 使用 .NET 編寫 Windows 10 UWP 應(yīng)用程序。

• 編寫用于 .NET Core 的 Portable Class Libraries

• 相比之前 Windows Store 或 Phone 應(yīng)用，UWP 應(yīng)用程序中可以使用更多的 .NET 外部工具，包括 System.Net.Sockets、WCF Client、System.Numerics.Vectors 和新的 Diagnostics APIs。

• NuGet 3.1（由文件「project.json」識別）可用于不同類型項目項目。

UWP 開發(fā)入門

下面是關(guān)于 UWP 開發(fā)的一些實用的概述和教程：

• 如何開發(fā) Windows 10 通用應(yīng)用程序[MSDN]——利用自適應(yīng) UI 界面和自適應(yīng)代碼使得 UWP 應(yīng)用在 Windows 10 設(shè)備上看起來更加美觀和運行更加流暢。

• UWP 應(yīng)用程序指南[MSDN]--「通用」應(yīng)用程序如何在所有設(shè)備上運行的。

• 移植應(yīng)用程序到 UWP[MSDN]--從 Phone Silverlight、Win8.1 和 VS2015 RC 移植到 UWP 上。

• 利用 C# 和 XAML 編寫 Universal Windows Apps[Microsoft Virtual Academy]——Jerry Nixon 教授發(fā)布的長達22小時實用在線訓(xùn)練課程。

• 在 VS2015 上開發(fā) UWP 應(yīng)用程序[BUILD talk]。

• 深入研究 XAML 和 .NET UWP 開發(fā)[BUILD talk]。

在本篇博客中，筆者將會介紹：作為 .NET 開發(fā)者，需要注意的哪些改進的地方——其他教程不會涉及的內(nèi)容。首先需要建立平臺，下面十張圖中涵蓋了 .NET UWP 開發(fā)過程中全部 Microsoft 工具。

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

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

Adaptive XAM 開發(fā)人員經(jīng)常設(shè)計「自適應(yīng)的 UIs」以便其適應(yīng)于不同設(shè)備、不同形式?，F(xiàn)在隨著 XAML 的發(fā)展，ViewState triggers、更多設(shè)備預(yù)覽和現(xiàn)場 XAML Tree 調(diào)試等方式使得這項任務(wù)變得非常容易。同樣， 在高性能數(shù)據(jù)綁定使用 x:Bind。

Adaptive code 一個優(yōu)秀的通用應(yīng)用程序的關(guān)鍵在于在不同的設(shè)備間可盡可能多的分享代碼，與此同時還要保障每個設(shè)備上都有最好的應(yīng)用體驗。開發(fā)者可通過調(diào)用特定平臺 WinRT APIs，在 .NET 中編寫自適應(yīng)代碼。這比使用 Reflection（自適應(yīng)代碼的前沿技術(shù)）方式要好的多。

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

WCF，HTTP/2 and Sockets目前 .NET 庫包括WCF和 AddServiceReference，兩者之前均不適用手機應(yīng)用程序。HttpClient已被重寫：重寫后性能更好，并且支持HTTP/2協(xié)議。這里同樣需要System.Net.Sockets，Windows Store 應(yīng)用中期待已久 .NET 特性。

Improved debugging and EnC 現(xiàn)在，開發(fā)者在仿真器上調(diào)試時可以使用「Edit and Continue (EnC)」。整個調(diào)制器引擎早已修改——在即時和觀察窗口中支持 lambdas 和 LINQ 表達式，同時與之前相比，在更多地方支持 EnC。一些開發(fā)者在 EnC 上編寫整個程序的代碼?？靽L試下吧！

.NET Native 當處于 Release 模式中，應(yīng)用程序通過新「.NET Native」編輯器編譯。這就將其轉(zhuǎn)化為高度優(yōu)化的原生機器代碼——應(yīng)用程序啟動時間縮短、電量損耗降低和整體性能加快。

Store submission 開發(fā)人員將十分喜愛新的統(tǒng)一開發(fā)者中心（ Developer Center）。在提交一個應(yīng)用時，向?qū)峤粦?yīng)用程序的 MSIL。商店使用 .NET Native 進行編譯，將應(yīng)用程序優(yōu)化為原生機器代碼（這是一個很難的反向工程，就像 C++ 代碼那樣），并將其部署到用戶設(shè)備中。

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

.NET Native

.NET Native 是預(yù)（「AOT」）編譯技術(shù)：在編譯的時，它將代碼轉(zhuǎn)為機器代碼。這與傳統(tǒng)的 .NET 使用的實時（「JIT」）編譯技術(shù)不同，在運行時延遲本地編譯直到它第一次執(zhí)行。.NET Native 更接近與 C++ 編譯器。事實上，它的工具鏈中有 Visual C++ 編譯器，在 Windows Store 中，該工具用于提交應(yīng)用程序（并非最終用戶設(shè)備）。它能夠快速地、精確地、獨立地生成代碼。

.NET Native 對終端用戶有著巨大的好處：應(yīng)用啟動時間縮短60%，并且優(yōu)化應(yīng)用程序的內(nèi)存占用。在一些 UWP 應(yīng)用程序上，筆者曾成功地將啟動時間由1秒縮短到110ms，測試機型號為 Nokia 635。這都歸功于 .NET Native 和 VS 2015 新的perf-tips 功能和 Diagnostics Tools 窗口。

目前在 .NET 團隊博客上已經(jīng)發(fā)布了很多關(guān)于 .NET Native 預(yù)覽版的文章。UWP中創(chuàng)新點在于它是第一個使用 .NET Native 的產(chǎn)品。對于大部分情況而言，.NET Native 是透明的：當在 Release 模式下使用時，它編譯進行的相當隱蔽；Release 版本建立需要更長的時間，并且調(diào)試稍微差一點，性能特點也稍微有點不同；但除此之外應(yīng)用程序能繼續(xù)正常運行并實現(xiàn)功能。Debug 版本主要依靠 CoreCLR，如你期望的那樣，有著杰出的調(diào)試體驗。

盡管 .NET Native 早在一年前就已公開預(yù)覽，對于很多人亂來說，這仍將是在 UWP 中第一次使用。出于這個原因，筆者會更詳細的介紹下它是如何工作的。不僅因為以此為豪，同時也為了滿足讀者的好奇心。

.NET Core Framework

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

• .NET Core 是現(xiàn)代化設(shè)備和云工作負載使用的 .NET 最新版本。.NET Core 以通用化為目的，并采用模塊化部署，可在不同環(huán)境下的多種工作負載移植和使用。

CoreFX 常用于 UWP 應(yīng)用程序。它是曾用于 Windows Store 開發(fā)的 .NET APIs 的擴展包。

這里重點介紹下 UWP 開發(fā)者比較感興趣的 .NET Core FX：

• System.Net.Sockets（曾用于 UDP 通信）曾用在 WinRT 應(yīng)用程序上。其方式是使用特定的 WinRT UDP APIs?，F(xiàn)在 System.Net.Sockets 已經(jīng)成為 .NET Core 的一部分，所以可被 UWP 應(yīng)用使用。事實上，開發(fā)者可以在其他的 .NET 應(yīng)用程序上共享 Sockets 代碼。注：這里正在致力于 System.Net.Sockets 的開源工作。

• HttpClient（類似許多 .NET Core FX 的低 level 部分）需要進行不同的部署才能在不同的平臺運行。在 UWP 應(yīng)用中，它被部署在 WinRT HTTP 棧的頂部。其默認的情況下使用HTTP/2協(xié)議，以獲得更低的延遲和更少的往返通信次數(shù)，當然前提是服務(wù)器支持該協(xié)議。

• WCF Clien（和關(guān)聯(lián)的Add Service Reference dialog）曾在 Windows Phone Appx 項目中使用。但自從它變成 .NET Core 的一部分后，就經(jīng)常被用于 UWP 應(yīng)用程序中了。

• System.Numerics.Vectors提供了向量和矩陣類型，該類型常用于 CPU 的 SIMD 操作碼——單指令多數(shù)據(jù)。矢量和矩陣的運算速度相比于正常的「單指令單數(shù)據(jù)」操作碼要快得多。
  -System.Diagnostics.Tracing。目前調(diào)度事件中，EventSource 可發(fā)送更豐富的有效負載到 Windows 事件跟蹤（ETW）中。

CoreFX 另外兩個令人興奮的方面是：開源和解除了與 Windows 和 Visual Studio 發(fā)布捆綁。每個開發(fā)者都可以參與其中并作出自己的貢獻，.NET 團隊每天都有所貢獻。該團隊與社區(qū)一起致力于擴展 CoreFX，添加更多的 APIs。只要這些接口能加入其中，就能為 UWP 應(yīng)用程序所用。由于 project.json 和 NuGet 存在，任一 UWP 開發(fā)人員都能使用最新版 .NET Core FX Packages（只要它們可用）——僅通過「Manage NuGet Packages」對話框即可。

注意：File>New 可以生成一個具有全套官方 Microsoft NET Core 組件的 UWP 應(yīng)用程序，這些與 UWP 應(yīng)用相關(guān)組件是用于其測試。如果想其他的或者尚未開發(fā)的 Microsoft 庫，不能再使用「References > Add References」下——相反地，而是在「References > Manage NuGet References」中。

如果想自行編寫一個 .NET Core 庫，大可試著開發(fā)任一 .NET4.6、UWP 或 ASP.NET 5 平臺可用的 PCLs。

Universal Projects

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

MSDN 上的「UWP 應(yīng)用程序指南」對如何讓應(yīng)用程序在不同的設(shè)備上界面看起美觀這一問題做了很好的解釋。好的方面是，通過 UI 調(diào)整能使得應(yīng)用程序在桌面不同大小的窗口看起來都很美觀，在不同設(shè)備同樣也可做到這一點。

從 .NET 方面來看，最有趣的技術(shù)就是采用自適應(yīng)代碼。例如：

在 Windows 10 電腦桌面上，我的應(yīng)用程序及其美觀，但是在 Windows 手機界面上，它僅僅顯示 Status Bar（狀態(tài)欄）。如果使用了StatusBar.HideAsync，應(yīng)用程序應(yīng)該會看起來更好看一點。然而StatusBar是電腦桌面上不存在的類型。處理此情況的代碼看起來非常簡單——WinRT API： Windows.Foundation.Metadata.ApiInformation.IsTypePresent用于檢測應(yīng)用程序正運行的設(shè)備上有無 WinRT 類型，并且它只會調(diào)用該案例中特定平臺方法。

有時候很難記住哪個 API 需要 IsTypePresent 保護。為此，這里開發(fā)一個名為PlatformSpecific.Analyzer的 NuGet 包，開發(fā)者可以將其添加到項目中：如果忘記保護某個接口，它將會在 IDE 中顯示警告信息。

有趣的是，這種自適應(yīng)代碼目前僅在 UWP 平臺上的 .NET 中可用，并且是只針對 UWP 類型。剛?cè)腴T的 .NET 專家可能比較想了解詳情。對于 Debug builds，CoreCLR需要（ JIT）實時編譯 SetupAsync 方法，想要做到這一點必需要清楚代碼主體中每種類型和方法的元數(shù)據(jù)，同時還要弄明白那些即便不運行的分支中方法類型。 UWP 處理此問題需要建立一個本地應(yīng)用程序文件「windows.winmd」，該文件包含全部 UWP 設(shè)備和各個版本中使用過 WinRT 類型和方法的元數(shù)據(jù)。對于 Release builds，.NET Native 將必要的元數(shù)據(jù)最終編譯成機器代碼，其格式一般是 COM IIDs 或者虛擬表形式。

因為將現(xiàn)有的代碼庫移植到 UWP 十分重要，這里不得不提自適應(yīng)應(yīng)用程序中PCLs的最后一個話題。如果編寫一個「8.1 通用PCL」，即能同時在 Windows 8.1 和 Phone 8.1 使用?？蓞⒖?UWP 應(yīng)用程序中使用 PCLs 的方式，將其做的完美。這是因為那些 PCLs 只能稱之為 WinRT APIs 的子集，所有 UWP 平臺都兼容該子集。

NuGet 3.0和「project.json」

在 .NET 應(yīng)用程序中，NuGet 事實上已經(jīng)成為包管理的標準。這里本打算將 .NET Core 作為 NuGet 包進行部署，但現(xiàn)有的 NuGet 2.0 客戶端和 packages.config（盡管前景很好），卻不是擴展到100+子包后 .NET Core的最佳選擇——速度太慢，又不夠靈活。NuGet 3.0解決了這些問題。最初是用于 ASP.NET 5中，現(xiàn)在 UWP 也在使用。

如果一個項目中使用了 project.json 文件而非 packages.config，同樣可以說該項目使用了 Nuget 3.0。開發(fā)人員同樣可以將 project.json 添加到任一現(xiàn)有的 .NET 項目中，同樣會起作用（首先需要項目卸載再重載）。下面是 project.json 的工作方式：

1. 當安裝一個 NuGet 包時，project.json 文件中將會自動添加一個引用，可以在 SolutionExplorer > References 下查看它。

2. 在 Build 之前，VS 確保所有的 NuGet 包（以及相關(guān)文件）成功的下載到用戶設(shè)備上的緩存中心內(nèi)，由它選擇當前項目目標/架構(gòu)所要使用的包。

3. 在 Build 時，如果存在 project.json 文件，MSBuild 將會讀取該文件并引用相應(yīng)的 DLLs 和它包含的 .targets 文件。

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

• .vbproj/.csproj 將不再包含任何 NuGet 引用：它們將完全分開。這將使得源代碼控制和合并沖突解決更加容易！

• 可以修改應(yīng)用程序的目標平臺，更改 Debug/Release 以及 x86/x64/ARM/ 任一 CPU，NuGet 將會實現(xiàn)這些設(shè)置。

• 在同一個需要 NuGet 的項目中，可以在兩個不同的目錄下分別部署不同的解決方案。當需要在兩個庫中工作時，這將十分有效。

• Solution Explorer > References 將會更加簡潔，因為它只包含了安裝時選擇的包而非全部相關(guān)的包。卸載 NuGet 包也變得更加方便，同樣是因為只需卸載選定的包而非全部相關(guān)的包。

• 包可在全局（每臺機器上的每個用戶）內(nèi)緩存，省略了單個解決方案使用時下載+解壓縮的步驟。

• File > New 和Manage NuGet Packages > Install 兩者速度都有所加快。

• 在 NuGet 包升級和版本不匹配時，控制更加精確。

請在 NuGet Team Blog 和 NuGet Home repo 查看更多關(guān)于 NuGet 的資料。兩者均是與該團隊討論 NuGet 變化的最佳場所?，F(xiàn)知的一個問題（并期望在未來升級版中解決該問題）：UWP 應(yīng)用中 Solution Explorer References 節(jié)點下顯示 NuGet 包所有相關(guān)的文件，正如 ASP.NET 5同樣具有該功能，這是一個好的改變嗎？

一些 NuGet 包安裝在 UWP 應(yīng)用時，其工作方式會發(fā)生變化。如果你發(fā)現(xiàn)某些包出現(xiàn)異常情況時，請在該貼底部的評論區(qū)留言。

• SharpDX.Toolkit 2.6.3 升級之后的 SharpDX 3（目前仍是 Alpha 版本）在 UWP 應(yīng)用中表現(xiàn)出色。SharpDX 工具包已被廢棄，并將不會在版本3中添加，同時也將不會安裝到 UWP 應(yīng)用中。這里將考慮 Paradox 和 MonoGame 作為其在 SharpDX 上代替工具包。

• MvvmLight 該 NuGet 包可在 UWP 應(yīng)用上正常工作，除了在安裝時需要多加一個額外步驟。安裝時能自動修改 App.xaml 文件和向項目中添加其他一些文件。但這并不適用于 UWP 應(yīng)用，所以這里需要手動修改或者使用 MvvmLight VSIX。

• Sqlite-net 盡管 UWP 應(yīng)用中不再安裝該 NuGet 包，與其類似的Sqlite.Net-PCL（同一作者）包表現(xiàn)搶眼。

• LiveSDK 該 NuGet 包盡管仍會安裝，但沒有實際引用 DLLs。在短期工作中，可以自行手動添加引用 Microsoft.Live.dll（如何確定 DLL 文件的位置？最簡單的方法是在 UWP 應(yīng)用中添加 LiveSDK 引用，然后將 NuGet 下載到%USERPROFILE%.nuget\packages\LiveSDK 路徑下）。另一個選擇，還可以使用該文檔描述的Windows.Security.Authentication.OnlineID，至于 OneDrive，可通過 HttpCliet 使用 REST APIs。

順便說一句，「現(xiàn)代化」PCLs 默認使用 project.json——例如某些可用于 .NET4.6、UWP 和 ASP.NET 5 Core 的 PCLs。

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

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

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

發(fā)布版本：.NET Native。當在 Release 模式下編譯程序時，它需要額外的30秒將 MSIL 和引用轉(zhuǎn)換為優(yōu)化的原生機器代碼。這里正在努力縮短此時間。通過「tree-shaking」方式刪除從未調(diào)用過的代碼。并在「Marshalling Code Generation」預(yù)編譯序列化代碼以便在運行中無需反射。優(yōu)化全部程序代碼。本機代碼的優(yōu)化和編譯生成單一本地 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，可在調(diào)用新 CoreFX 庫的同時提供 Debug 和 Release 兩種模式。

Store submission。當開發(fā)了一個準備提交到 Windows Store 商店的 Appx 包時，該 Appx 附加包中包含 MSIL。然后 Windows Store 進行 .NET Native 編譯。這就減輕了一些人對 .NET Core FX「局部應(yīng)用部署」的擔憂。他們擔心如果在 .NET 中出現(xiàn)安全漏洞怎么辦。在過去，通常的解決方法是進行 Windows 更新?，F(xiàn)在，通過識別 Appx 包是否易受***，然后和其開發(fā)者一起進行修復(fù)解決。

.NET Native 開發(fā)技巧

在發(fā)布模式下測試 請在 Release 模式下定期測試的應(yīng)用程序。Release 模式使用了 .NET Native。如果定期測試（比如四小時測試一次），將能夠及時發(fā)現(xiàn)問題，如 Expression.Compile 的不同性能。如果在測試中發(fā)現(xiàn)問題需要調(diào)試時，當心發(fā)布版本是完全優(yōu)化的，需要禁用優(yōu)化以獲得最佳的調(diào)試效果。

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

AnyCPU被取消。這是因為 .NET Native 編譯為原生機器代碼。對于應(yīng)用程序開發(fā)而言，CPU 幾乎毫無份量。開發(fā)者僅需牢記在本地設(shè)備或者模擬器上部署時選擇 x86；在 Win10 移動設(shè)備上部署選擇 ARM ；或者 x64（這并不比 x86 效果好）。當為應(yīng)用商店開發(fā) Appx 包時，該向?qū)扇N不同的類型并提交到應(yīng)用商店。

如果正在開發(fā)一個類庫或 PCL，應(yīng)當將其開發(fā)成「AnyCPU」類型。這將會使得事情簡單化——可單獨分配一個全部項目均可用的 DLL 文件。

我能找到的最簡單的方式就是：點擊 Build > ConfigurationManager 對話框?？梢赃@樣設(shè)置，對于該庫而言，即使工具欄顯示「AnyCPU」，仍將 builds+deploys應(yīng)用為 x86 類型。

調(diào)試.NET Native。有時，開發(fā)者想在 .NET Native 中設(shè)置斷點來調(diào)試代碼。但最好請不要在 Release 模式下這樣做，因為調(diào)試本身就很困難，.NET Native 的對代碼積極優(yōu)化將使得其難上加難。結(jié)果顯而易見，使用 Debug 模式（關(guān)閉優(yōu)化），然后臨時修改項目配置以便使用 .NET Native（即便是在 Debug 版本也要這樣做）。在 C# 中，在 .NET Native 工具欄中設(shè)置方式：Project > Properties > Compile。在 VB 中，設(shè)置方式：MyProject > Build > Advanced。

定制 .NET Native 優(yōu)化。尤其是在應(yīng)用程序中，通過巧妙地使用反射方式，.NET Native 可以刪除多余的優(yōu)化。這是可控的。這些博客解釋得很好：
1. 靜態(tài)代碼中的動態(tài)特性。
2. 求助！我遇到 MissingMetadataException 異常。
3. 求助！我沒遇到 MissingMetadataException 異常。
4. .NET Native 深入探索：讓庫變得更好。
5. [.NET Native 深入探索：優(yōu)化運行指令][1]。

Expression.Compile。之所以介紹它，是因為它在 Newtonsoft‘s Json.Net 內(nèi)部使用并且對開發(fā)者有著深遠的影響。在傳統(tǒng)的 CLR 中，表達樹可在運行時編譯為 MSIL，然后 JIT 將其轉(zhuǎn)為原生代碼。這在 .NET Native 中不會發(fā)生，.NET Native 將會解讀這些表達樹。請注意與 Json.Net 相比發(fā)生的變化，例如，啟動時間縮短（無需加載 CLR 表達樹架構(gòu)），但在序列化大的數(shù)據(jù)文件時速度變慢。如果這對你的應(yīng)用較為重要，請親自測量。這一改變使得應(yīng)用程序啟動時間縮短了200ms。

F#-- 任一 UWP 商店應(yīng)用程序均不能使用 F# DLLs：目前 .NET Native 不支持該文件。這是未來需要修復(fù)的一個問題。如果這對你很重要，請及時通知我們。

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

總結(jié)

今天 Universal Windows Platform 發(fā)布為 .NET 開發(fā)者提供了一個全新的契機。對 UWP 應(yīng)用而言，這是一筆巨大的財富，開發(fā)者可以使用最新的 .NET 技術(shù)開發(fā)應(yīng)用。

請大膽地做出嘗試并交流你的想法。如果存在任何問題。請在此處或者在Windows Dev Center 的「Developing Universal Apps」論壇上留言。如果通過使用 .NET Native 優(yōu)化應(yīng)用程序的啟動時間在200ms以下，請在這里大膽的炫耀吧！

OneAPM 助您輕松鎖定 .NET 應(yīng)用性能瓶頸，通過強大的 Trace 記錄逐層分析，直至鎖定行級問題代碼。以用戶角度展示系統(tǒng)響應(yīng)速度，以地域和瀏覽器維度統(tǒng)計用戶使用情況。想閱讀更多技術(shù)文章，請訪問 OneAPM 官方博客。
本文轉(zhuǎn)自 OneAPM 官方博客

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

+

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當前名稱：使用.NET平臺，如何玩轉(zhuǎn)UniversalWindows應(yīng)用？-創(chuàng)新互聯(lián)
網(wǎng)站路徑：http://www.rwnh.cn/article4/ddceoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站內(nèi)鏈、網(wǎng)站營銷、品牌網(wǎng)站制作、動態(tài)網(wǎng)站、做網(wǎng)站、移動網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)