說起GacUI（www.gaclib.net，gac.codeplex.com），其實這個想法在我還在上大三的時候就已經有了。但是由于經驗不足，在當時并沒能夠把這個東西給做出來，直到去年（2011）的國慶節為止。想想到現在也做了快一年了，GacUI也可以用來寫一些不是特別殘暴的C++GUI程序了。前幾天有人問道，為什么在PC都快完蛋了并且大部分GUI都已經用C#來做的時候，我還要做這個東西呢？其實，這有兩個原因：第一個我喜歡折騰C++；第二個C++好像也沒什么特別好的GUI，因此也想嘗試一下，如果做成了就維護下去，做不成了好歹還可以提高自己的水平，總之是不會浪費時間的。所以我就在想，GacUI寫到現在也快一年了，并且我最近也看到cppblog上面有幾個人也想搞搞GUI，因此我想把GacUI的一些設計思想，和我得到這些思想的過程寫出來，順便也介紹一下GacUI的架構，讓一些有興趣的人（特別是裝配腦袋）也可以來折騰折騰。

GacUI的架構的最重要一點就是要跨平臺。當然這不一定意味著我將來一定會把GacUI移植到別的什么操作系統去，但至少Windows的Classic Desktop和Metro的兩套API就毫無相似之處，同時搞定他們，也算是跨平臺了。而且就算是基于同一種API，上面還有不同的渲染器的API，譬如說GDI，譬如說Direct2D，他們也是截然不同。GacUI的設計至少要可以屏蔽掉他們的區別。當然，這在技術上有一個很好的方法來保證，就是GacUIIncludes.h里面不包含Windows.h的任何內容——因此至少在頭文件里面，所有的東西都是跟Windows無關的。當然在非GUI的部分，我們還是需要Windows.h的，并且有些人喜歡對GacUI做點hack的操作，因此我還是在GacUI.h里面提供了幾個額外的依賴于Windows.h的函數來暴露一些內部細節。那這樣如何跨Classic Desktop和Metro呢？有一個簡單的方法，就是可以在編譯的時候給些宏開關，譬如說GACUI_WINDOWS_CLASSIC_DESKTOP（缺省）或者GACUI_WINDOWS_METRO之類的東西，來屏蔽掉不需要的部分。當然這部分在移植到Metro之前我不會加進去。

基于這個想法，如果大家閱讀了GacUI的代碼的話，會發現在文件\Libraries\GacUI\Source\NativeWindow\GuiNativeWindow.h里面定義了一個INativeController接口，而且目前只有Windows Classic Desktop一個實現。INativeController的內容很多，提供了跟具體的平臺有關的操作，譬如說讀寫圖片文件啦、創建消滅窗口啦、顯示器操作啦、還有各種其他的輸入輸出等等。實現一個從頭INativeController還是比較繁瑣的，因為GUI這種對操作系統重度依賴的東西，想剝離開來，就會發現他依賴了一大坨API。這也解釋了為什么INativeController的各個XXXService函數返回的對象的方法的總和有上百個。不過從Classic Desktop移植到Metro還是相對比較簡單的，因為大部分內容還是可以共享的。

其次就是渲染器了。渲染器跟平臺是交叉依賴的。譬如說OpenGL在linux上和Classic Desktop上都可以用，Direct2D在Classic Desktop上和Metro上都可以用，GDI只能在Classic Desktop上面用。因此這就是為什么我最終沒有把渲染器也寫在INativeController里面，而是把渲染器整個給屏蔽掉了，根本沒有在GacUIIncludes.h里面給出他的接口。但是考慮到GacUI是一個支持換膚的GUI庫，因此肯定需要讓皮膚來自己決定如何繪圖。后來我就想了一個辦法，把渲染器的結構整個拿掉，替換成各種各樣的圖元（IGuiGraphicsElement）。所謂的圖元就是類似于方形啊，圓形啊，填充啊，漸變啊，文字之類的東西。皮膚自己把圖元按照一定的排版關系（在下文中有描述）拼裝好，然后GacUI內部的一個小系統會利用Bridge和Abstract Factory兩個模式的結合體（參考\Libraries\GacUI\Source\GraphicsElement\GuiGraphicsElement.h）來為這些圖元分配好渲染器對象（IGuiGraphicsRenderer）。然后圖元和渲染器之間用了Listener模式在交換信息。這樣的好處是，當圖元受到改動的時候，這個圖元對象的專用渲染器對象可以選擇cache一些信息，然后在窗口渲染的時候，只需要訪問所有的渲染器對象（在排版對象GuiGraphicsComposition的組合項形成了一棵樹），讓他們渲染自己就可以了。

圖元包含了所有需要渲染的數據，但是唯獨沒有把尺寸寫進去，因為尺寸這種東西不應該讓渲染器來負責，而應該讓排版對象來負責。排版對象自己是一棵樹，然后節點根節點之間有一些關系，這樣就可以實現堆棧排版、表格排版、對齊（到某一些邊上的）排版等等具體的排版算法。一個排版對象可以放置一個圖元對象并讓這個圖元充滿他，所以顯而易見，有一些排版對象僅僅是用來計算尺寸的中間結果，上面不一定有圖元對象的。當渲染開始的時候，排版對象首先跟圖元對象獲取數據，然后遞歸計算好整棵排版樹的尺寸，最后把尺寸交給附著在上面的圖元對象的專用渲染器對象來渲染。

大家可能會想，如果渲染一次都需要調用成千上萬個虛函數的話，會不會性能低下啊？當然編譯成Release運行會發現GacUI的性能還是相當高的。原因有兩個。第一個是我對排版對象做了一些優化。舉個例子，一個對象的尺寸至少要大于所有子對象的尺寸，這個事情計算起來是相當快的，不需要做cache。但是一個表格排版里面的所有小格子會互相擠來擠去，這個東西計算起來相當復雜（復雜度大越是平方，而且系數也不笑），所以結果要做cache。但是什么時候需要重新計算呢？度量方法很簡單，就是每一個格子的最小尺寸發生了變化的時候。而且事實上大部分皮膚都是用表格來排版的，所以等于說大部分結果都有cache。所以排版部分的尺寸在每一次渲染的時候只需要做一些小計算就可以了。復雜的排版每一個排版對象相互之間都是有關系的，一個排版對象發生了變化，有可能導致另一個排版對象的尺寸需要修改，所以最簡單的方法就是，不保存尺寸，每一次都直接重新算一次就可以了。在這個基礎上，表格排版做一下cache，整個計算過程就會變得飛快。所以盡管每一次拖動窗口，或者鼠標滑過一次窗口，都要進行相當多的計算，但是因為有一個智能的cache，使得不僅運算速度變快，而且在添加新的排版對象類型的時候也根本不需要考慮自己會不會被cache的問題，開發起來也相當愉悅。

所以上面的三大模塊（操作系統API隔離、渲染器、排版對象）已經足以讓我在系統里面開一個窗口然后在上面放各種各樣的東西了，譬如說組合成一個非常接近Windows7的按鈕外觀的一個矢量圖。那控件要怎么辦呢？其實一個控件，就是通過接收用戶的輸入，對一個排版對象上承載的一大堆圖元進行更改。用戶的輸入和控件（GuiControl）本身的狀態進行互動，然后控件把狀態的變更提交給控件的皮膚（GuiControl::IStyleController），最后皮膚通過修改圖元來把狀態變更最終展現給用戶。一個典型的例子就是，在使用Windows7皮膚的時候，鼠標移動到按鈕上面去，他會觸發一個動畫慢慢變成藍色。

GacUI的大體架構就是這個樣子了。在接下來的幾篇文章里面，我會詳細介紹每一個子系統的內部結構，順帶做以下代碼導讀，大家敬請期待。