我安裝好Win8 CTP后做的第一件事情就是用調(diào)試器研究Win8各個(gè)組件的協(xié)作關(guān)系。從我半天的研究結(jié)果看來，Win8真是一個(gè)讓我愛不釋手的產(chǎn)品。Win8里面涉及到的很多技術(shù)正好也是我的興趣所在。這篇文章簡單回顧一下這些技術(shù)的變遷，優(yōu)缺點(diǎn)，和對(duì)Win8的影響.
注意，下面提到的對(duì)Win8的分析, 是基于公開的Win8 CTP來做的。相信Win8面世的時(shí)候，這些技術(shù)和細(xì)節(jié)，都會(huì)發(fā)生重大改變。所以這篇文章不具備實(shí)踐上的指導(dǎo)價(jià)值。
COM - Common Object Model 通用組件模型
COM是上個(gè)世紀(jì)中期設(shè)計(jì)出來的偉大產(chǎn)品。COM旨在解決軟件復(fù)用的問題。在COM以前，大家都是用代碼級(jí)別的復(fù)用，常見的就是C/C++的庫，無論是原代碼庫還是lib庫，都是需要編譯后才能重用的。COM使得技術(shù)人員可以在二進(jìn)制上進(jìn)行復(fù)用。從Win95, OLE32和Office95系列開始，COM就是微軟平臺(tái)上的一個(gè)技術(shù)基石，無論是DirectX API, 還是最常見的剪貼板，以及后來.NET Framework的host接口，都離不開COM。但任何偉大的產(chǎn)品，都有局限的一面。COM在局限性在下面一些地方。
STA/MTA/NTA等等線程模型過于復(fù)雜
線程模型，特別是STA，設(shè)計(jì)的目的是方便使用者。但COM的線程模型嚴(yán)重依賴于太多系統(tǒng)組件，比如Win32 Message, RPC和Windows系統(tǒng)服務(wù)，使得程序員需要熟悉和了解太多系統(tǒng)知識(shí)才可以正確地使用線程模型。否則用STA導(dǎo)致死鎖簡直就是家常便飯。
開發(fā)工具沒有提供足夠支持
COM和Visual Studio 6.0的關(guān)系，就如同現(xiàn)在CLR2/VS2005, CLR3.5/VS2008和CLR4/VS2010的關(guān)系一樣鐵。使用COM開發(fā)，當(dāng)時(shí)的選擇要么是VB6，要么用ATL。這兩者都有天生的局限。VB6適合企業(yè)開發(fā)，特別是當(dāng)時(shí)流行的MIS系統(tǒng)，數(shù)據(jù)庫系統(tǒng)這樣的CS應(yīng)用，但是VB6不夠靈活。而且VB6里面由于缺少多線程支持，無法用MTA的模型。ATL功能強(qiáng)大，足夠靈活，但是使用起來特別復(fù)雜。每次實(shí)現(xiàn)一個(gè)接口，都要做一大堆C++的儀式性工作，比如實(shí)現(xiàn)多重繼承，定義新的模板，使用大量的C宏。神經(jīng)再粗大的程序員，都經(jīng)不起這樣用C++的。
無止境地?cái)U(kuò)充到DCOM, COM+, DTC, MSMQ以及后來的.NET Remoting/WCF, 使得最后的復(fù)雜度無法控制
為了更好地適應(yīng)企業(yè)級(jí)別的開發(fā)，COM被進(jìn)一步延伸和演化成了DCOM和COM+。所謂"企業(yè)級(jí)別"，其實(shí)是指對(duì)安全性和可伸縮性的更高要求。經(jīng)典的COM是一個(gè)進(jìn)程內(nèi)模型，無法讓不同的代碼運(yùn)行在不同的帳號(hào)下的，因?yàn)橥粋€(gè)進(jìn)程只能啟動(dòng)在唯一的帳號(hào)下。雖然通過impersonate等方法可以適當(dāng)?shù)亟鉀Q問題，但是為了讓安全模型更為全面，正確的做法是讓不同的接口實(shí)現(xiàn)，能夠跨越進(jìn)程甚至跨越機(jī)器等安全邊界運(yùn)行，要能夠賦予不同的接口不同的安全級(jí)別，能夠和域帳號(hào)集成，支持不同等級(jí)的加密等等。遠(yuǎn)程通用組件模型，也就是DCOM就這樣誕生了。讀者可以嘗試運(yùn)行以下dcomcnfg.exe這個(gè)工具，展開一些節(jié)點(diǎn)，看看屬性頁，就能體會(huì)到DCOM的功能是多么讓人眼花繚亂了。對(duì)于可伸縮性，微軟更上一層樓，在DCOM的基礎(chǔ)上加入了對(duì)象池和新的同步模型做成了COM+。風(fēng)靡十年的ASP，就是運(yùn)行在COM+框架下的最好例子。更讓人嘆為觀止的是，微軟把DTC和MSMQ的設(shè)計(jì)也和COM+模型綁定起來。陌生的讀者可能不了解DTC是個(gè)多么nb的東西。簡單說DTC是可以讓程序員一行代碼都不用寫，就讓SQL Server和Oracle的數(shù)據(jù)庫操作運(yùn)行在同一個(gè)事務(wù)邊界里面?？梢韵胂?，在MSSQL Server剛進(jìn)入市場的時(shí)候，微軟推出這樣的功能，對(duì)于搶占Oracle的市場份額有多么重要。DTC和COM+當(dāng)時(shí)成為了很多大公司的標(biāo)準(zhǔn)配置，以至于后來設(shè)計(jì).NET Remoting和WCF的時(shí)候，都還是要考慮對(duì)DTC的支持。這些強(qiáng)大而且復(fù)雜的功能，讓本來就復(fù)雜的COM更加恐怖。這樣的復(fù)雜度雖然也體現(xiàn)了當(dāng)時(shí)的市場需求，但由于缺乏配套的開發(fā)工具，新的開發(fā)語言和更優(yōu)美的抽象，使得這條路最后越走越窄。
.NET Framework/CLR
在我眼中，CLR的各方面簡直是無可挑剔的。但可能正是因?yàn)镃LR太好了，讓微軟從2003年開始，對(duì)unmamanged world的投資就不大了。
為了爭取企業(yè)客戶，全力推廣CLR是最正確的做法。畢竟絕大多數(shù)的程序員，一輩子都是和數(shù)據(jù)庫，和UI代碼打交道。你總不能讓他們一輩子都用C去管理內(nèi)容，創(chuàng)建窗口句柄吧。CLR的性能也很有競爭力，與之對(duì)應(yīng)的編程語言和開發(fā)工具也非常給力，每個(gè)新版本都帶來長足進(jìn)步。但是，這些再好，也無法掩飾一個(gè)悖論: 要用C#寫出性能可以和C++一個(gè)數(shù)量級(jí)的程序，不是不可能，而是花費(fèi)的代價(jià)往往比直接用C++寫更大。這里面有很多原因，比如系統(tǒng)最底層的API還是unmanaged的，通過CLR作interop的性能損失無法忽略。比如用C#的話，程序員的控制力很弱，從工具和語言層面上很難對(duì)性能精雕細(xì)作，一不注意就box/unbox了。比如JIT編譯器為了實(shí)現(xiàn)自己的安全模型和異常處理，每次訪問成員函數(shù)的都是都要生成代碼確認(rèn)this指針是否為空。這個(gè)世界上還是有很多程序，是需要對(duì)性能做嚴(yán)格控制的。在CLR高速發(fā)展的幾年中，對(duì)應(yīng)的系統(tǒng)平臺(tái)，Win32 API, C++開發(fā)工具，只有完善性的改善，并沒有重大突破。這個(gè)問題對(duì)Windows平臺(tái)本身影響不大，但如果寄希望于在移動(dòng)設(shè)備上，大家都指著C#來開發(fā)，就有點(diǎn)天方夜譚了。這樣的失衡，使得微軟在移動(dòng)設(shè)備和消費(fèi)者產(chǎn)品這兩個(gè)嚴(yán)重需要unmanaged和系統(tǒng)投入的領(lǐng)域緩慢發(fā)展了很長時(shí)間。
WPF
在我看來，WPF是一個(gè)設(shè)計(jì)得很美的產(chǎn)品。WPF解決了傳統(tǒng)Win32 UI程序的四大局限：1) Win32的繪圖是由各自Window元素獨(dú)立控制，基于GDI的。WPF引入了rendering thread來提高性能，優(yōu)化算法，借用GPU加速。2) Win32依賴于GDI Object，在開發(fā)復(fù)雜窗口程序的時(shí)候，很容易就遭遇資源泄露和資源不足。比如早期的淘寶旺旺，開到幾十個(gè)窗口的時(shí)候，程序就會(huì)出問題。所以淘寶針對(duì)這個(gè)問題，使用了統(tǒng)一控制臺(tái)，合并多個(gè)窗口到標(biāo)簽頁的方法來解決。而WPF只有最外面的窗口使用了Win32 Window和GDI，內(nèi)部的元素都是抽象成了WPF自己的元素，不額外占用Win32 GDI資源的。3) Win32窗體程序嚴(yán)重依賴Windows Message模型。這要求程序員對(duì)系統(tǒng)知識(shí)有深入的了解。而且Win32 API并不是非常利于使用，比如要進(jìn)行UI thread和Worker thread之間的通信，往往需要和SendMessage這樣的API打交道。在WPF中，引入了Dispatcher類和BeginInvoke方法，把這些復(fù)雜問題抽象了。加上CLR提供了更方便高效的開發(fā)環(huán)境，使用WPF是很愉快的工作。4) Win32缺乏數(shù)據(jù)，設(shè)計(jì)和代碼三者之間的模式抽象。這三者在WPF中對(duì)應(yīng)了數(shù)據(jù)綁定，XAML文件，以及后臺(tái)代碼。在WPF中可以更直觀地使用各種模式比如MVC和MVVM。這些都體現(xiàn)了WPF設(shè)計(jì)上的優(yōu)美。
再優(yōu)美的東西都還是有局限性的。WPF的問題在于過多的模式和對(duì)CLR過度的依賴。了解WPF框架的人都知道，就一個(gè)簡單的dependent property, 就把設(shè)計(jì)模式這本書里面的模式用掉一大半了。分析WPF框架代碼的話，簡直就是看一本設(shè)計(jì)模式的百科全書。我曾經(jīng)統(tǒng)計(jì)過，關(guān)于mouse click這樣一個(gè)event回調(diào)，WPF里面有7種不同的實(shí)現(xiàn)方法，分別各有好處，旨在解決不同問題。在這樣高度靈活的背后，犧牲的是程序性能。無論是五花八門的模式，還是最常用的數(shù)據(jù)綁定，背后的主力都是CLR的reflection。過度依賴于reflection導(dǎo)致WPF程序規(guī)模一大，性能上就出問題。就算再怎么優(yōu)化，也總找不到原生Win32程序那般流利的感覺。使用reflection也體現(xiàn)了對(duì)CLR的依賴。所以前面CLR的局限性，也適用于WPF。
微軟產(chǎn)品的互操作性
微軟的產(chǎn)品線雖又長又多，但是各個(gè)產(chǎn)品之間一定是能夠互操作的，比如C#可以和C++互相調(diào)用。任何語言開發(fā)的程序都可以嵌入Browser Control來借用IE的功能。Office暴露了VBA接口，通過VBScript都能夠自動(dòng)化Office程序。各種管理工具無論是Explorer還是MMC，都暴露了編程接口可以讓程序員添加自己的功能。我見過客戶用ASP.NET在后臺(tái)用VBScript生成Excel表格，然后把表格嵌入在IE瀏覽器中，再使用JavaScript來幫助客戶編輯，最后提交回MSSQL數(shù)據(jù)庫做完成報(bào)銷功能的。完善的互操作性充分保護(hù)了用戶的投資，使得客戶對(duì)微軟平臺(tái)用一次就上癮，幾乎沒有不可能完成的任務(wù)。仔細(xì)分析，其實(shí)這些互操作有一個(gè)共性，都是把暴露COM接口作為內(nèi)部實(shí)現(xiàn)原理。這個(gè)做法導(dǎo)致了三個(gè)局限性，首先是牽涉到了前面提到的COM的復(fù)雜度。其次是潛在的性能損耗。最后是在具體開發(fā)的時(shí)候，都需要一些儀式性的工作來引入或者定義COM接口，使得開發(fā)過程不夠自然流暢。在CLR和COM互操作的調(diào)用棧里面，CLR的RCW, CCW, 安全處理, 列集拷貝等等，耗費(fèi)的時(shí)間帶來的性能開銷簡直是可以到了肉眼可察覺的地步(聽硬盤的聲音和看任務(wù)管理器里面CPU的波動(dòng))。
Win8
在討論完這些技術(shù)背后的故事后，再看看為啥我就對(duì)Win8愛不釋手了。
Win8引入了Windows Runtime, 簡稱WinRT. WinRT是一個(gè)操作系統(tǒng)模塊，運(yùn)行在用戶態(tài)，介于Win32的上層和應(yīng)用程序的下層，目的在于提供更高效友好的開發(fā)接口供Win8的程序員使用。WinRT在二進(jìn)制模型上基本就是照搬了經(jīng)典的COM。WinRT和CLR互不依賴，WinRT可以被CLR使用。WinRT通過C/C++實(shí)現(xiàn)，效率高是一個(gè)方面，更重要的時(shí)Win8引入了projection的概念，就是可以把WinRT的API用最直接最高效的方法，提供給上層的編程語言調(diào)用。這個(gè)語言可以是C#, C或者JavaScript。
對(duì)于第一次接觸Projection的朋友，可以把Projection認(rèn)為是一種新的Windows API模型。傳統(tǒng)的操作系統(tǒng)API，要么是暴露DLL的方法，要么是通過COM接口。無論是哪一種，在CLR中調(diào)用的時(shí)候都有不小的開銷。使用這些傳統(tǒng)API的效率，比調(diào)用一個(gè)C#自己的方法，效率差了多個(gè)數(shù)量級(jí)，根本的原因在于CLR的安全模型、內(nèi)存模型和傳統(tǒng)的unmanaged模型不兼容，所以跨越邊界的調(diào)用需要額外的代碼來處理。而Projection提供的模型，是在提供新功能的同時(shí)，還針不同編程模型和語言，提供了最利于它們調(diào)用的方法。這樣就主動(dòng)避免了不同模型之間為了互相兼容導(dǎo)致的開銷，也使得程序員寫代碼的時(shí)候非常自然流暢，調(diào)用的時(shí)候根本感覺不到和調(diào)用本地函數(shù)的區(qū)別。當(dāng)然，能夠?qū)崿F(xiàn)這一點(diǎn), 也是得益于CLR, C#語言和VS開發(fā)工具這十年的長足發(fā)展. 舉個(gè)例子, C# 5.0中引入了await關(guān)鍵字, WinRT中引入了async operation. Projection技術(shù)把C#中的await語句轉(zhuǎn)換為WinRT async operation的調(diào)用，而且這個(gè)調(diào)用直接從managed code直接跳到unmanaged code，中間沒有任何冗余，也不需要CLR Engine的介入。進(jìn)一步的信息, 可以參考Build大會(huì)關(guān)于WinRT的多個(gè)演講。后面的callstack也提供了直觀的例子.
前面提到了COM的局限性在于一個(gè)輕量的二進(jìn)制模型，被硬生生的擴(kuò)展成一個(gè)無所不能的框架。WinRT取其精華，去其糟粕，借用了COM的輕便，舍棄了復(fù)雜性，在擴(kuò)展性上依托于上層的編程語言和工具。WinRT通過projection的技術(shù)解決了傳統(tǒng)互操作性效率不高使用不方便的問題。以前的路線是希望所有的產(chǎn)品和技術(shù)最后都統(tǒng)一到CLR上來?，F(xiàn)在修正為底層模型通過WinRT和C來實(shí)現(xiàn)，然后把這一層高效的組件無縫提供給上層的開發(fā)技術(shù)比如CLR來使用。這個(gè)轉(zhuǎn)變重新重視unmanaged層面的二進(jìn)制模型。歸納為，unmanaged模型的優(yōu)勢在于執(zhí)行效率高，可以通吃所有場景，缺點(diǎn)在于開發(fā)和使用成本也高。CLR的優(yōu)勢在于開發(fā)成本低，缺點(diǎn)在于無法通吃各種需求。現(xiàn)在微軟自己用unmanaged來做WinRT，然后把WinRT提供給上層語言，這兩者就可以取長補(bǔ)短了。
有了WinRT，有了unmanaged的回歸，再加上微軟開發(fā)工具和C#語言的長足發(fā)展，前面介紹的各種技術(shù)在Win8里面就相得益彰了。Metro是如何修復(fù)WPF的缺陷就顯而易見了: Win8的metro程序繼續(xù)使用WPF中引入的rendering模型和XAML, 但是在control的基礎(chǔ)設(shè)計(jì)和實(shí)現(xiàn)上，從CLR轉(zhuǎn)移到了C，然后通過WinRT來暴露給使用者。至于使用的靈活性，比如要不要實(shí)現(xiàn)數(shù)據(jù)綁定，就看上層使用者自己的選擇了。
附錄
下面是我研究過程中看到的一些Win8的callstack. 基于這些callstack和我以往的經(jīng)驗(yàn)，才寫了上面的文章.
Stack1:
Windows_UI_Immersive!`Windows::Internal::CMessageDialog::ShowAsync'::`50'::<lambda_32D66FEFF293CE6B>::<lambda_32D66FEFF293CE6B>
Windows_UI_Immersive!Windows::Internal::CMessageDialog::ShowAsync+0x1a0
image08ee0000!DomainNeutralILStubClass.IL_STUB_CLRtoCOM()+0x8c
application1!Application1.MainPage+<button_Click>d__0.MoveNext()+0xcd
application1!Application1.MainPage.button_Click(System.Object, Windows.UI.Xaml.RoutedEventArgs)+0x80
stack2:
combase!CComActivator::DoCreateInstance+0x121
combase!CoCreateInstanceEx+0x51
combase!CoCreateInstance+0x65
Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_TryToUnregisterForIHMNotifications+0x3b
Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_HideWindow+0x31
Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::HideWindow+0x9
Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::DestroyWindow+0x24
Windows_UI_Immersive!Windows::Internal::CPopupWindow::Destroy+0x57
Windows_UI_Immersive!Windows::Internal::CClosePopupCommandHandler::Invoke+0xe 0x73
Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::_OnButtonPress+0xc0
Windows_UI_Immersive!Windows::Internal::CPopupWindowImpl::OnMessage+0x18b
DUI70!DirectUI::NativeHWNDHost::WndProc+0x73
USER32!InternalCallWinProc+0x23
USER32!UserCallWinProcCheckWow+0x100
USER32!DispatchMessageWorker+0x3d4
USER32!DispatchMessageW+0x10
Windows_UI_Immersive!SHProcessMessagesUntilEventsEx+0xe2
Windows_UI_Immersive!Windows::Internal::PopupWindowOperation::Show+0x103
Stack3:
Windows_UI_Xaml!HWWalk::RenderChildren+0x7a
Windows_UI_Xaml!HWWalk::RenderContentAndChildren+0x2d1
Windows_UI_Xaml!HWWalk::Render+0x61e
Windows_UI_Xaml!HWWalk::RenderChildren+0x7a
Windows_UI_Xaml!HWWalk::RenderRoot+0x1c4
Windows_UI_Xaml!CCoreServices::NWDrawTree+0x698
Windows_UI_Xaml!CCoreServices::NWDraw+0x1d6
Windows_UI_Xaml!CRenderTarget::Draw+0x13
Windows_UI_Xaml!CWindowRenderTarget::Draw+0x40
Windows_UI_Xaml!CXcpBrowserHost::OnTick+0x88
Windows_UI_Xaml!CXcpDispatcher::Tick+0x184
Windows_UI_Xaml!CXcpDispatcher::OnReentrancyProtectedWindowMessage+0x133
Windows_UI_Xaml!CXcpDispatcher::ProcessMessage+0xa4
Windows_UI_Xaml!CXcpDispatcher::WindowProc+0x69
USER32!InternalCallWinProc+0x23
USER32!UserCallWinProcCheckWow+0x100
USER32!DispatchMessageWorker+0x3d4
USER32!DispatchMessageW+0x10
windows_ui!Windows::UI::Core::CDispatcher::ProcessMessage+0xc7
windows_ui!Windows::UI::Core::CDispatcher::ProcessEvents+0x6c
Windows_UI_Xaml!CJupiterWindow::RunCoreWindowMessageLoop+0x3b
Windows_UI_Xaml!CJupiterControl::RunMessageLoop+0x1d
Windows_UI_Xaml!CJupiterControlLight::RunMessageLoop+0x8
Windows_UI_Xaml!DirectUI::DXamlCore::RunMessageLoop+0x15
Windows_UI_Xaml!DirectUI::ViewProvider::Run+0x11
twinapi!Windows::ApplicationModel::Core::CoreApplicationView::ViewProviderThreadProc+0x27