在 嵌入式 Linux 下有很多圖形界面系統(tǒng) GUI，包括 Qt/Embedded，F(xiàn)LTK，Microwindows 和 GTK+ 等。作為一個(gè)開發(fā)者，到底使用什么樣的 GUI 系統(tǒng)呢？對(duì)一個(gè)系統(tǒng)，將它改造為符合你的需求，你要做多少修改呢？修改后的系統(tǒng)的尺寸一般會(huì)有多大呢？這些都是開發(fā)人員會(huì)遇到的問題。我們?cè)谶@里討論的就 是要對(duì)這些內(nèi)容做一個(gè)具體細(xì)致的分析，通過我們的討論，大家會(huì)對(duì)基于 GTK+ 和 X 的 GUI 在嵌入式Linux 下的應(yīng)用有一個(gè)確切的了解。

在嵌入式系統(tǒng)應(yīng)用日益發(fā)展的今天，越來越多的應(yīng)用都需要使用到 GUI 來進(jìn)行開發(fā)，以此來獲得更好的交互性。

嵌入式 Linux 下 GUI 的選擇，對(duì)大多數(shù)開發(fā)人員來說是一個(gè)需要權(quán)衡對(duì)比的過程。選擇 GTK+ 運(yùn)行在 X 系統(tǒng)上，然后 X 系統(tǒng)運(yùn)行在嵌入系統(tǒng)的 framebuffer 上，這會(huì)是一個(gè)很好的選擇。

GTK+ 與 X 的優(yōu)點(diǎn)

當(dāng)然，GTK+ 與 X 一般都是被大家考慮為體積較大的桌面系統(tǒng)的好搭配，但實(shí)際上對(duì)于嵌入系統(tǒng)來說，它也有著諸多的優(yōu)點(diǎn)：

1、 X-window 系統(tǒng)與 GTK+ 都非常穩(wěn)定可靠，X-window 系統(tǒng)是經(jīng)歷了長(zhǎng)期的開發(fā)及應(yīng)用實(shí)踐的，GTK+ 也是一個(gè)比較成熟的開放源代碼項(xiàng)目。

2、 X-window 系統(tǒng)是一個(gè)靈活的 client/server 的模型結(jié)構(gòu)，一個(gè)應(yīng)用客戶端的崩潰不會(huì)影響到圖形系統(tǒng)的其他部分，這是一個(gè)很重要的特性，它有利于支持第三方應(yīng)用的擴(kuò)展開發(fā)，而不影響到主體部分。

3、 GTK+有兩個(gè)重要的庫(kù)：GDK和GLIB。GDK抽象了底層的窗口管理，要移植 GTK+ 到另一個(gè)不同的窗口系統(tǒng)的話，我們只需要移植 GDK 就可以了。GLIB 是一個(gè)工具集合，它包括了數(shù)據(jù)類型，各種宏定義，類型轉(zhuǎn)化，字符串處理，任何應(yīng)用程序都可以鏈接這個(gè) GLIB 庫(kù)，使用其中的各種數(shù)據(jù)類型、方法，來避免重復(fù)代碼，或者說避免開發(fā)人員重新發(fā)明輪子，這樣有利于減少整個(gè)系統(tǒng)的尺寸。

4、 對(duì) GTK+/X 的裁剪是很容易的，它們有著很好的可配置的選項(xiàng)，有著清晰的代碼結(jié)構(gòu)，可以保證安全正確地去掉大段的不需要的代碼。

5、 GTK+ 有著大量的應(yīng)用，GTK+ 已經(jīng)被用在了很多重要的應(yīng)用系統(tǒng)中。

6、 GTK+ 的授權(quán)是 LGPL 方式的，X 是 non-copyleft free license 的，第三方開發(fā)的系統(tǒng)都能與它們進(jìn)行鏈接。

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

8、 GTK+ 使用 C 來實(shí)現(xiàn)了面向?qū)ο蟮募軜?gòu)。

其他 GUI 系統(tǒng)

其他可以選擇的圖形系統(tǒng)包括：Qt/Embedded，F(xiàn)LTK 和 Microwindows。

1、 Qt/E 是其中較高級(jí)的，它是一個(gè)完整的，基于 framebuffer 的 GUI 系統(tǒng)，由 Trolltech 公司開發(fā)。

2、 Qt/E 有著高效的圖形渲染效果，還包括 TrueType 字體系統(tǒng)，及 alpha blending 半透明處理。

3、 但 Qt/E 不是使用 LGPL 授權(quán)方式，而是使用兩種授權(quán)方式：開發(fā)使用 GPL，而商用需要授權(quán)與版稅。

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

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

6、 Qt/E 不夠穩(wěn)定，QPE demo 不錯(cuò)，但出現(xiàn)過崩潰。

7、 FLTK (the Fast Light Toolkit) 是一個(gè)小型的 GUI 圖形系統(tǒng)，它也是用 C++ 寫的，特性太少，應(yīng)用范圍較少，不夠成熟。

8、 Microwindows 和 X-Window 相比也是一個(gè)不錯(cuò)的選擇，它占用大約 100KB-600KB 大小的內(nèi)存，和文件存儲(chǔ)空間，雖然已經(jīng)有了一個(gè)其上的 GTK+ 移植，但還是不夠成熟。

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

對(duì)于X-window系統(tǒng)，廣大的網(wǎng)絡(luò)開發(fā)者已經(jīng)做了大量的工作來減小其的尺寸，最知名的有TinyX。可以通過對(duì)不需要的代碼的裁剪及去除XLIB中靜態(tài)數(shù)據(jù)來減少總體的尺寸，如：color管理系統(tǒng)，弧形，粗線條等。

在 大多數(shù)開發(fā)人員的印象里，X 系統(tǒng)很龐大，但實(shí)際上，你聽到的，是那些對(duì) X 不夠了解的人的一種誤解。在經(jīng)過裁剪后的情況下，GTK+/X 要比 GTK+/FB 與 Qt/E 還要來得有效，且 XLIB 對(duì)一般的應(yīng)用程序有著更好的支持作用，應(yīng)用程序的開發(fā)會(huì)變得更高效。

如何裁剪 GTK+

我們可以從標(biāo)準(zhǔn)的 GTK+ 發(fā)行版本來裁剪，裁剪掉其中的不需要的，修改已經(jīng)有的代碼，并加入新的特性所需要的代碼。裁剪的范圍包括小的改動(dòng)，也包括一些大的結(jié)構(gòu)性的、核心的改變。

一、 去除 Widgets 窗口

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

二、 Widgets 窗口尺寸與繪制

接 著，修改Widgets的大小與繪制方法，GTK+提供了一個(gè)主題引擎機(jī)制，來控制窗口的外觀與效果。它允許在運(yùn)行中設(shè)置字體，設(shè)置行間隔，設(shè)置繪制特 性。這樣的機(jī)制很不錯(cuò)，但不夠靈活，代碼中很多設(shè)置的地方都是使用硬編碼的方式；另外，一種主題，就是一堆額外的代碼段和參數(shù)，這樣會(huì)增加整體的尺寸。

需 要找出影響到窗口系統(tǒng)整體尺寸的內(nèi)容，再來修改它。比如，一個(gè)按鈕的大小與繪制，包括這樣的參數(shù)：邊框的寬度，x/y的位置（主題引擎需要的參數(shù)），缺省 的間隔（常量），缺省的左上角的位置（常量），獲得焦點(diǎn)。這些在嵌入系統(tǒng)中并不需要那么完整，我們可以根據(jù)實(shí)際的需求來簡(jiǎn)化代碼，來避免GTK +的復(fù)雜性。

另外，使用面向?qū)ο蟮姆椒ǎ瑏砝^承窗口Widgets的特性，作為子類也是一個(gè)有效的方法。

三、GtkWindow

GTK+ 總是假定一個(gè)窗口里面包含了另一個(gè)窗口，它們就是嵌套關(guān)系。但對(duì)于我們經(jīng)常會(huì)碰到的有軟鍵盤的應(yīng)用時(shí)，就不完全正確了。軟鍵盤雖然是屬于一個(gè)窗口的，但卻 會(huì)超出那個(gè)窗口。所以為了突破這個(gè)假定，需要對(duì)GtkWindow增加一些特性，將軟鍵盤處理成一種特殊的子窗口。

軟鍵盤所在的窗口，需要處理軟鍵盤的按鍵事件，并將按鍵轉(zhuǎn)發(fā)給軟鍵盤工具條。當(dāng)軟鍵盤按下，軟鍵盤的回調(diào)函數(shù)就被注冊(cè)到原始窗口上，這樣軟鍵盤就會(huì)響應(yīng)按鍵事件。在GtkWindow上增加接口，可以創(chuàng)建，響應(yīng)按鍵。

在小屏幕的嵌入系統(tǒng)中，可以將滾動(dòng)條做得更簡(jiǎn)化些，去掉邊框，使用單個(gè)滾動(dòng)條。這些都更適合嵌入系統(tǒng)。

字體管理系統(tǒng)

在字體管理方面，要找到一個(gè)輕型的機(jī)制來在嵌入式系統(tǒng)顯示各種字體，并不是那么簡(jiǎn)單，困難在于GTK+ 的大型的 Widget 風(fēng)格與 X 系統(tǒng)的老式的字體管理機(jī)制的結(jié)合所引起的問題。

前 面提到的，主題引擎方式的GTK+ 是用來控制窗口的樣式與外觀的。在一個(gè)窗口顯示之前，它會(huì)得到一個(gè)式樣對(duì)象，GtkStyle，它可以是一個(gè)指向父窗口的式樣對(duì)象指針，或者是一個(gè)新的類 型，這些式樣對(duì)象將被應(yīng)用到這個(gè)窗口及它的子窗口。這個(gè)式樣由缺省值、rc 文本文件、應(yīng)用來確定。

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

但 實(shí)際中會(huì)有些問題，GtkStyle是一個(gè)大的對(duì)象。如果一個(gè)屏幕上有很多種不同字體大小的多個(gè)窗口，每個(gè)都有一個(gè)唯一的GtkStyle對(duì)象，我們就會(huì) 浪費(fèi)大量的內(nèi)存。到最后，X系統(tǒng)就不能支持類似字體的各種變化了。你甚至不能使X完成讓某個(gè)字體變粗的操作，因?yàn)閄系統(tǒng)是將不同外型的字體作為不同的字體 的。X系統(tǒng)是假定你會(huì)硬編碼一個(gè)希望的字體或者分析出一個(gè)字體名，改變字體及驗(yàn)證結(jié)果都將在字體服務(wù)器上。

還可以使用一個(gè)更好的方法來完善字體管理系統(tǒng)，即包裝GtkStyle，這樣開發(fā)者就可以通過屬性來獲得一個(gè)窗口的字體，這比直接使用 X 系統(tǒng)字體的名字要更靈活。比如要顯示一個(gè)比基本字體要大一號(hào)，并且是黑體字就可以調(diào)用：

gtk_widget_set_font_bold (widget, TRUE);
gtk_widget_set_font_enlarge (widget, 1);

這是通過在 GtkWidget 結(jié)構(gòu)中加入一個(gè) GdkFont * font 來實(shí)現(xiàn)的，GtkWidget 是所有窗口類的父類。如果設(shè)置widget->font 那么就使用它，否則就使用widget->style->font。

窗口管理

在嵌入系統(tǒng)GUI中，還需要建立一個(gè)窗口管理器。我們可以選擇一個(gè)開放代碼的，輕量級(jí)的X管理器，Aewm。在嵌入系統(tǒng)中，我們會(huì)將最上層的窗口設(shè)置為獲得焦點(diǎn)，并且只有對(duì)話框能移動(dòng)，能顯示其標(biāo)題欄。

窗 口管理器是一個(gè)交互端，它可以管理內(nèi)部與外部的應(yīng)用程序的窗口。每一個(gè)應(yīng)用程序的窗口，都會(huì)建立一個(gè) socket 連接，并取一個(gè)名字。一個(gè)應(yīng)用可以把請(qǐng)求將自己放在窗口堆棧的最下面，或者將一個(gè)命名的應(yīng)用往上移。如果一個(gè)對(duì)話框要在最上層的窗口上打開，那么窗口管理 器就將告訴這個(gè)最上層的窗口它將不再獲得焦點(diǎn)，而新對(duì)話框?qū)@得焦點(diǎn)。

整體尺寸大小

經(jīng)過一系列的改進(jìn)后，我們就得到了一個(gè)穩(wěn)定的，功能和性能都能滿足嵌入系統(tǒng)要求的GUI了。在ARM系統(tǒng)下，得到的尺寸大小為：

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

運(yùn)行性能

將修改過的 GUI 運(yùn)行在一個(gè) ARM7 的系統(tǒng)上，CPU 為 100MHZ，運(yùn)行時(shí)的效果還不錯(cuò)，窗口響應(yīng)用戶操作的速度很迅速，新的畫面創(chuàng)建與顯示的速度都能接受。

但是，啟動(dòng)時(shí)的時(shí)間卻有些問題，比較慢。在這個(gè) CPU 上，應(yīng)用程序畫面加載與顯示的時(shí)間需要 2.4秒，其中 1.5 秒是花在了建立與顯示 UI 上。

在 較慢的 CPU 上，這樣的啟動(dòng)速度是 GTK+ 運(yùn)行在 X，X 再寫到 framebuffer 上導(dǎo)致的。我們需要分析具體的瓶頸在什么地方。在深入的調(diào)試中，當(dāng)使用PC機(jī)來運(yùn)行我們的應(yīng)用，而在ARM設(shè)備上顯示時(shí)，初始化和顯示的時(shí)間幾乎可以忽略 不計(jì)。同樣，將應(yīng)用運(yùn)行在ARM設(shè)備上，而在PC機(jī)上顯示時(shí)，性能也很好。所以數(shù)據(jù)包的傳輸，framebuffer上的顯示及GTK+的運(yùn)算速度都不是 問題所在。速度慢的原因可能是這幾個(gè)因素的先后順序引起的。而且內(nèi)存的占用上也存在問題。在初始階段，GTK+構(gòu)造了大量的對(duì)象，GTK+和X是使用共享 內(nèi)存來通訊的，X寫到framebuffer，framebuffer也是不變地寫到顯存上。這些都是發(fā)生在一個(gè)較窄總線上相同的內(nèi)存空間里，這個(gè)就會(huì)引 起速度慢。

現(xiàn) 在知道了X在啟動(dòng)時(shí)比較花費(fèi)時(shí)間。在客戶模式下的GTK+的應(yīng)用，需要連接到X server，通過了認(rèn)證，得到位深及其他資源。當(dāng)然，使用X系統(tǒng)的好處要遠(yuǎn)大于它的不足。X系統(tǒng)提供了一個(gè)靈活的client/server模型，這樣 更有利于應(yīng)用的靈活加入。你可以在同一時(shí)間顯示不用的應(yīng)用窗口，而像GTK+/Fb等其他的GUI方式無法做到這一點(diǎn)，當(dāng)然QPE是個(gè)例外。

2.4 秒的延時(shí)，也并不能完全否定一切。在一個(gè)700MHZ的windows系統(tǒng)的PC上，Microsoft Word, Excel and IE幾乎都需要2秒的時(shí)間來啟動(dòng)。KEdit, 一個(gè)KDE的應(yīng)用程序，在500MHZ的PIII上，加載的時(shí)間也需要1.37秒。

對(duì)于啟動(dòng)時(shí)間，需要采用其他的辦法來加以改善。一個(gè)策略就是在用戶等待的時(shí)候，顯示一些東西來表示系統(tǒng)正在工作，這樣會(huì)使用戶忽略掉啟動(dòng)時(shí)間的緩慢。另一個(gè)策略就是可以預(yù)先在背后啟動(dòng)一些通用的程序，來有效減少集中啟動(dòng)的時(shí)間。這也是通常嵌入系統(tǒng)所慣用的做法。

優(yōu)化

在ARM7的系統(tǒng)上，由于沒有浮點(diǎn)運(yùn)算FPU，所以GTK+中的浮點(diǎn)運(yùn)算部分最好是去掉，否則會(huì)大大影響性能。GTK+使用到的浮點(diǎn)變量只分布在少數(shù)的幾個(gè)窗口中，并且去掉它們會(huì)帶來3%到12%的性能提高。

高 像素的應(yīng)用會(huì)導(dǎo)致速度較慢，這大多是由于GTK+與X中對(duì)高像素的效率低下的處理有關(guān)。如涉及到的XPM，XPM （X pixmap）格式是被設(shè)計(jì)來做到較好的兼容性，而不是更加快速。X系統(tǒng)是一個(gè)像素一個(gè)像素地畫到server的pixmap的。GTK+的像素處理也很 低效，它是使用fgetc()來讀取XPM文件的，這就會(huì)帶來大量的上下文切換開銷。
?