一種嵌入式圖形用戶(hù)界面系統的設計與實(shí)現

當其他窗口或輸入抽象層需要操作主窗口時(shí)，就調用事件系統中的Post_Msg或Send_Msg函數向該窗口的消息隊列發(fā)送一個(gè)消息。而主窗口得知有消息輸入，就調用事件系統中的Get_Msg函數取出消息，并使用Dispatch_Msg調用自己的消息處理函數，找到相應的事件處理方法處理事務(wù)。這種消息傳遞的特點(diǎn)是消息的發(fā)送和處理分別在不同的窗口線(xiàn)程中完成，一般用于兩個(gè)主窗口之間或者輸入抽象層和主窗口之間的消息通信。

沒(méi)有消息隊列的子窗口或控件處理消息的流程如圖6所示。


圖6沒(méi)有消息隊列的窗口的消息處理流程

主窗口調用事件系統中的Post_Msg或Send_Msg函數向子窗口或控件發(fā)送消息，由于該窗口沒(méi)有自己的消息隊列，事件系統不會(huì )將該消息保存，而是直接調用該窗口的消息處理函數找到具體的事件處理方式完成這次窗口操作。這種消息傳遞方式中，發(fā)送消息和處理消息都在主窗口的線(xiàn)程中完成，向一個(gè)窗口發(fā)送消息相當于要求該窗口立刻對事件進(jìn)行處理。

SKY-GUI只設置了一個(gè)主窗口，即桌面。其他所有的窗口或對話(huà)框都作為桌面的子窗口而存在。

這樣系統中只有一個(gè)窗口線(xiàn)程和一個(gè)消息隊列，第一種消息處理方式只存在于輸入抽象層和桌面之間，而窗口之間的消息處理都采用第二種方式，這樣系統的線(xiàn)程開(kāi)銷(xiāo)和消息循環(huán)開(kāi)銷(xiāo)會(huì )大大減少，從而提高其運行效率。

2. 4. 3窗口之間的消息傳遞

窗口之間的消息傳遞根據消息類(lèi)型的不同有兩種不同方式。

主窗口從消息隊列中取得的消息在SKY-GUI中稱(chēng)為底層消息。這類(lèi)消息是由主窗口處理，還是交給子窗口或是控件處理，是根據窗口定義中的pFocus變量而定的。當一個(gè)窗口的pFocus不為空時(shí)，表示該窗口上方有子窗口被用戶(hù)使用，消息應該交給它指向的子窗口處理，而這個(gè)子窗口也檢查自己的pFocus變量，依此類(lèi)推；只有當一個(gè)窗口的pFocus為空，表示該窗口位于屏幕的最上方，得到的底層消息由窗口自身處理（如圖7左邊流程）。

而當控件的狀態(tài)變化產(chǎn)生控件消息時(shí)，其消息處理的過(guò)程正好跟上面的流程相反?？丶a(chǎn)生的消息首先由自己處理，有必要時(shí)再送給pParent指針指向的父窗口處理，而后還有必要的話(huà)再送給父窗口的父窗口處理，最后也可以由主窗口送入消息隊列（如圖7右邊流程）。


圖7從消息隊列讀出的消息處理流程（左）和控件產(chǎn)生的消息處理流程（右）。

pFocus變量和pParent變量加上這樣樹(shù)形的窗口系統實(shí)質(zhì)上是實(shí)現了很多GUI系統中的窗口的Z序[6]（窗口的上下順序）功能。該功能是建立在子窗口顯示在其父窗口之上，且控件顯示在其所屬窗口之上的思想上的。由于底層消息一般代表用戶(hù)對輸入設備的操作，所以應該送給位于屏幕最上方的用戶(hù)正在使用的窗口處理，而控件消息一般代表著(zhù)GUI界面自上而下的圖形和數據變化過(guò)程，所以應該從上到下逐層處理。

3實(shí)驗和測試

SKY-GUI現已嵌入已有的視頻監控系統項目中予以使用，它有下拉菜單、輸入框、密碼框、按鈕、軟鍵盤(pán)等十幾種控件，提供視頻監控的操控界面和配置界面。其中的一個(gè)典型的界面如圖8所示。


圖8 SKY-GUI在視頻監控系統中的典型界面。

為了測試其的性能，本文利用SKY-GUI和開(kāi)源的Qt界面庫分別為視頻監控系統制作了一套用戶(hù)界面，其參數對比如表1所示。

表1 SKY-GUI與Qt在視頻監控系統中的性能比較。


很顯然，Qt在嵌入式監控系統中占用資源過(guò)多，導致其運行速度緩慢并影響到系統的正常編解碼。

而SKY-GUI加上其所需的開(kāi)源圖片和字體庫大小也不超過(guò)1 M，運行時(shí)只占用4 M左右的內存，這在典型的嵌入式Linux系統中完全可以接受，也不會(huì )影響到監控系統本身的性能?？梢钥闯?，Qt要運用在該監控系統中還需進(jìn)行更深層次的剪裁和性能優(yōu)化，而SKY-GUI則可滿(mǎn)足其對界面的功能和性能需求。

4總結

本文描述了一種嵌入式Linux平臺下GUI的設計方案。實(shí)驗證明此設計方案可行，可以滿(mǎn)足一般嵌入式平臺上的圖形界面要求。