遊戲引擎/GUI的設計與實現-常見GUI架構，gui架構

遊戲引擎/GUI的設計與實現-常見GUI架構，gui架構

以X Window為代表的客戶/伺服器架構。

X Window通常是指X伺服器及封裝了通訊協定的用戶端庫。伺服器端主要負責輸入事件的分發，視窗層次的管理，以及顯示輸出的處理，其它功能基本上都是在用戶端實現了。我們看到的各種介面元素都是在用戶端繪製的，這一部分通常稱為ToolKit，應用程式開發人員只需要關注ToolKit就行了。以前的ToolKit非常多，經過多年的進化和淘汰，常用的ToolKit主要是GTK+和QT兩個了。X Window是非常複雜和晦澀的，以前我花了不少時間去研究用於嵌入式系統的TinyX，有興趣的朋友可以看我的部落格X Window研究筆記 。

要注意的是X Window的視窗管理功能是在X伺服器裡實現的，但視窗管理器卻是一個用戶端進程。視窗管理器決定了案頭系統的整體風格，視窗管理器進程通過視窗管理協議，發送請求給X伺服器，由X伺服器執行真正的視窗管理功能。這是X Window七大設計原則中的，提供機制而不是策略的一個體現。這樣的好處在於，視窗管理器可以獨立發展：比如用於嵌入式系統的視窗管理器和傳統PC的視窗管理器之間的差別是很大的，獨立出來後就可以開發兩個不同的視窗管理器，分別用於不同的情境。

Android上的實現也是客戶/伺服器架構。但是它和X Window並不完全相同，首先應用程式與伺服器使用binder而不是socket作為IPC機制，這主要是出於效能和安全許可權控制考慮。其次是視窗管理、渲染輸出和輸入事件分發是在幾個不同的服務裡實現的。

以DirectFB為代表的Master/Slave架構。

DirectFB可以單進程運行也可以多進程運行，多進程運行需要各進程之間協作，以防止顯示錯亂。在多進程運行方式下，DirectFB使用了一個所謂的主從（Master/Slave）模式，它有一個叫Fusion的核心模組，每個DirectFB進程通過檔案介面與Fusion模組交換資料，第一個啟動的DirectFB進程稱為Master，後面的啟動的DirectFB進程稱為Slave，Master進程一般不能退出，否則Slave進程也會被迫退出。

Master進程負責讀取輸入裝置的輸入事件，然後根據情況分發到各個Slave進程。視窗等資訊放在共用記憶體中，視窗管理器通常是作為一個模組在各個進程中，後來DirectFB也支援了獨立進程的視窗管理器。

DirectFB說Master/Slave模式與C/S模式相比有更高的效能，但是我覺得真正的效能瓶頸是在介面的繪製上，處理序間通訊的開銷非常小，Master/Slave模式根本沒有什麼必要。Fusion模組好長時間都沒有穩定下來，我被它折騰了好幾年，呵呵，現在想起來還有點惱火。

以傳統嵌入式GUI為代表的單進程架構。

功能機時代的展訊和MTK的手機平台，以及現在的一些即時作業系統，整個系統都是在一個地址空間啟動並執行，所有應用程式的資料都是共用的，雖然沒有明顯的建立進程，但是可以把整個系統看作一個進程。GUI在其中一個線程裡運行，應用程式只是邏輯上的劃分，物理上都是在一個進程中運行，所以他們不需要進程間通訊機制。

在這種架構下，GUI實現相對簡單，不需要進程間通訊機制，也不需要加鎖（雖然有多個線程，但GUI的訪問是串列的），GUI運行效率很高。它的不足在於穩定性存在潛在的問題，就GUI本身來說，因為其簡單性而具有更高的穩定性，但是由於全部應用程式共用同一個記憶體位址空間，某個應用程式崩潰掉會導致整個系統崩潰。不過這不是GUI的問題，而是系統的問題。

以前我寫的嵌入式GUI FTK就是單線程的，這樣做的主要原因是：1.FTK是為嵌入式系統開發的，所以希望能相容各種即時作業系統。2.希望做得簡單些，適用於輕量級的應用，沒有必要搞的像GTK+那樣強大。3.嘗試一種新的架構，全部有介面的應用程式都在一個進程中運行，其它伺服器在後台運行，徹底分離介面與邏輯。

基於瀏覽器HTML5 Canvas的GUI。

創新高效能移動UI架構——Canvas 使用者介面架構認為Canvas UI是HTML5 APP的介面發展趨勢，我在幾年前就認為Canvas UI才是HTML5 APP的未來，所以花了大量時間去開發CanTK和AppBuilder/GameBuilder。

基於瀏覽器HTML5 Canvas的GUI的架構類似於單進程的架構，主要區別有：

• 瀏覽器已經封裝了輸入裝置，GUI不要從輸入裝置裡讀取事件，只需要註冊相應的回呼函數即可。

• 瀏覽器已經實現了主迴圈，GUI可以通過requestAnimationFrame註冊回呼函數。

• GUI無法直接喚起IME，只能通過input元素來類比，也就不需要去實現編輯器控制項。

• GUI 不需要自己實現基本的繪圖操作，Canvas已經提供了強大繪圖操作。

• 不需要太關心跨平台的東西（各個瀏覽器存在相容性的問題，還好Canvas的API差異不大）。

不同的GUI的架構適用於不同的情況，需要根據實際情況選用。對於大多數人來說，去實現一個完整的GUI的機會不多，瞭解一下就夠了。