基于GTK+和X-window的GUI在嵌入式Linux中的應(yīng)用

　　整體尺寸大小

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

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

　　運(yùn)行性能

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

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

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

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

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

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

　　優(yōu)化

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

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

　　X窗口系統(tǒng)的結(jié)構(gòu)也導(dǎo)致了像素的加載變慢。GTK+客戶端需要加載，分析XPM文件，將像素值通過(guò)傳輸協(xié)議發(fā)送給server，然后server才將像素值放入framebuffer。如果客戶端直接將數(shù)據(jù)寫(xiě)到framebuffer server那將會(huì)有效很多。

　　處理的GTK+像素的辦法就是，寫(xiě)一個(gè)臨時(shí)的中間過(guò)程，取得render過(guò)的像素，使用這個(gè)原始數(shù)據(jù)來(lái)替換XPM數(shù)據(jù)，這個(gè)原始數(shù)據(jù)就可以直接強(qiáng)制寫(xiě)到X server上。從結(jié)構(gòu)上來(lái)看，這雖然不是一個(gè)很好的處理辦法，但在效率上卻要比使用XPM要快上80%。

　　總結(jié)

　　現(xiàn)在的消費(fèi)電子大多需要一個(gè)美觀，實(shí)用的圖形界面系統(tǒng)GUI。在嵌入系統(tǒng)linux下，有很多種GUI可供選擇。使用開(kāi)放代碼的GUI的優(yōu)點(diǎn)就是你可以將其裁剪得滿足你的各種各樣的特殊需求。GTK+就是一個(gè)很好的選擇，而X-window系統(tǒng)提供了一個(gè)穩(wěn)定可靠的client/server模型。當(dāng)你得到一個(gè)只有2.9M大小的定制過(guò)的GUI時(shí)，對(duì)大多數(shù)的嵌入系統(tǒng)還是很有參考價(jià)值的。

　　關(guān)于作者

　　余濤，高級(jí)軟件工程師，現(xiàn)從事 linux 嵌入式系統(tǒng)的開(kāi)發(fā)工作，主要研究方向嵌入系統(tǒng)，UPNP 多媒體播放系統(tǒng)。您可以通過(guò)電子郵件 yut616@21cn.com 和他聯(lián)系。希望能與更多的朋友交流關(guān)于 Linux 方面的知識(shí)。