開(kāi)發(fā)者角度看Windows Phone8.1
Windows Phone8.1之后,開(kāi)發(fā)者有三種選擇。
- 繼續(xù)用silverlight 8.0,反正向下兼容,如果APP也不需要新功能就這樣吧。
- 升級(jí)到silverlight 8.1,如果需要8.1提供的新功能,silverlight8.0項(xiàng)目可以直接升級(jí)到8.1,然后開(kāi)發(fā)新功能即可。
- 遷移到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了。
一張圖說(shuō)明問(wèn)題,windows.winmd,也就是Windows Runtime提供的API:
圖中分別列出了Win8.1,WP8.1,和WP8的windows.winmd的API,下原圖對(duì)著看一幕了然:
(點(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開(kāi)發(fā)文檔了,不過(guò)手機(jī)PC畢竟還有一些區(qū)別,所以有PC和手機(jī)圖標(biāo)表明該功能的適用場(chǎng)景(如圖

下面我首先看了下自己比較關(guān)注的方面,文件訪問(wèn)。
WP8.1已經(jīng)有和Win8/RT同樣的文件選擇器,Windows.Storage.Pickers.FileOpenPicker。
看看效果,兩個(gè)使用方式基本沒(méi)有差別,不過(guò)實(shí)際效果嘛:
- Win8.1:可以選擇SkyDrive,本機(jī)磁盤(pán),網(wǎng)上鄰居的共享文件,甚至第三方應(yīng)用提供的接口的文件選擇。
- WP8.1:不錯(cuò),沒(méi)Win8.1這么強(qiáng),但已經(jīng)可以自由瀏覽可訪問(wèn)的目錄,包括SD卡,而且SD卡已經(jīng)有寫(xiě)入權(quán)限,不用走后門(mén)了。
以后第三方軟件,就可以自由打開(kāi)保存文件了,例如下載視頻歌曲等文件,就可以下載到SD卡,其他軟件也可以訪問(wèn)。


雖然說(shuō)表面看來(lái),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)形式不見(jiàn)得一樣。
PS:winmd是什么,可以認(rèn)為是新一代的dll,winmd程序集可以被C++,C#,JS調(diào)用。winmd包含元數(shù)據(jù),意思就是調(diào)用winmd程序集就像調(diào)用Net的類庫(kù)一樣簡(jiǎn)單。
反正我覺(jué)得8.1開(kāi)始,是很有必要遷移到Windows Runtime了,特別是要跨平臺(tái)(Win8/RT/WP)開(kāi)發(fā)的。Windows Phone和Windows 8.1的Windows Runtime既然已經(jīng)如此靠近了。未來(lái)就算改也是更接近而已,繼續(xù)加強(qiáng)Windows Runtime而已?;静豢赡芡说絎indows Runtime。
還有就是Windows Runtime本身就是Native Code,而Silverlight是Managed Code。目前,微軟的C#也開(kāi)始支持直接編譯Native Code了,這個(gè)已經(jīng)開(kāi)始beta了。感覺(jué)上技術(shù)還是那些技術(shù),silverlight是XAML+C#,Windows Runtime也是XAML+C#,但本質(zhì)已經(jīng)有所不同了。未來(lái)C#可能不再運(yùn)行在.Net框架上,而是直接編譯native code了。
可以理解為C++的運(yùn)行效率,C#的開(kāi)發(fā)效率么?
唉,C#可以編譯Native Code的工作早點(diǎn)想起來(lái)做,讓C#可以脫離Net框架運(yùn)行,或許Winform早占領(lǐng)桌面程序了。至少我最關(guān)心的一點(diǎn),第三方程序,可以打開(kāi)有權(quán)訪問(wèn)的任意目錄了,第三方程序不用走后門(mén),也可以讀寫(xiě)寫(xiě)SD卡了。
反正我覺(jué)得8.1開(kāi)始,是很有必要遷移到Windows Runtime了,特別是要跨平臺(tái)(Win8/RT/WP)開(kāi)發(fā)的。但我覺(jué)得silverlight可能到頭了,雖然WP8.1新加的功能,silverlight8.1仍然提供支持,8.0項(xiàng)目可以直接升級(jí)silverlight 8.1享受新功能。但我很擔(dān)心未來(lái)WP8.2如果帶來(lái)新特性,有可能木有silverlight 8.2了。就像當(dāng)年的XNA,只是兼容XNA開(kāi)發(fā)的已有程序而已,XNA本身已經(jīng)不會(huì)更新了。
未來(lái)不需要兩種不同的C#+XAML。
當(dāng)年Windows Phone和Windows不是一個(gè)部門(mén),而且WP部門(mén)的理念完全不同于Windows。不然WP8.0就該兼容WP7的silverlight時(shí),保留盡量完整的Windows Runtime了。畢竟WP8.0和Win8同期開(kāi)發(fā)的,Win8一開(kāi)始是完整的Windows Runtime,而WP8.0卻是個(gè)渣。同期開(kāi)發(fā)的東西故意把WP的Windows Runtime搞的面目全非,現(xiàn)在才來(lái)補(bǔ)全,根本說(shuō)不過(guò)去。
你看RT和Win8都是Windows 部門(mén)的,多好,除了ARM不兼容舊桌面程序外。它們從內(nèi)到外都做成一個(gè)樣子,月經(jīng)補(bǔ)丁一起打,8.1,8.1 Update都同時(shí)升級(jí)。我覺(jué)得5年前也就是Win8和WP8開(kāi)始開(kāi)發(fā)的時(shí)候,WP和Windows屬于一個(gè)部門(mén)。那么WP8.0一出生,Windows Runtime就不可能相對(duì)Win8如此殘缺需要現(xiàn)在慢慢補(bǔ)回來(lái)。
如果WP一開(kāi)始就是Windows 團(tuán)隊(duì)開(kāi)發(fā),Windows團(tuán)隊(duì)一定是想著怎么盡量共享代碼。去掉桌面,精簡(jiǎn)體積,為手機(jī)優(yōu)化界面功能,兼容WP7的silverlight應(yīng)用。記得當(dāng)年,live.com上面維護(hù)的聯(lián)系人分組和頭像,和Windows Phone 7同步到人脈的分組和頭像,完全不相干。你就知道,大公司病多嚴(yán)重,各部門(mén)溝通多差。
Windows Runtime是Native code,是Win32 com的新的封裝形式。但加入一個(gè)很重要的特性,就是元數(shù)據(jù),使得調(diào)用WinRT如同Net 類庫(kù)一樣簡(jiǎn)單方便。以前C#就算預(yù)編譯,仍然無(wú)法脫離Net框架,是因?yàn)榭蚣鼙旧淼某绦蚣际沁\(yùn)行在Net虛擬機(jī)上。所以以前只是所謂的預(yù)編譯,不能整整的Native code,所以C#直接編譯和所謂預(yù)編譯沒(méi)有本質(zhì)區(qū)別了。只是先后的問(wèn)題,比預(yù)編譯再早一點(diǎn)而已,類似的還有云編譯,都是先后問(wèn)題,沒(méi)解決本質(zhì)問(wèn)題。
所以以前談C#直接編譯Native code是根本沒(méi)有意義的,都要運(yùn)行在.net框架下。而現(xiàn)在,一套類似Net的原生庫(kù)已經(jīng)有現(xiàn)成了就是WIndows Runtime,雖然其目前無(wú)法代替Net框架。所以C#直接編譯Native code,也就變成順理成章的事情。
Windows Runtime絕對(duì)不是.Net升級(jí)版,基本上除了借鑒Net的元數(shù)據(jù),讓開(kāi)發(fā)友好跨語(yǔ)言調(diào)用,其他方面沒(méi)有任何相同點(diǎn)。winrt和.net不存在合并,否者就不會(huì)發(fā)展獨(dú)立發(fā)展Windows Runtime了。一個(gè)是在.Net虛擬機(jī)上提供了一套API。一個(gè)是Win32 com基礎(chǔ)上實(shí)現(xiàn)了一套API。借鑒了Net的元數(shù)據(jù),使開(kāi)發(fā)更加容易。意思就是把本質(zhì)根本不同的東西。做的表面上一樣,使用Windows Runtime和使用Net框架一樣友好。
開(kāi)發(fā)者以前用C#開(kāi)發(fā)Net程序,現(xiàn)在用C#開(kāi)發(fā)Windows runtime程序,除了API的了解,可以說(shuō)沒(méi)有學(xué)習(xí)成本。而讓Net程序員從winform開(kāi)發(fā)桌面程序改為用C++開(kāi)發(fā)桌面程序,可以說(shuō)是非常高的學(xué)習(xí)成本。但這兩個(gè)本質(zhì)不同的東西,功能存在大量重疊,開(kāi)發(fā)者使用起來(lái)也差不多。就像VB和C#都可以做Net開(kāi)發(fā)的感覺(jué),共存。但共存總有一個(gè)熱門(mén)一個(gè)變得冷門(mén)。
可能隨著Windows Runtime的成熟,桌面也就是Windows Runtime的天下了。Net退居于服務(wù)端了。因?yàn)榛贜et的第三方資源不可能都重建。例如MVC,例如Entity Fremework,基于Net框架的很多項(xiàng)目都是獨(dú)立在發(fā)展而且已經(jīng)有很大市場(chǎng)。所以Windows Runtime并非要取代.Net框架,也沒(méi)有打算去實(shí)現(xiàn)Net框架的那一面。
Windows Runtime應(yīng)該沒(méi)有打算去參合Net用于網(wǎng)站那一部分。由于Windows Runtime并未去重復(fù)Net框架的很多功能。所以做開(kāi)發(fā),可能一邊用Net框架, 一邊用Windows Runtime。例如你想要用到的一個(gè)第三方組件Json.Net是基于Net框架的等等。Windows Runtime是原生代碼,Windows Runtime可以被C++,C#,JS調(diào)用。意思就是未來(lái)基于Windows Store開(kāi)發(fā),C#可能擁有和C++類似的地位。
以前都是C#快速開(kāi)發(fā), 核心算法部分可能還是C++。未來(lái)更多的東西可以C#通吃。
Windows Runtime有些功能仍然是通過(guò)Win32 API實(shí)現(xiàn)不能脫離Win32 API,但就Windows Runtime本身來(lái)說(shuō)是如同Net框架一樣友好的
總結(jié)就是:Windows Runtime是新時(shí)代的Win32 api,借鑒了net的易用性。
但目前沒(méi)發(fā)現(xiàn),要用它取代Net的的想法。
Windows Runtime主要是Windows本身的開(kāi)發(fā),就像以前Win32做桌面應(yīng)用,現(xiàn)在WIndows Runtime做跨平臺(tái)觸屏應(yīng)用?,F(xiàn)在乃至未來(lái)可以預(yù)見(jiàn)的時(shí)間,都不會(huì)取代Net。微軟自己維護(hù)的一些基于Net的開(kāi)源項(xiàng)目,例如MVC3,4,5框架,Entity Framework等,都不會(huì)基于Windows Runtime重建。Windows Runtime絕對(duì)不是.Net升級(jí)版,基本上除了借鑒Net的元數(shù)據(jù),讓開(kāi)發(fā)友好跨語(yǔ)言調(diào)用,其他方面沒(méi)有任何相同點(diǎn)。和Net完全沒(méi)有繼承性,所有API都是與Net無(wú)關(guān)的重建的一套原生的實(shí)現(xiàn)。
首先第一點(diǎn),根本的一點(diǎn),Windows Runtime本身都是原生代碼,并非運(yùn)行在虛擬機(jī)上,原生的實(shí)現(xiàn)或是對(duì)Win32 api之類的直接調(diào)用。簡(jiǎn)單粗暴的理解,就是com加上元數(shù)據(jù),沒(méi)有什么中間語(yǔ)言,所以除了C++加Windows Runtime,自始至終是原生代碼。之前用C#+Windows Runtime就會(huì)出現(xiàn)一個(gè)很尷尬的局面,就是同時(shí)在用Net框架和Windows Runtime。本質(zhì)有點(diǎn)類似于以前Net程序Interop調(diào)用Win32 API的感覺(jué),只是說(shuō)現(xiàn)在使用的是更友好的Windows Runtime。
所以C#能像C++一樣編譯原生代碼,脫離Net框架,在WIndows Runtime出現(xiàn)后,也就變得順理成章。
以前Net的本身是中間語(yǔ)言,本是運(yùn)行時(shí)的即時(shí)編譯,所謂的優(yōu)化手段例如安裝后或后臺(tái)預(yù)編譯,甚至后來(lái)的云編譯。
無(wú)非是編譯的時(shí)機(jī)不同,把運(yùn)行時(shí)影響速度的即時(shí)編譯改在了運(yùn)行前準(zhǔn)備好,沒(méi)有改變運(yùn)行在Net框架上的本質(zhì)。
而這次,Net Native時(shí)C#基于Windows Runtime,是真的徹底的原生代碼,至始至終都可以獨(dú)立于Net框架了。