摘要：圖形用戶界面是嵌入式系統(tǒng)中重要部分，是用戶與系統(tǒng)進行交互的樞紐，如何建立一個有效的消息機制，實現(xiàn)消息從用戶到系統(tǒng)的傳遞，以及系統(tǒng)對消息的處理如何再反映到圖形用戶界面是嵌入式系統(tǒng)開發(fā)的重要環(huán)節(jié)。本文通過對 MiniGUI的消息機制的分析后，介紹一種簡單的基于嵌入式系統(tǒng)的消息機制的實現(xiàn)方法，其相對于專業(yè)的 GUI中間件中的消息機制簡單許多，但是也有著完善的結構，便于系統(tǒng)整合在一起，非常適用于一些輕量級圖形用戶界面的嵌入式應用。

1引言

嵌入式系統(tǒng)，作為計算機兩大分支之一，從不同的角度影響著人們的生活，尤其是在通訊、工控、電子等領域發(fā)揮著越來越重要的作用。嵌入式設備之所以為眾多用戶樂于接受，是因為嵌入式設備有著自然的人機交互界面，較小的尺寸、微功耗和低成本的特點。同時，這些特點也要求嵌入式產品設計者相應降低處理器的性能，限制內存容量和復用接口芯片，這就相應提高了對嵌入式軟件設計技術要求。如，選用最佳的編程模型和不斷改進算法。這也正是本文的目的，提出一個消息機制實現(xiàn)的模型，并具有良好的可擴展性和維護性。

本文對消息機制的定義為：從底層接收用戶輸入信息(如按鍵和鼠標操作等)，經后臺處理、記錄后反映到前臺顯示的一個機制。

2 對MiniGUI中的消息機制分析

MiniGUI下的通訊是一種類似于 Win32的消息機制，運行在 MiniGUI-Threads模式下時，線程間的消息傳遞模型如下圖所示，其中的 Desktop線程充當一個微服務器，所有的消息在 Event線程獲取出來以后就會投遞給 Desktop線程，然后再分發(fā)到目的應用程序主窗口上面。

MiniGUI-Threads 中每個線程創(chuàng)建的第一個主窗口，其托管窗口必須是桌面，即 HWND_DESKTOP，該線程的其他窗口，必須由屬于同一線程的已有主窗口作為托管窗口。系統(tǒng)在托管窗口為 HWND_DESKTOP時創(chuàng)建新的消息隊列，而在指定非桌面的窗口作為托管窗口時，使用該托管窗口的消息隊列，也就是說，同一線程中的所有主窗口應該使用同一個消息隊列。通過對 MiniGUI開源學習版本版本 1.6.2源代碼的分析，其消息機制模型大致如下：

a) Event線程中的 void* EventLoop (void* data)函數(shù)通過宏IAL_Waitevent等待底層事件發(fā)生，IAL_WaitEvent實際上是調用當前系統(tǒng)所指定的 IAL引擎的 wait函數(shù)，收到具體的事件觸發(fā)消息后，EventLoop再調用 ParseEvent函數(shù)來解析這個事件消息， ParseEvent解析后，再往 Desktop的消息隊列中發(fā)送相應的消息， EventLoop從 ParseEvent返回后，單次循環(huán)結束，再次回到 IAL_WaitEvent，如此反復循環(huán)。

b) Desktop線程在隊列中收到消息后，根據消息種類處理分別處理，再將消息發(fā)往當前活動窗口(活動窗口句柄__mg_active_mainwnd)的消息隊列。

c) 其它窗口線程中，一般會有如下格式的循環(huán)來處理消息

while (GetMessage (&Msg, hMainWnd)) {

TranslateMessage (&Msg);

DispatchMessage (&Msg);

} GetMessage 函數(shù)從句柄為hMainWnd的窗口的消息隊列當中獲得消息，然后調用 TranslateMessage函數(shù)將某些消息如 MSG_KEYDOWN 和 MSG_KEYUP 翻譯成字符消息 MSG_CHAR ，最后調用 DispatchMessage 函數(shù)將消息發(fā)送到指定的窗口，或者理解為 DispatchMessage調用指定窗口的窗口過程，并傳遞消息及其參數(shù)。

由此可見，MiniGUI的消息機制是相當完整的，擴展性，健壯性都很好，很適合開發(fā)復雜的桌面系統(tǒng)，但是如果在一些資源相對有限的嵌入式場合并且窗口數(shù)目不多，菜單簡單，不需要窗口重疊，窗口移動等應用情況下，沒有必要使用專業(yè) GUI中間件。在此情況下，有必要引入一個簡單的消息機制，來維護系統(tǒng)底層事情、程序后臺菜單和前臺顯示之間的關系。

3簡單消息機制的實現(xiàn)

3.1 消息機制結構

采用不同于MiniGUI的消息隊列的通信方式，因為簡單的應用的窗口數(shù)目不多，這里的

窗口數(shù)目的含義是每一個在目標機上可能出現(xiàn)的系統(tǒng)菜單逐級顯示界面。這個消息機制的系統(tǒng)結構圖，如圖1所，結合圖說明這個簡單消息機制的實現(xiàn)過程:

后續(xù)再判斷按鍵是不是但前菜單需要的按鍵，如果不是，則此函數(shù)不會調用任何處理函數(shù)，直接返回，反之，則調用相應按鍵的處理子程序。

c) 經判定后，如果要處理該按鍵，就進入了相應的過程函數(shù)，每個過程函數(shù)，都有一段 refreshRoutine,這個函數(shù)的作用就是根據具體的按鍵(按鍵可能觸發(fā)轉到新的菜單頁面)，Current_win_ID,pre_win_ID,3個要素來更新 Current_win_ID，同時把原來的 Current_win_ID保存到Pre_win_ID中，這樣新的按鍵有效后，前臺顯示和后臺菜單的位置就同步了，之后調用相應的應用程序，根據應用程序返回的參數(shù)，再決定是否刷新 screenDC,即調用 GDI進行相應區(qū)域的重繪工作。

3.2 利用2個數(shù)組來記錄所有菜單

OBJECT* WIN_OBJECT[]、MENU WIN_MENU[]這2個數(shù)組與Menu之間的關系如圖 2所示。WIN_OBJECT是一個結構體指針數(shù)組，數(shù)組的每一項，存放一個指向 OBJECT類型的結構體數(shù)組的指針(如mainMenu[3])，這個結構體數(shù)組相當于一個菜單的作用，數(shù)組的長度表示該菜單下，菜單項的個數(shù)，同時，ID標簽也指向這個菜單，如圖 2中 mainMenu_ID,WIN_OBJECT[mainMenu_ID]中就存放了一個指向mainMenu[]數(shù)組的指針。 mainMenu[]中的每一項指向一個具體的OBJECT結構體，可以抽象理解為指向一個按鈕。 WIN_MENU[]數(shù)組的作用是指示當前菜單下按鈕的個數(shù)，以及當前按鈕的索引和默認按鈕的索引，如WIN_MENU[mainMenu_ID]={3,0,0};表示mainMenu_ID菜單下，有3個按鈕，默認和當前按鈕都是button0。在OBJECT結構體中，還存放了該 OBJECT的事件處理函數(shù)指針。

可以看出，采用這種模型能把前臺顯示的菜單系統(tǒng)很直觀的表現(xiàn)出來，這樣，極大的方 便了后臺的維護，有著相對可視化的優(yōu)點，并且具有良好的移植性能，在更換平臺時，只要考慮GDI函數(shù)的重寫以及底層按鍵與結構體 EVENT_DESCRIPTOR注冊關系。適合于輕量級的嵌入式系統(tǒng)應用，不能應用于復雜的界面開發(fā)，如需要窗口重疊，剪貼等，也恰恰印證了嵌入式系統(tǒng)都有著自己特殊的應用范圍這一特殊性。

4 結 束

本文介紹的消息機制實現(xiàn)靈活，占用額外 ROM空間少，可以用于單環(huán)或多線程模式，執(zhí)行效率高，同樣也有著相對完整的結構組織。雖然不適用于大型的界面開發(fā)，但是非常適合一些簡單應用場合，在當前GUI功能越來越復雜，占用 ROM&RAM空間越來越多的情況下，這種簡單的實現(xiàn)方法為一些簡單的界面開發(fā)提供了一種消息機制，能有效的降低成本并保持較高的實時性。此方法已經在基于 UC/OSII的操作系統(tǒng)上實現(xiàn)了多媒體播放器的功能。