在嵌入式Linux系統中應用的GTK+和X分析

在嵌入式 Linux 下有很多圖形界面系統 GUI，包括Qt/Embedded，FLTK，Microwindows 和 GTK+ 等。作為一個開發者，到底使用什麼樣的 GUI 系統呢?對一個系統，将它改造為符合你的需求，你要做多少修改呢?修改後的系統的尺寸一般會有多大呢?這些都是開發人員會遇到的問題。我們在這裡讨論的就是要對這些内容做一個具體細緻的分析，通過我們的讨論，大家會對基于 GTK+ 和 X 的 GUI 在嵌入式Linux 下的應用有一個确切的了解。

　　在嵌入式系統應用日益發展的今天，越來越多的應用都需要使用到 GUI 來進行開發，以此來獲得更好的互動性。

　　嵌入式 Linux 下 GUI 的選擇，對大多數開發人員來說是一個需要權衡對比的過程。選擇 GTK+ 運作在 X 系統上，然後 X 系統運作在嵌入系統的 framebuffer 上，這會是一個很好的選擇。

　　GTK+ 與 X 的優點

　　當然，GTK+ 與 X 一般都是被大家考慮為體積較大的桌面系統的好搭配，但實際上對于嵌入系統來說，它也有着諸多的優點：

　　1、 X-window 系統與 GTK+ 都非常穩定可靠，X-window 系統是經曆了長期的開發及應用實踐的，GTK+ 也是一個比較成熟的開放源代碼項目;

　　2、 X-window 系統是一個靈活的 client/server 的模型結構，一個應用用戶端的崩潰不會影響到圖形系統的其他部分，這是一個很重要的特性，它有利于支援第三方應用的擴充開發，而不影響到主體部分;

　　3、 GTK+有兩個重要的庫：GDK和GLIB。GDK抽象了底層的視窗管理，要移植 GTK+ 到另一個不同的視窗系統的話，我們隻需要移植 GDK 就可以了。GLIB 是一個工具集合，它包括了資料類型，各種宏定義，類型轉化，字元串處理，任何應用程式都可以連結這個 GLIB 庫，使用其中的各種資料類型、方法，來避免重複代碼，或者說避免開發人員重新發明輪子，這樣有利于減少整個系統的尺寸;

　　4、 對 GTK+/X 的裁剪是很容易的，它們有着很好的可配置的選項，有着清晰的代碼結構，可以保證安全正确地去掉大段的不需要的代碼;

　　5、 GTK+ 有着大量的應用，GTK+ 已經被用在了很多重要的應用系統中;

　　6、 GTK+ 的授權是 LGPL 方式的，X 是 non-copyleft free license 的，第三方開發的系統都能與它們進行連結;

　　7、 GTK+/X 二者都是基于 C 代碼的，而不是C++;

　　8、 GTK+ 使用 C 來實作了面向對象的架構;

　　其他 GUI 系統

　　其他可以選擇的圖形系統包括：Qt/Embedded，FLTK 和 Microwindows。

　　1、 Qt/E 是其中較進階的，它是一個完整的，基于 framebuffer 的 GUI 系統，由 Trolltech 公司開發;

　　2、 Qt/E 有着高效的圖形渲染效果，還包括 TrueType 字型系統，及 alpha blending 半透明處理;

　　3、 但 Qt/E 不是使用 LGPL 授權方式，而是使用兩種授權方式：開發使用 GPL，而商用需要授權與版稅;

　　4、 Qt/E 是用 C++ 編寫的;

　　5、 Qt/E 非常大，一個 iPAQ QPE 就包括了 3.3MB 的 Qt/E 庫和一個 718KB 的 QPE 庫(和 Xlib 類似的一種庫);

　　6、 Qt/E 不夠穩定，QPE demo 不錯，但出現過崩潰;

　　7、 FLTK (the Fast Light Toolkit) 是一個小型的 GUI 圖形系統，它也是用 C++ 寫的，特性太少，應用範圍較少，不夠成熟;

　　8、 Microwindows 和 X-Window 相比也是一個不錯的選擇，它占用大約 100KB-600KB 大小的記憶體，和檔案存儲空間，雖然已經有了一個其上的 GTK+ 移植，但還是不夠成熟;

　　X-window：比你想象的要小很多

　　對于X-window系統，廣大的網絡開發者已經做了大量的工作來減小其的尺寸，最知名的有TinyX。可以通過對不需要的代碼的裁剪及去除XLIB中靜态資料來減少總體的尺寸，如：color管理系統，弧形，粗線條等。

　　在大多數開發人員的印象裡，X 系統很龐大，但實際上，你聽到的，是那些對 X 不夠了解的人的一種誤解。在經過裁剪後的情況下，GTK+/X 要比 GTK+/FB 與 Qt/E 還要來得有效，且 XLIB 對一般的應用程式有着更好的支援作用，應用程式的開發會變得更高效。

　　如何裁剪 GTK+

　　我們可以從标準的 GTK+ 發行版本來裁剪，裁剪掉其中的不需要的，修改已經有的代碼，并加入新的特性所需要的代碼。裁剪的範圍包括小的改動，也包括一些大的結構性的、核心的改變。

　　1、 去除 Widgets 視窗

　　最開始，我們把不需要的 Widgets 去除掉，比如：GtkGamma、GtkHRuler、過時了的 GtkList(被 GtkCList所替代了)、和我們不需要的 GtkFrame. 邊框。

　　2、 Widgets 視窗尺寸與繪制

　　接着，修改Widgets的大小與繪制方法，GTK+提供了一個主題引擎機制，來控制視窗的外觀與效果。它允許在運作中設定字型，設定行間隔，設定繪制特性。這樣的機制很不錯，但不夠靈活，代碼中很多設定的地方都是使用寫死的方式;另外，一種主題，就是一堆額外的代碼段和參數，這樣會增加整體的尺寸。

　　需要找出影響到視窗系統整體尺寸的内容，再來修改它。比如，一個按鈕的大小與繪制，包括這樣的參數：邊框的寬度，x/y的位置(主題引擎需要的參數)，預設的間隔(常量)，預設的左上角的位置(常量)，獲得焦點。這些在嵌入系統中并不需要那麼完整，我們可以根據實際的需求來簡化代碼，來避免 GTK+的複雜性。

　　另外，使用面向對象的方法，來繼承視窗Widgets的特性，作為子類也是一個有效的方法。

　　3、GtkWindow

　　GTK+總是假定一個視窗裡面包含了另一個視窗，它們就是嵌套關系。但對于我們經常會碰到的有軟鍵盤的應用時，就不完全正确了。軟鍵盤雖然是屬于一個視窗的，但卻會超出那個視窗。是以為了突破這個假定，需要對GtkWindow增加一些特性，将軟鍵盤處理成一種特殊的子視窗。

　　軟鍵盤所在的視窗，需要處理軟鍵盤的按鍵事件，并将按鍵轉發給軟鍵盤工具條。當軟鍵盤按下，軟鍵盤的回調函數就被注冊到原始視窗上，這樣軟鍵盤就會響應按鍵事件。在GtkWindow上增加接口，可以建立，響應按鍵。

　　在小螢幕的嵌入系統中，可以将滾動條做得更簡化些，去掉邊框，使用單個滾動條。這些都更适合嵌入系統。

　　字型管理系統

　　在字型管理方面，要找到一個輕型的機制來在嵌入式系統顯示各種字型，并不是那麼簡單，困難在于GTK+ 的大型的 Widget 風格與 X 系統的老式的字型管理機制的結合所引起的問題。

　　前面提到的，主題引擎方式的GTK+ 是用來控制視窗的樣式與外觀的。在一個視窗顯示之前，它會得到一個式樣對象，GtkStyle，它可以是一個指向父視窗的式樣對象指針，或者是一個新的類型，這些式樣對象将被應用到這個視窗及它的子視窗。這個式樣由預設值、rc 文本檔案、應用來确定。

　　要改變一個視窗的字型，你必須克隆視窗的式樣，并使用X字型加載一個新的字型，類似adobe-helvetica-bold-r-normal--12-*-*-*-p-*-iso8859-1。

　　但實際中會有些問題，GtkStyle是一個大的對象。如果一個螢幕上有很多種不同字型大小的多個視窗，每個都有一個唯一的GtkStyle對象，我們就會浪費大量的記憶體。到最後，X系統就不能支援類似字型的各種變化了。你甚至不能使X完成讓某個字型變粗的操作，因為X系統是将不同外型的字型作為不同的字型的。X系統是假定你會寫死一個希望的字型或者分析出一個字型名，改變字型及驗證結果都将在字型伺服器上。

　　還可以使用一個更好的方法來完善字型管理系統，即包裝GtkStyle，這樣開發者就可以通過屬性來獲得一個視窗的字型，這比直接使用 X 系統字型的名字要更靈活。比如要顯示一個比基本字型要大一号，并且是黑體字就可以調用：

　　gtk_widget_set_font_bold (widget, TRUE);

　　gtk_widget_set_font_enlarge (widget, 1);

　　這是通過在 GtkWidget 結構中加入一個 GdkFont * font 來實作的，GtkWidget 是所有視窗類的父類。如果設定widget->font 那麼就使用它，否則就使用widget->style->font。

　　視窗管理

　　在嵌入系統GUI中，還需要建立一個視窗管理器。我們可以選擇一個開放代碼的，輕量級的X管理器，Aewm。在嵌入系統中，我們會将最上層的視窗設定為獲得焦點，并且隻有對話框能移動，能顯示其标題欄。

　　視窗管理器是一個互動端，它可以管理内部與外部的應用程式的視窗。每一個應用程式的視窗，都會建立一個 socket 連接配接，并取一個名字。一個應用可以把請求将自己放在視窗堆棧的最下面，或者将一個命名的應用往上移。如果一個對話框要在最上層的視窗上打開，那麼視窗管理器就将告訴這個最上層的視窗它将不再獲得焦點，而新對話框将獲得焦點。

　　整體尺寸大小

　　經過一系列的改進後，我們就得到了一個穩定的，功能和性能都能滿足嵌入系統要求的GUI了。在ARM系統下，得到的尺寸大小為：

　　其中 GTK+ 裡面仍然還有不需要的代碼，可以将其再去除。如果再簡化一下的話，GTK+ 可以做到850KB，總體大小可以到 2.8M。

　　運作性能

　　将修改過的 GUI 運作在一個 ARM7 的系統上，CPU 為 100MHZ，運作時的效果還不錯，視窗響應使用者操作的速度很迅速，新的畫面建立與顯示的速度都能接受。

　　但是，啟動時的時間卻有些問題，比較慢。在這個 CPU 上，應用程式畫面加載與顯示的時間需要 2.4秒，其中 1.5 秒是花在了建立與顯示 UI 上。

　　在較慢的 CPU 上，這樣的啟動速度是 GTK+ 運作在 X，X 再寫到 framebuffer 上導緻的。我們需要分析具體的瓶頸在什麼地方。在深入的調試中，當使用PC機來運作我們的應用，而在ARM裝置上顯示時，初始化和顯示的時間幾乎可以忽略不計。同樣，将應用運作在ARM裝置上，而在PC機上顯示時，性能也很好。是以資料包的傳輸，framebuffer上的顯示及GTK+的運算速度都不是問題所在。速度慢的原因可能是這幾個因素的先後順序引起的。而且記憶體的占用上也存在問題。在初始階段，GTK+構造了大量的對象，GTK+和X是使用共享記憶體來通訊的，X寫到 framebuffer，framebuffer也是不變地寫到顯存上。這些都是發生在一個較窄總線上相同的記憶體空間裡，這個就會引起速度慢。

　　現在知道了X在啟動時比較花費時間。在客戶模式下的GTK+的應用，需要連接配接到X server，通過了認證，得到位深及其他資源。當然，使用X系統的好處要遠大于它的不足。X系統提供了一個靈活的client/server模型，這樣更有利于應用的靈活加入。你可以在同一時間顯示不用的應用視窗，而像GTK+/Fb等其他的GUI方式無法做到這一點，當然QPE是個例外。

　　2.4秒的延時，也并不能完全否定一切。在一個700MHZ的windows系統的PC上，Microsoft Word, Excel and IE幾乎都需要2秒的時間來啟動。KEdit, 一個KDE的應用程式，在500MHZ的PIII上，加載的時間也需要1.37秒。

　　對于啟動時間，需要采用其他的辦法來加以改善。一個政策就是在使用者等待的時候，顯示一些東西來表示系統正在工作，這樣會使使用者忽略掉啟動時間的緩慢。另一個政策就是可以預先在背後啟動一些通用的程式，來有效減少集中啟動的時間。這也是通常嵌入系統所慣用的做法。

　　在ARM7的系統上，由于沒有浮點運算FPU，是以GTK+中的浮點運算部分最好是去掉，否則會大大影響性能。GTK+使用到的浮點變量隻分布在少數的幾個視窗中，并且去掉它們會帶來3%到12%的性能提高。

　　高像素的應用會導緻速度較慢，這大多是由于GTK+與X中對高像素的效率低下的處理有關。如涉及到的XPM，XPM (X pixmap)格式是被設計來做到較好的相容性，而不是更加快速。X系統是一個像素一個像素地畫到server的pixmap的。GTK+的像素處理也很低效，它是使用fgetc()來讀取XPM檔案的，這就會帶來大量的上下文切換開銷。

　　X視窗系統的結構也導緻了像素的加載變慢。GTK+用戶端需要加載，分析XPM檔案，将像素值通過傳輸協定發送給server，然後server才将像素值放入framebuffer。如果用戶端直接将資料寫到framebuffer server那将會有效很多。

　　處理的GTK+像素的辦法就是，寫一個臨時的中間過程，取得render過的像素，使用這個原始資料來替換XPM資料，這個原始資料就可以直接強制寫到X server上。從結構上來看，這雖然不是一個很好的處理辦法，但在效率上卻要比使用XPM要快上80%。

　　總結

　　現在的消費電子大多需要一個美觀，實用的圖形界面系統GUI。在嵌入系統linux下，有很多種GUI可供選擇。使用開放代碼的GUI的優點就是你可以将其裁剪得滿足你的各種各樣的特殊需求。GTK+就是一個很好的選擇，而X-window系統提供了一個穩定可靠的client/server模型。當你得到一個隻有2.9M大小的定制過的GUI時，對大多數的嵌入系統還是很有參考價值的。