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

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

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

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

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

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

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

GacUI的大體架構(gòu)就是這個樣子了。在接下來的幾篇文章里面，我會詳細(xì)介紹每一個子系統(tǒng)的內(nèi)部結(jié)構(gòu)，順帶做以下代碼導(dǎo)讀，大家敬請期待。