基于MiniGUI的多進程圖形用戶界面的研究

0引言

嵌入式圖形用戶界面（Graphic User Interface）是嵌入式產品設計和開發的重點，隨著嵌入式產品的廣泛應用，所實現的功能也日益強大和復雜，因此對嵌入式產品的GUI在功能、易用性、穩定性等方面提出了更高的要求。目前的嵌入式GUI多是基于線程實現，在穩定性和功能上具有一定的局限性，所以開發多進程的GUI具有重要意義。

1多進程圖形用戶界面分析

1.1 多進程圖形用戶界面的優勢

MiniGUI是由飛漫開發的基于事件驅動的圖形用戶界面支持系統，采用微C/S機制和分層設計模型，利用Unix域套接字實現客戶應用程序和服務器程序之間的交互。早期的MiniGUI采用基于POSIX線程進行消息傳遞和窗口管理的機制，這種實現能夠提供最大程度的數據共享，實現多窗口系統，但是也造成體系結構上的脆弱，所有的窗口在一個進程或者地址空間中運行，一旦某個線程因為非法的數據訪問而導致崩潰或終止運行，整個圖形用戶界面系統都將受到影響。

在Linux系統中，任務是以進程為單位實現的。進程主要提供兩類虛擬化資源：虛擬地址空間和虛擬CPU。前者保證了進程在分配和管理內存時就像機器上只有這一個進程。類似的，虛擬CPU也使進程看上去獨占了CPU。 Linux系統為進程提供了安全的運行環境，保證每個進程的獨立性，一個進程的崩潰不會危及其他進程。因此在多進程模式下，能夠同時運行多個客戶進程，如果某個進程不正常終止，其他的進程不會受到影響，因此實現多進程GUI將極大的提高系統的穩定性。

1.2 進程間通信方式的選擇

基于多進程的GUI能夠實現多個界面窗口的并發運行，通過進程間通信（IPC）實現窗口切換。進程間通信有多種形式，如管道、信號、共享內存等。

共享內存是由內核出于在多個進程間交互信息的目的而保留的一塊內存空間，多個進程共享該內存空間，如果一個進程更新了其中的數據，其他的進程會立即看到更新，而且共享內存也是速度最快的進程間通訊機制。因此共享內存作為進程間的通信方式對于多窗口GUI系統的編程實現非常合適。

1.3 基于微C/S機制的多進程模型

對于在微C/S機制上運行的GUI系統，在運行過程中只能有一個服務器程序，其余的應用程序均為客戶程序。各客戶應用程序分別運行于各自不同的進程空間中，并且根據需要在應用程序之間通過進程間通信進行數據交換，完成窗口切換等過程。

MiniGUI為了實現客戶端和服務器端之間的通信，定義了一種簡單方便的請求/響應結構：客戶程序通過制定的結構將請求發送到服務器，服務器處理請求并應答。在圖形界面運行后，服務器程序完成Server端連接初始化（ServerStart()），建立服務器端連接套接字Socket，其文件描述符為listenfd，進入到偵聽客戶連接請求狀態，用一個Idlehandler4Server句柄等待接收客戶端的連接請求消息，在接受到來自于客戶端的連接請求消息后進行處理，將客戶應用程序加入到當前活動列表，并將客戶端套接字文件描述符clifd加入到偵聽文件集合中。客戶端程序在完成連接初始化后(cli_conn())建立客戶端套接字Socket，并發送連接請求消息給Server程序，之后采用句柄 IdelHandler4Client偵聽服務器的返回消息。此后服務器程序進入一個消息循環過程，在此循環過程中繼續準備接收已連接的客戶程序的其他消息、新的客戶程序連接請求消息以及由系統產生的鼠標、鍵盤事件消息等，并在事件消息處理完成后用函數Send2Client將需要的消息發送到相應的客戶端應用程序。此后客戶端應用程序從套接字讀取由服務器程序處理后返回的消息，并把消息寫到當前進程的桌面隊列中，交由本進程消息循環進行分發和處理。在獲得消息處理結果后用cli_quest()向服務器端發送數據請求，服務器端接收數據請求后交由handle_request按照請求功能號的不同調用不同的服務例程進行處理，完成后發送一個{HWND_INVALID,0}消息和應答數據，客戶端接收服務器應答消息，至此完成一個基本的消息循環通信過程。

基于以上的分析， MiniGUI下的基于微C/S機制的多進程GUI通信模型如圖1所示：

相比傳統的嵌入式圖形界面開發，多進程圖形用戶界面系統在編程實現上有較大的復雜性。圖形用戶界面必須實現對窗口、層、異步事件、光標或者加上觸摸屏的管理，MiniGUI本身的消息機制的管理與內核系統的其他機制之間的配合等。