如有問題歡迎指正。

下載地址：

幻燈片http://files.cnblogs.com/lxconan/WinRTIntroPPT.pdf

附加說明http://files.cnblogs.com/lxconan/WinRTIntro.pdf

1   概述

這篇的標題叫做Windows RT Introduction而非Windows 8 Introduction是想強調(diào)此次介紹是從開發(fā)人員的角度而不是普通用戶的角度出發(fā)的。同時，我們關(guān)注的是Metro Style應(yīng)用而不是傳統(tǒng)的Win32應(yīng)用程序的開發(fā)。

實際上，使用C#或者HTML + Javascript書寫一個Hello world應(yīng)用的代碼例子已經(jīng)在網(wǎng)上泛濫了。但是僅有一個Hello world并不能夠說你掌握了Win RT的開發(fā)。從Pro的角度來說我們應(yīng)該弄清楚整件事情的細節(jié)。那么首先就應(yīng)當(dāng)是他的架構(gòu)。這樣寫起程序來才能心定。

2   Windows 8 Metro與Desktop模式

2.1  兩種模式

Windows 8的應(yīng)用程序顯示模式目前有兩種，定義在METRO_MONITOR_MODE中：即傳統(tǒng)的桌面模式（MMM_Desktop）以及Metro模式（MMM_Metro）。如果你是Windows Phone用戶的話可能就會對Metro比較熟悉。事實上，微軟在2009年啟動Windows 8的研發(fā)工作時目標是創(chuàng)造一個完全不同以往的操作系統(tǒng)，完全不以之前的操作系統(tǒng)為藍本。而后發(fā)現(xiàn)Desktop應(yīng)用是不可或缺的部分而將兩個部分進行合并。一開始用可能會有些別扭，但是我估計開發(fā)人員半天之內(nèi)就能夠熟練使用這個系統(tǒng)了。

2.2  Metro和Desktop的一些不同

既然有兩種模式那么我們自然就會關(guān)注他們的不同點。這個問題應(yīng)該從架構(gòu)圖上做一下說明但是我們可以先有一些直觀的認識。

2.2.1   Message Loop

消息處理的編程是傳統(tǒng)Desktop應(yīng)用程序的重要部分。你需要書寫維護Message Loop的代碼。例如：在WinMain調(diào)用（或者其子例程中）你需要書寫類似

while (::GetMessage(&message, NULL, 0, 0)) { 
   ::TranslateMessage(&message); 
   ::DispatchMessage(&message); 

而在Window創(chuàng)建之前候你一定指定了

WNDCLASS wndClass; 
// ... 
wndClass.lpfnWndProc = WndProc; 

這樣你就可以在WndProc函數(shù)中決定特定message的流向了。對于繪圖來說，你一定是接受了WM_PAINT消息，然后執(zhí)行了區(qū)域重繪。

但在Metro App中這些都已經(jīng)隱藏了，而且消息的細節(jié)也可能發(fā)生了變化。Metro App中你看不到消息循環(huán)。一切關(guān)于界面消息的分發(fā)都隱藏在了CoreDispatcher中。因此如果你用Spy++去試探Metro App的消息循環(huán)那么你什么都抓不到。

2.2.2   Display

在傳統(tǒng)的Desktop應(yīng)用程序中，繪圖可能通過GDI，GDI+，DirectDraw，DirectX進行。同樣通過捕獲WM_PAINT消息或者當(dāng)系統(tǒng)處于IDLE的時候進行繪圖（對于游戲編程來說）。

而Metro App不會再支持GDI和GDI+，在Metro App中繪圖只能通過DirectX來進行。確切的說是Direct3D和新公布的Direct2D、Direct Write API。因此Metro應(yīng)用的所有繪圖都是希望是硬件加速的。這種繪圖更高效，解放CPU，而且一般不需要處理復(fù)雜的Dirty Region Repaint。

2.2.3   Life Cycle

Metro App并沒有關(guān)閉窗口這種按鈕。其生命周期是由系統(tǒng)托管的。系統(tǒng)會決定僅僅是掛起應(yīng)用執(zhí)行還是需要完全銷毀應(yīng)用進程。這和一般意義上的Desktop應(yīng)用程序不一樣。（當(dāng)然，你也可以使用Alt+F4顯示的結(jié)束Metro App的執(zhí)行）。

2.2.4   Share & Communication

傳統(tǒng)的桌面應(yīng)用程序有多種手段進行公共組建的公用或IPC。但是在Metro App中，隔離是一個很重要的概念，應(yīng)用的可執(zhí)行部分，運行庫，Isolated Storage都是獨立的，不能夠共用。同樣，不能夠使用傳統(tǒng)的IPC機制。應(yīng)用程序的互動僅僅可以通過內(nèi)置的Contracts進行，關(guān)于這一部分內(nèi)容可以查看MSDN：

http://msdn.microsoft.com/en-us/library/windows/apps/hh464906.aspx

2.2.5   Portability

傳統(tǒng)的Desktop應(yīng)用程序的支持大多為x86/64架構(gòu)的處理器。由于Metro環(huán)境可以完整運行在ARM處理器上是一個重要的特性，因此Metro App可以運行在ARM處理器上，即同時部署在PC和移動設(shè)備上。

2.2.6   OS Access

當(dāng)然為了Portability的要求，必然要求應(yīng)用不能夠越過Win RT的抽象，因此Metro是不能像Desktop App那樣訪問所有的Windows API的。

3   從Windows 8 API的架構(gòu)圖看Windows RT

我們對Windows RT的介紹都將圍繞著這個圖展開。

在這個圖中，***層的是NT的內(nèi)核；在其上是Windows子系統(tǒng)。實際上NT至少有三個子系統(tǒng)，Windows子系統(tǒng)，POSIX子系統(tǒng)（Unix）和OS/2子系統(tǒng)。POSIX子系統(tǒng)和OS/2子系統(tǒng)實際還是在使用Windows子系統(tǒng)。 在Windows子系統(tǒng)上劃分了不同的運行時（橙色）和程序庫（淺藍色），最上面的綠色是我們使用的各種開發(fā)語言。

這個架構(gòu)圖實際上說明了一切。并且消除了很多誤解：

（1）***個誤解是INFOQ指出的Windows RT和Win32是完全分開的。這源于微軟發(fā)布的一幅飽受批評的架構(gòu)圖，在那張架構(gòu)圖中，Windows RT和Windows子系統(tǒng)竟然是并排排列的。這是很荒謬的，Windows RT實際上基于Windows子系統(tǒng)。首先Windows RT完全基于COM；其次Windows RT利用了一部分現(xiàn)有的Win32 API；其余的部分Windows RT則直接訪問NT內(nèi)核。

（2）第二個誤解是C++/CX。C++/CX是微軟推薦的開發(fā)Windows RT的方式。他主要隱藏了COM的復(fù)雜性。關(guān)于這個問題我們后續(xù)會有說明。這個誤解是C++/CX實際就是C++ CLI。實際上這是兩個完全不同的東西，C++ CLI是運行在托管環(huán)境下的，而C++/CX完全是Native的。

3.1  Windows RT僅用于Metro應(yīng)用

從架構(gòu)圖中可以看出，Win RT僅僅用于Metro應(yīng)用。并秉承了我們剛才介紹的，簡單部署，沒有共享的組件，沒有IPC，等等。

3.2  Windows RT構(gòu)建與COM之上

這也是為什么說Windows RT是構(gòu)建與Win32之上，因為COM是Win32重要的組成部分。這意味著：

（1）你可以用之前所有的消費COM的方式來使用Windows RT，你可以用C，你可以用ATL或者新的WRL；

（2）WRL完全符合傳統(tǒng)的C++語法，這意味著你可以使用不同的編譯器（例如Intel C++編譯器）來構(gòu)建Metro應(yīng)用。但是微軟顯然希望大家都來使用C++/CX，WRL的文檔跟沒有差不多，現(xiàn)在也看不到一個完整的例子出現(xiàn)。

3.3  Windows RT限制了系統(tǒng)API的調(diào)用

Win RT是基于COM的，但是COM僅僅是一個二進制協(xié)議而已。在COM Interface實現(xiàn)中從技術(shù)上講還是在調(diào)用Win32 API。但由于前面介紹的Win RT的設(shè)計要求，系統(tǒng)API的調(diào)用需要受到嚴格的限制。僅僅支持有限的API調(diào)用，因此在你希望使用一個Win32 API時，一定要查詢MSDN上的Applied To一節(jié)，看看是否是Metro Style App | desktop App。

同樣的道理，.NET的某些方法也在進行著系統(tǒng)調(diào)用，因此在使用.NET開發(fā)Metro Style應(yīng)用程序的時候也并不是所有的程序集都能夠支持。當(dāng)然，如果使用P-Invoke的方式調(diào)用Win32 API那么危險性就會更大。

總之，在Metro應(yīng)用中調(diào)用不支持的Win32 API會有如下的后果：

（1）發(fā)生一個Runtime Exception；

（2）應(yīng)用程序失去響應(yīng)，尤其是在使用和消息循環(huán)相關(guān)的代碼時。例如對Metro App進程使用WaitForSingleObject(hProcess)。

（3）調(diào)用成功，但是你的Metro App應(yīng)用會被Windows Store駁回。

按照上述分析，那么即使你存在相當(dāng)可觀的COM代碼庫，也需要巨大的努力才能夠保證他們在Metro App上正確運行（消除非法的系統(tǒng)調(diào)用）。對于新的應(yīng)用來說，為了避免書寫大量的COM開發(fā)代碼，***使用C++/CX進行開發(fā)了。

3.4  C++/CX

為什么會有C++/CX呢？這可以聯(lián)想n年前我們?yōu)榱吮苊釩++開發(fā)COM的冗長的代碼，轉(zhuǎn)而使用C開發(fā)關(guān)鍵程序，而使用Visual Basic創(chuàng)建COM組件。現(xiàn)在時間到了2012年，VB6已經(jīng)不在考慮范圍之內(nèi)了，于是C++/CX取代了他的位置。

C++/CX是Native的，但是它的語法為什么能夠和C++ CLI保持近乎一致呢？這是因為Win RT本身雖然是Native的，但它以.NET兼容的方式暴露了元數(shù)據(jù)。但是我們在編程中要時刻想到，我們在操作實打?qū)嵉腘ative對象。根本沒有什么垃圾收集器在幫助我們。

那么為什么不單純使用.NET開發(fā)Metro App呢？這是因為對于移動設(shè)備來說，CPU的速度和電池是兩大局限，因此在近一年，Go Native的大潮終于襲來。目前：

（1）iOS使用Objective-C進行程序開發(fā)，而且在移動設(shè)備上也是沒有垃圾收集器的，需要手動釋放使用的內(nèi)存；

（2）Android一開始使用Java進行開發(fā)，但是在糟糕的性能和社區(qū)的強大壓力下，終于開放了C/C++開發(fā)接口；

（3）WP7/8也出現(xiàn)了類似Android的情況。

目前客戶端應(yīng)用向更?。ê诵膽?yīng)用向服務(wù)器移動），更快（運行速度快，耗電?。换ジS富（沒有動畫你都對不起觀眾）的方向發(fā)展。因此開放Native接口是大勢所趨，C/C++順理成章的在Windows 8強勢回歸了。

但是，用.NET開發(fā)Metro應(yīng)用也是一個不錯的選擇，尤其你的應(yīng)用沒有密集的運算（游戲）的情況下。你可以參考幻燈片中的Cheat Sheet。

原文鏈接：http://www.cnblogs.com/lxconan/archive/2012/09/09/2677957.html