Windows Runtime - 面向對象化的C++(并非意味著托管)

>>>  技術話題—商業文明的嶄新時代  >>> 簡體     傳統

  Windows 8的開發平臺總體上分為兩部分:一是全新的WinRT,界面搭配Metro style,二是傳統的Win32、.NET(SL)、IE三大平臺,界面為傳統窗體風格。其中全新的WinRT被微軟視為開發者的未來。

  WinRT平臺開發又細分為兩大方式:一是C/C++搭配XAML,或C#/VB搭配XAML,二是JavaScript搭配HTML/CSS。C、C++、C#、VB、Javascript全部可以直接調用WinRT APIs,這樣微軟將Native(本地)、Managed(托管)、Dynamic(動態)三大語言運行機制統一了起來。可見,WinRT是微軟將Win32、.NET(SL)、IE三大平臺進行整合的產物。

  回顧歷史,Win32是微軟最早推出、發展時間最久的一個開發平臺。C++搭配Windows SDK或C++搭配MFC等類庫或VB均是Win32平臺的開發方式。而COM技術,也作為那個時代的組件模型,為微軟的發展建立了不可磨滅的功勛。2000年,微軟推出.NET戰略,.NET平臺開始走入主流。WinForm、WPF以及之后的Silverlight均是.NET時代的產物。而Assembly組件模型,也逐步地在很多領域替代COM技術。

  Win32時代,我稱之為“PC時代”。那時的硬件性能普遍較低,所以Win32平臺具有非常高效的性能。但是開發效率低下,內存管理復雜,COM技術晦澀難懂、沒有統一的數據傳遞模型等這些問題,使Win32難以適應網絡發展的需要。于是微軟推出.NET戰略,“網絡時代”來臨。.NET平臺從2000年開始,到現在,已經發展了10年左右,微軟依次給我們帶來了.NET1.1、.NET2.0、.NET3.0、.NET3.5。

  .NET4.0。.NET平臺解決了Win32平臺的問題,設計了非常優雅的開發接口和龐大類庫,開發效率提升了,內存管理引入了GC,Assembly組件模型非常簡單,而且還解決了COM技術造成的DLL Hell問題,也帶來了統一的數據傳遞模型XML。但是.NET平臺從一開始,就暴露了缺點,由于.NET是建立在Win32基礎上的托管API接口,性能下降,系統資源消耗嚴重,而且和Win32平臺交互困難。隨著硬件的提升、.NET平臺的不斷發展優化,性能得到部分提升,跨平臺調用方案也一定程度解決了Win32平臺的交互問題。但是這些改變,沒有根本解決問題,即便微軟后來又推出了“改良的.NET平臺”——Silverlight,但.NET平臺的缺點還是隨著“移動時代”的來臨,再次暴露無疑。此時WinRT上場了!

  那么,WinRT給我們帶來了什么呢?WinRT是“移動時代”需求的產物,那肯定會充滿“移動時代”的色彩。第一,WinRT給我們帶來了界面上的革命:Metro。新的Metro風格界面更加適合觸摸屏操作,更加適合多尺寸的顯示屏,全屏的顯示方式突出了以內容為中心的理念。第二,WinRT給我們帶來了全新的系統級Native API,WinRT APIs是Native的,而且直接建立在系統內核之上,并且還自動獲得硬件加速,包裝非常類似.NET,既高效又易用。第三,WinRT采用了MVC模式,做到了界面和邏輯的很好分離。XAML和HTML5作為兩大界面標記語言同時被采用。第三,WinRT給我們帶來了新的組件模型:C++組件擴展。該組件模型是COM和Assembly技術的結合體,可同時被Native、Managed和Dynamic三種類型的語言直接調用。WinRT APIs本身就是使用的C++組件擴展技術實現的,所以做到了C、C++、C#、VB、Javascript的直接調用。WPF、SL、網頁應用均可以較小代碼調整,即可在WinRT平臺運行。第四,WinRT同時支持X86/64、ARM架構,即可在PC上運行,又可在Pad上運行。第五,WinRT全面采用了異步技術。在WinRT中,微軟一直遵循一個簡單的規則:如果一個API預計耗時超過50毫秒,那么API就是異步的,這樣就能確保Metro UI上的操作體驗是最好的。第六,WinRT程序在不顯示的時候,自動轉換為掛起狀態,不占用CPU,節省了電能消耗。

  對于傳統平臺開發,也稍微做下介紹。IE平臺更新到了IE10版本,.NET平臺更新到了.NET4.5版本。另外,專門提下,傳統的網頁插件技術已經不能在Metro風格的IE中獲得支持。而新的插件技術或者是否還提供插件技術尚不得而知。

  開發工具對應的是Visual Studio 11 和 Expression Blend 5。

  WinRT是一個新的API 集合,具有以下特性:

  • 它實現了Metro UI規范的UI庫
  • 為Windows開發人員提供一個簡單的UI編程模型,你不需要學習Win32API的那些復雜的API了
  • 它使用XAML-base的UI系統
  • API都設計成了異步的
  • 它和.NET一樣是個沙箱的API,自成體系,用于創建AppStore上的應用程序。
  • API的元數據格式是ECMA335,和.NET一樣的標準。這是不是意味著以后Mono也可以在xUnit上去實現這樣的API呢?

  WinRT包裝的新的用戶界面系統,和Win32API一樣是Com的上層。

  Windows運行時(WinRT)是為了在Windows上給用戶提供一種流暢且安全的應用體驗。WinRT會受到.NET、C++、以及JavaScript三者的影響。WinRT不會取代CLR或Win32,而是為那些使用不同語言編寫的應用程序提供統一支持,以便它們可使用新的Metro風格用戶界面運行于Windows之上。 

  WinRT不是為了取代.NET或Win32提供的所有功能,但是它是一個公共平臺,以便那些使用不同語言編寫的應用程序可使用新的Metro風格界面來運行。當混合C#應用程序基于WinRT創建Metro風格用戶界面時,程序中將仍能執行LINQ查詢,對于存儲、網絡、新式應用程序的安全性等方面同樣能執行LINQ查詢。完整的運行時架構如下圖所示:

  在類型上,WinRT必須提供語言無關的類型——integer(整數)、enumerations(枚舉)、structures(結構)、arrays(數組)、interfaces(接口)、generic interfaces(泛型接口)、以及runtime classes(運行時類)。引入了被稱之為HSTRING的新字符串類型,該類型允許在不進行任何數據復制的情況下,在應用程序與運行時環境之間傳輸字符串。

  每個WinRT對象都會對應一些接口,其中有兩個接口屬于每個對象:IUnknown接口,熟悉的COM接口;以及IInspectable接口,用于根據對象所包含的元數據來發現有關該對象的信息。一個對象可能通過接口提供其他功能,然而運行時類會把這些接口集中公開出來。例如,一個FileInformation對象擁有由FileInformation類公開的IStorageItemInformation、IStorageItem、IStorageFile三個接口。

  WinRT對象在編譯時被公開給C++應用程序,而對于C#或VB.NET應用程序而言,對WinRT對象的綁定一部分是在編譯時完成的,另一部分則是在運行時完成的。HTML或JavaScript應用程序只有在運行時可以看到WinRT對象,而且元數據是動態生成的。

  Metro界面運行在一個不可重入的單線程之上,然而應用程序的其余部分可以從線程池中使用由運行時環境所自動提供的多線程。

  開發者可以用C#語言創建可供C++或JavaScript的WinRT應用程序使用的Windows運行時組件,然而須要遵守一系列規則:“結構體只能擁有公共數據字段;只允許對XAML控件使用繼承,其它類型都必須使用sealed關鍵字;只支持系統提供的泛型。” 


chuncn 2013-08-31 16:55:50

[新一篇] 使用緩存的9大誤區

[舊一篇] 開發和常用工具推薦清單
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表