Metro C++ 初體驗 第二周

閑話少說，書歸正傳：

1 Metro C++程式的進入點：

    C++開發的Metro程式有兩種架構：Windows RT和Direct程式，這兩種程式可以完美的進行互動，用一個不恰當的例子形容他們之間的關係應該就是 MFC和Win32 API程式之間的關係。Windows RT是將Windows API封裝在了一組類庫中，從使用者角度來說它處於更高層次，當然受到的局限性也更大，它的進入點被封裝在IDE(vs2011)自動產生的app類中，該類被manifest指定為進入點。而Direct程式更像是用Win32 API開發的視窗程序，它的進入點是我們熟悉的main()。我們首先要實現兩個類分別繼承於IFramworkView和IFramwordViewSource，然後在main函數中建立IFrameworkViewSource介面執行個體,用該執行個體作為參數調用靜態方法CoreApplication::Run(),並在IFrameworkViewSource介面的CreateView方法中建立IframeworkView執行個體，並調用IFrameworkView介面執行個體相關的方法（由自己實現）啟動程式。

2 Metro UI:

   緊接上文，使用 Windows RT開發的應用程式其實就是.Net程式的變種，通過 XAML定義Ui布局，使用豐富的控制項可以進行比較簡便快捷的開發出絢麗奪目的軟體。但是它同樣具備一些缺點：對效率的要求比較低，不夠靈活只能使用控制項提供的功能，無法訪問一些底層的API，對於有特定需求的開發人員（系統級軟體）無法訪問底層的API。另外，對於習慣了直接使用Win32開發視窗程序的程式員來說不容易適應。相反，Direct程式就是對Win32視窗程序的一種延伸，你可以自由建立或者獲得CoreWindow這種對象（類似於視窗控制代碼），並在CoreWindow上直接使用Direct函數繪製（取代Gdi和GDI+）。同時你還可以使用dispatcher/event傳遞訊息(取代message機制）。使用WRT直接使用Com組建，以及一些列Windows為Metro保留或者重新開發的Win32 API。然而，Direct程式開發複雜，難度大，繁瑣的API調用必定會延長開發週期，因此究竟如何選擇還需要根據實際情況而定。

對於我來說，我選擇兩者混用，在互動方面微軟做的還是非常好的，基本是無縫對接。

3 進程與UI(題外話)：

    Windows程式通常分為兩部分：進程和UI。當然，這麼說非常不準確，事實上我想表達的意思其實是進程未必一定是要有UI的，即便沒有UI程式依然也可以執行。因此，如果我們想真正弄懂Metro的機制，必須區分開進程與UI。特別值得一提的是，我們必須清楚地知道永遠是進程駕馭UI，而非UI左右進程。這句話的意思並非是在UI中不能建立進程，而是說我們必須把進程作為程式的核心，我們需要UI的時候就去 建立，當UI不存在的時候，不意味進程就結束了，依然可以做我們想做的事，在需要的時候還可以再建立UI。當然，如果你只想開發一個WinRT程式，也未必要理解這些，就好像很多未曾深入研究的MFC程式員，它們覺得視窗就是和程式共存的（同生同滅），這個不難理解，因為視窗不是自己建立(微軟幫你做了大部分工作)的，你要做的就是在UI中添代碼，或許對你來有一種錯覺就是現有UI後有進程。。。有了上面的一些不成熟的見解，我要引出的是幾個類CoreApplication,CoreApplicationView,CoreWindow。這幾個類表示的是什嗎？其實CoreApplication表示的就是進程，CoreWindow表示的是UI（類似於視窗控制代碼)，CoreApplicaitonView就是將CoreWindow和CoreApplication聯絡起來的對象。對應到Windows視窗程序，CoreApplication就是表示執行main函數的一個進程，CoreWindow就是在這個進程中建立的一個視窗。由於Metro程式本質上就是一個擁有一個主視窗的全屏程式，因此需要使用CoreApplicationView將這個進程和一個主視窗綁定。通過CoreApplication::GetCurrentView獲得當前進程的綁定關係CoreApplicationView，再通過CoreApplicationView::CoreWindow屬性就可以找到綁定到當前進程的主視窗對象CoreWindow。

4 WinRT UI 結構：

    承接上文，Metro程式的Ui其實都是基於一個全屏主視窗建立的。WinRT和MFC，WPF或者C#一樣強化了UI而淡化了非UI部分，使得寫程式看似就是一個在UI架構中填代碼的操作，其實這麼看也無可厚非，還能簡化程式開發的難度。我們就看一看，到底使用 XAML建立的Ui是一個什麼結構？這裡首先要提到一個類Windows::UI::Xaml::Window。這個東西究竟是什嗎？從MSDN上看"A Window object is just surfacing information from CoreWindow, which in turn is referencing the window created by the system."這個我研究了很久，一直沒明白，有幾點是我感覺到值得特別注意的：

1 ）這個類有擷取CoreWindow的方法，但是卻找不到任何從CoreWindow擷取Window的方法。

2 ）它屬於Xaml空間

3 ）它與UIElement有關係，我們之前說了MetroUI都是基於一個CoreWindow上的，但是從CoreWIndow我並沒有找到與UI有什麼關係。

通過以上幾點我可以大膽推測：Window就是主視窗的CoreWindow的一個XAML表現形式，它將作為所有UIElment的父視窗。這樣一來，CoreWindow就和UIElement掛鈎了。之所以說它只表示主視窗的CoreWindow，是因為我們無法從任意的CoreWindow獲得Window，而只能從一個Window類的靜態屬性Current得到唯一的Window對象，這隻可能是主視窗的Window。

通過不斷地實驗，我大致可以得出Metro的Ui結構，一個CoreApplication綁定一個CoreWindow，這個CoreWIndow作為所有UIElement的父控制項的表現形式就是Window。Window的Content屬性是Frame,一個Window對應n個Frame也就是軟體可以有很多情境，每個frame綁定n個page,這個page也就是你當前頁面下所有控制項的父節點。你可以在一個情境中自由切換頁面，也可以在Window下自由切換情境，這對遊戲開發人員有著非凡的意義。對於一般非遊戲開發人員，可能一個frame多個page的情況比較常見。

5 page切換：

使用frame的Navigate()函數或者GoBack(),GoForward()。後兩個函數沒什麼可說的，像瀏覽器一樣，可以根據你的切換曆史，跳轉到指定頁面。值得一題的是Navigate函數，很奇怪，它的參數並不是指定頁面對象的名字，反而是指定頁面的類型名。我大膽推測一下吧，在Metro程式中我們沒有顯式的建立過頁面，而系統自動建立了我們自訂的頁面，和可能是我們每一個自訂的頁面類型只會被建立唯一一個執行個體，而且我們並不是使用ref new來建立，而是通過navigate函數建立這唯一的執行個體，因此我們只要指定頁面的類型就可以跳轉到唯一的頁面。不過這隻是我的推測。

原文地址