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 裝置）等等。
開發者可下載下傳安裝免費的 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」。
隻要是 .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 開發的一些實用的概述和教程：
如何開發 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 是預（「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 ("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。
利用 uwp 可以編寫通用的應用——單一的 vs 項目、單一的代碼庫、單一上傳到 windows developer center --即便其運作在多個「家族裝置」（桌面、手機、xbox 等等）。利用 uwp，應用程式代碼不再需要使用#ifdefs 或 shared projects。通過此方法，應用程式開發和維護将會變得更加容易。
msdn 上的「uwp 應用程式指南」對如何讓應用程式在不同的裝置上界面看起美觀這一問題做了很好的解釋。好的方面是，通過 ui 調整能使得應用程式在桌面不同大小的視窗看起來都很美觀，在不同裝置同樣也可做到這一點。
從 .net 方面來看，最有趣的技術就是采用自适應代碼。例如：
在 windows 10 電腦桌面上，我的應用程式及其美觀，但是在 windows 手機界面上，它僅僅顯示 status bar（狀态欄）。如果使用了<code>statusbar.hideasync</code>，應用程式應該會看起來更好看一點。然而statusbar是電腦桌面上不存在的類型。處理此情況的代碼看起來非常簡單——winrt api： <code>windows.foundation.metadata.apiinformation.istypepresent</code>用于檢測應用程式正運作的裝置上有無 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 平台都相容該子集。
在 .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%.nugetpackageslivesdk 路徑下）。另一個選擇，還可以使用該文檔描述的 windows.security.authentication.onlineid，至于 onedrive，可通過 httpcliet 使用 rest apis。
順便說一句，「現代化」pcls 預設使用 project.json——例如某些可用于 .net4.6、uwp 和 asp.net 5 core 的 pcls。
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 檔案。可以在 binx86releaseilc 目錄下找到此檔案。
**.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 包是否易受攻擊，然後和其開發者一起進行修複解決。
在釋出模式下測試 請在 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 可以删除多餘的優化。這是可控的。這些部落格解釋得很好：
靜态代碼中的動态特性。
求助！我遇到 missingmetadataexception 異常。
求助！我沒遇到 missingmetadataexception 異常。
.net native 深入探索：讓庫變得更好。
.net native 深入探索：優化運作指令。
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 優化應用程式的啟動時間.aspx)在200ms以下，請在這裡大膽的炫耀吧！
oneapm 助您輕松鎖定 .net 應用性能瓶頸，通過強大的 trace 記錄逐層分析，直至鎖定行級問題代碼。以使用者角度展示系統響應速度，以地域和浏覽器次元統計使用者使用情況。想閱讀更多技術文章，請通路 oneapm 官方部落格。
本文轉自 oneapm 官方部落格
原文連結：http://blogs.msdn.com/b/dotnet/archive/2015/07/30/universal-windows-apps-in-net.aspx