Windows Phone8.1之后，開發(fā)者有三種選擇。

1. 繼續(xù)用silverlight 8.0，反正向下兼容，如果APP也不需要新功能就這樣吧。
2. 升級到silverlight 8.1，如果需要8.1提供的新功能，silverlight8.0項(xiàng)目可以直接升級到8.1，然后開發(fā)新功能即可。
3. 遷移到windows phone Store APP(也就是Windows Runtime)，這個(gè)推薦，這個(gè)可以最大化和Windows共享代碼，Win/RT/WP 8.1的通用程序也需要遷移到Windows Runtime。

后面就不討論silverlight了，只討論Windows Runtime，之前泄露的SDK還分別稱Windows Phone Runtime和Windows Runtime，也就是WPRT和WinRT。

而這次的RC版，微軟已經(jīng)統(tǒng)稱Windows Runtime，已經(jīng)淡化Windows Phone Runtime了。

一張圖說明問題，windows.winmd，也就是Windows Runtime提供的API：

圖中分別列出了Win8.1,WP8.1,和WP8的windows.winmd的API，下原圖對著看一幕了然：

（點(diǎn)擊看大圖）

看了這張圖，就明白微軟為何不刻意區(qū)分WPRT和WinRT了，因?yàn)橐呀?jīng)高度統(tǒng)一了。

WP8.1和Win8.1的WinRT已經(jīng)高度統(tǒng)一了，不像WP8的WPRT不但大量API缺失，還有不少是Windows.Phone.xxx手機(jī)專用命名空間。

MSDN上也統(tǒng)一為Windows Runtime APP開發(fā)文檔了，不過手機(jī)PC畢竟還有一些區(qū)別，所以有PC和手機(jī)圖標(biāo)表明該功能的適用場景(如圖

下面我首先看了下自己比較關(guān)注的方面，文件訪問。

WP8.1已經(jīng)有和Win8/RT同樣的文件選擇器，Windows.Storage.Pickers.FileOpenPicker。

看看效果，兩個(gè)使用方式基本沒有差別，不過實(shí)際效果嘛：

• Win8.1：可以選擇SkyDrive，本機(jī)磁盤，網(wǎng)上鄰居的共享文件，甚至第三方應(yīng)用提供的接口的文件選擇。
• WP8.1：不錯(cuò)，沒Win8.1這么強(qiáng)，但已經(jīng)可以自由瀏覽可訪問的目錄，包括SD卡，而且SD卡已經(jīng)有寫入權(quán)限，不用走后門了。

以后第三方軟件，就可以自由打開保存文件了，例如下載視頻歌曲等文件，就可以下載到SD卡，其他軟件也可以訪問。

雖然說表面看來，WP8.1和Win8.1的WinRT已經(jīng)非常接近了，但實(shí)際還是有所不同的。例如Windows.UI.Xaml.Controls.Pivot是WP上的樞紐視圖控件，在Win8.1上就木有。例如Windows.UI.Xaml.Controls.Hub在WP8.1和Win8.1上都有，但展現(xiàn)形式不同。WP8.1上就是以前的全景視圖的樣子，Win8.1嘛，你知道的。

就跟Windows.Storage.Pickers.FileOpenPicker，都是文件選擇器，用法也基本一樣，但功能和展現(xiàn)形式不見得一樣。

PS：winmd是什么，可以認(rèn)為是新一代的dll，winmd程序集可以被C++，C#，JS調(diào)用。winmd包含元數(shù)據(jù)，意思就是調(diào)用winmd程序集就像調(diào)用Net的類庫一樣簡單。

反正我覺得8.1開始，是很有必要遷移到Windows Runtime了，特別是要跨平臺(Win8/RT/WP)開發(fā)的。Windows Phone和Windows 8.1的Windows Runtime既然已經(jīng)如此靠近了。未來就算改也是更接近而已，繼續(xù)加強(qiáng)Windows Runtime而已?；静豢赡芡说絎indows Runtime。

還有就是Windows Runtime本身就是Native Code，而Silverlight是Managed Code。目前，微軟的C#也開始支持直接編譯Native Code了，這個(gè)已經(jīng)開始beta了。感覺上技術(shù)還是那些技術(shù)，silverlight是XAML+C#，Windows Runtime也是XAML+C#，但本質(zhì)已經(jīng)有所不同了。未來C#可能不再運(yùn)行在.Net框架上，而是直接編譯native code了。

可以理解為C++的運(yùn)行效率，C#的開發(fā)效率么？

唉，C#可以編譯Native Code的工作早點(diǎn)想起來做，讓C#可以脫離Net框架運(yùn)行，或許Winform早占領(lǐng)桌面程序了。至少我最關(guān)心的一點(diǎn)，第三方程序，可以打開有權(quán)訪問的任意目錄了，第三方程序不用走后門，也可以讀寫寫SD卡了。

反正我覺得8.1開始，是很有必要遷移到Windows Runtime了，特別是要跨平臺(Win8/RT/WP)開發(fā)的。但我覺得silverlight可能到頭了，雖然WP8.1新加的功能，silverlight8.1仍然提供支持，8.0項(xiàng)目可以直接升級silverlight 8.1享受新功能。但我很擔(dān)心未來WP8.2如果帶來新特性，有可能木有silverlight 8.2了。就像當(dāng)年的XNA，只是兼容XNA開發(fā)的已有程序而已，XNA本身已經(jīng)不會更新了。

未來不需要兩種不同的C#+XAML。

當(dāng)年Windows Phone和Windows不是一個(gè)部門，而且WP部門的理念完全不同于Windows。不然WP8.0就該兼容WP7的silverlight時(shí)，保留盡量完整的Windows Runtime了。畢竟WP8.0和Win8同期開發(fā)的，Win8一開始是完整的Windows Runtime，而WP8.0卻是個(gè)渣。同期開發(fā)的東西故意把WP的Windows Runtime搞的面目全非，現(xiàn)在才來補(bǔ)全，根本說不過去。

你看RT和Win8都是Windows 部門的，多好，除了ARM不兼容舊桌面程序外。它們從內(nèi)到外都做成一個(gè)樣子，月經(jīng)補(bǔ)丁一起打，8.1,8.1 Update都同時(shí)升級。我覺得5年前也就是Win8和WP8開始開發(fā)的時(shí)候，WP和Windows屬于一個(gè)部門。那么WP8.0一出生，Windows Runtime就不可能相對Win8如此殘缺需要現(xiàn)在慢慢補(bǔ)回來。

如果WP一開始就是Windows 團(tuán)隊(duì)開發(fā)，Windows團(tuán)隊(duì)一定是想著怎么盡量共享代碼。去掉桌面，精簡體積，為手機(jī)優(yōu)化界面功能，兼容WP7的silverlight應(yīng)用。記得當(dāng)年，live.com上面維護(hù)的聯(lián)系人分組和頭像，和Windows Phone 7同步到人脈的分組和頭像，完全不相干。你就知道，大公司病多嚴(yán)重，各部門溝通多差。

Windows Runtime是Native code，是Win32 com的新的封裝形式。但加入一個(gè)很重要的特性，就是元數(shù)據(jù)，使得調(diào)用WinRT如同Net 類庫一樣簡單方便。以前C#就算預(yù)編譯，仍然無法脫離Net框架，是因?yàn)榭蚣鼙旧淼某绦蚣际沁\(yùn)行在Net虛擬機(jī)上。所以以前只是所謂的預(yù)編譯，不能整整的Native code，所以C#直接編譯和所謂預(yù)編譯沒有本質(zhì)區(qū)別了。只是先后的問題，比預(yù)編譯再早一點(diǎn)而已，類似的還有云編譯，都是先后問題，沒解決本質(zhì)問題。

所以以前談C#直接編譯Native code是根本沒有意義的，都要運(yùn)行在.net框架下。而現(xiàn)在，一套類似Net的原生庫已經(jīng)有現(xiàn)成了就是WIndows Runtime，雖然其目前無法代替Net框架。所以C#直接編譯Native code，也就變成順理成章的事情。

Windows Runtime絕對不是.Net升級版，基本上除了借鑒Net的元數(shù)據(jù)，讓開發(fā)友好跨語言調(diào)用，其他方面沒有任何相同點(diǎn)。winrt和.net不存在合并，否者就不會發(fā)展獨(dú)立發(fā)展Windows Runtime了。一個(gè)是在.Net虛擬機(jī)上提供了一套API。一個(gè)是Win32 com基礎(chǔ)上實(shí)現(xiàn)了一套API。借鑒了Net的元數(shù)據(jù)，使開發(fā)更加容易。意思就是把本質(zhì)根本不同的東西。做的表面上一樣，使用Windows Runtime和使用Net框架一樣友好。

開發(fā)者以前用C#開發(fā)Net程序，現(xiàn)在用C#開發(fā)Windows runtime程序，除了API的了解，可以說沒有學(xué)習(xí)成本。而讓Net程序員從winform開發(fā)桌面程序改為用C++開發(fā)桌面程序，可以說是非常高的學(xué)習(xí)成本。但這兩個(gè)本質(zhì)不同的東西，功能存在大量重疊，開發(fā)者使用起來也差不多。就像VB和C#都可以做Net開發(fā)的感覺，共存。但共存總有一個(gè)熱門一個(gè)變得冷門。

可能隨著Windows Runtime的成熟，桌面也就是Windows Runtime的天下了。Net退居于服務(wù)端了。因?yàn)榛贜et的第三方資源不可能都重建。例如MVC，例如Entity Fremework，基于Net框架的很多項(xiàng)目都是獨(dú)立在發(fā)展而且已經(jīng)有很大市場。所以Windows Runtime并非要取代.Net框架，也沒有打算去實(shí)現(xiàn)Net框架的那一面。

Windows Runtime應(yīng)該沒有打算去參合Net用于網(wǎng)站那一部分。由于Windows Runtime并未去重復(fù)Net框架的很多功能。所以做開發(fā)，可能一邊用Net框架， 一邊用Windows Runtime。例如你想要用到的一個(gè)第三方組件Json.Net是基于Net框架的等等。Windows Runtime是原生代碼，Windows Runtime可以被C++，C#，JS調(diào)用。意思就是未來基于Windows Store開發(fā)，C#可能擁有和C++類似的地位。

以前都是C#快速開發(fā)， 核心算法部分可能還是C++。未來更多的東西可以C#通吃。

Windows Runtime有些功能仍然是通過Win32 API實(shí)現(xiàn)不能脫離Win32 API，但就Windows Runtime本身來說是如同Net框架一樣友好的

總結(jié)就是：Windows Runtime是新時(shí)代的Win32 api，借鑒了net的易用性。

但目前沒發(fā)現(xiàn)，要用它取代Net的的想法。

Windows Runtime主要是Windows本身的開發(fā)，就像以前Win32做桌面應(yīng)用，現(xiàn)在WIndows Runtime做跨平臺觸屏應(yīng)用?，F(xiàn)在乃至未來可以預(yù)見的時(shí)間，都不會取代Net。微軟自己維護(hù)的一些基于Net的開源項(xiàng)目，例如MVC3,4,5框架,Entity Framework等，都不會基于Windows Runtime重建。Windows Runtime絕對不是.Net升級版，基本上除了借鑒Net的元數(shù)據(jù)，讓開發(fā)友好跨語言調(diào)用，其他方面沒有任何相同點(diǎn)。和Net完全沒有繼承性，所有API都是與Net無關(guān)的重建的一套原生的實(shí)現(xiàn)。

首先第一點(diǎn)，根本的一點(diǎn)，Windows Runtime本身都是原生代碼，并非運(yùn)行在虛擬機(jī)上，原生的實(shí)現(xiàn)或是對Win32 api之類的直接調(diào)用。簡單粗暴的理解，就是com加上元數(shù)據(jù)，沒有什么中間語言，所以除了C++加Windows Runtime，自始至終是原生代碼。之前用C#+Windows Runtime就會出現(xiàn)一個(gè)很尷尬的局面，就是同時(shí)在用Net框架和Windows Runtime。本質(zhì)有點(diǎn)類似于以前Net程序Interop調(diào)用Win32 API的感覺，只是說現(xiàn)在使用的是更友好的Windows Runtime。

所以C#能像C++一樣編譯原生代碼，脫離Net框架，在WIndows Runtime出現(xiàn)后，也就變得順理成章。

以前Net的本身是中間語言，本是運(yùn)行時(shí)的即時(shí)編譯，所謂的優(yōu)化手段例如安裝后或后臺預(yù)編譯，甚至后來的云編譯。

無非是編譯的時(shí)機(jī)不同，把運(yùn)行時(shí)影響速度的即時(shí)編譯改在了運(yùn)行前準(zhǔn)備好，沒有改變運(yùn)行在Net框架上的本質(zhì)。

而這次，Net Native時(shí)C#基于Windows Runtime，是真的徹底的原生代碼，至始至終都可以獨(dú)立于Net框架了。