Qualcomm平台 AEE運行機制的深入剖析

前言
  本文利圖對Qualcomm平台的AEE（Application Execute Entironment）做一個深入的研
究與分析，便於大家瞭解整個Brew平台的App 調度機制和資源管理機制，從而方便大家以
後在Brew平台上面的的應用程式開發工作。
一．  名詞解釋
a)  Brew：無線二進位運行環境
b)  Applet：AEE執行環境裡面的一個調度，或者說執行單元
c)  Task：作業系統層面的一個任務
d)  Rex：作業系統
e)  AEE：應用程式執行環境
二．  關鍵技術分析
a)  AEE在作業系統層面，沒有獨立的Task，它只不過是依附於ui_task的一個函數調
用罷了；
b)  一個Applet是否活動，不是指它是否可以佔有CPU，而是指它在AEE層面，是否
是 Active（可以擁有LCD和鍵盤）；
c)  AEE 也好，Applet 也罷，它們只不過是一套靜態代碼而已，因此，誰調用它，它
就將在誰的上下文（Task層面）運行，因此從這種角度來講，Brew 平台的Applet
沒有Active和DeActive而言，每一個Applet都可以得到執行權（只不過不一定是
在 AEE 的上下文運行）；
d)  Rex不是分時作業系統，所以，一個Task假如不主動釋放CPU的話，其它任務將
無法得到執行權；
e)  AEE 內部有一些全域群組件，這些組件可以通過 IShell 組件來隱式操作，目前最為
重要的，大家只需要知道AEE內部維護了一個訊息佇列就Ok了；
f)  訊息和回調從本質上是一回事，發送一個訊息給一個 Applet 和調用 Applet 裡的一
個回呼函數，兩者在本質上是一回事；
三．  AEE任務調度機制分析
在 ui_task的適當時候，它將調用AEE_Init()將 AEE運行環境初始化起來，到此為
UnRegistered止，整個AEE 運行環境就可以使用了，AEE的相關介面調用也就可以正常工作了。在
AEE 的所有介面裡面，有一個最為重要的函數：AEE_Dispatch（），即 AEE 的任務調
度函數。調用此函數，將引起AEE內部進行任務調度。下面是AEE任務調度的一個簡
單描述。
  每次需要進行AEE任務調度時，AEE只需要從它的訊息佇列的隊頭，取出最前面
的訊息， 根據訊息體裡面指定的訊息接收者，（ClassID）， 調用 IShell_SendEvent(pApp,w,d)
將訊息發送給相應的Applet。而IShell_SendEvent的工作機理其實很簡單，就是直接調
用相應Applet的HandleEvent()函數，從而在邏輯層面上使得一個Applet得到了“執行
權” 。但在作業系統層面，這隻不過是一個函數調用而已。
  上述的調度機制就是 AEE 的核心演算法，很簡單，卻不好理解。接下來，再講一下
IShell_PostEvent()的作用。這個函數很簡單，就是直接把訊息放到 AEE 的訊息佇列的
末尾，然後，在下一次 AEE 的調度的時候，由 AEE 取出這個訊息並調用接收 Applet
的事件處理函數。
  好了， 調度演算法算是搞明白了， 現在有一個問題？什麼時候才會觸發AEE_Dispatch()
呢？假如這個調度函數得不到執行，就談不上調度了。問題的關鍵在於ui_task()會在需
要時（由一個AEE_APP_SIG 訊號量控制）調用AEE_Dispatch，而AEE_APP_SIG 的置
位，是由底層作業系統的一個定時器定時發送的，從這種角度來看，AEE 會定時進行
上層的任務調度。
四．  執行個體分析
當前一個Applet正在前台“運行” ，即顯示權和鍵盤控制權由當前Applet獲得，現
在來了一個短訊息，那麼，WmsApp 能不能得到這個訊息，並獲得執行權？假如可以
獲得，它應該如何操作？
按上面的說法，一個Applet只不過是一堆靜態代碼而已，對於每一個Applet而言，
只要它的某一個處理函數被調用了，就相當於它“活動”了。從這種角度出發，假如
wmsApp 在啟動並執行時候先向底層服務元件註冊了一個接收短訊息的回調（回調：在
Applet實現，由底層調用），那麼，當底層服務任務（這裡是wms_task）發現有一個短
訊息來了之後，它就會調用 WmsApp 的回呼函數，這樣的話，不管 AL 層當前活動的
Applet是誰，WmsApp都可以得到執行權（只不過，它是在ws_task的上下文執行的，
而不是在AEE的上下文） ，即都可以“接收”到短訊息。
好了，第一個問題搞定了。任何Applet，不管它是否活動，都可以得到系統事件。
UnRegistered現在的關鍵是，假如它得到了系統事件並運行，那麼 Applet 該如何動作？比如上述的
wmsapp，它得到一個短訊息事件之後，是直接彈出短訊息介面呢？還是怎麼辦？
請大家記住一點：只有當前活動的Applet可以擁有螢幕和鍵盤的控制權！！那假如
真是這樣的話，Wmsapp雖然可以接收到短訊息，但由於它不是當前活動的Applet，所
以它無法控制螢幕。為了獲得LCD的控制權，它必須由“非啟用”狀態，變成“啟用”
狀態。因此，一般的非啟用 Applet 在收到系統訊息之後，假如它希望彈出一些提示界
面，則必須先將自己啟用（做法很簡單，就是直接調用 IShell_StartApplet），這樣，它
才可以操作LCD 並顯示相應的提示資訊了。
五．  AEE的鍵盤派發和LCD重新整理機制
AEE的鍵盤派發機制很簡單，每一次當AEE 需要派發鍵盤訊息（鍵盤訊息將由底
層 task 傳送給AEE，至於如何傳送的，大家暫且可以不用關心）時，AEE 的做法很簡
單，就是從它的Applet棧中取出最上層的Applet（也就是活動Applet），並將鍵盤訊息
發送給它。也就是說，AEE 將鍵盤訊息每次只發送給當前活動的 Applet，其它 Applet
無法接收到鍵盤訊息。
關於 LCD 重新整理機制同樣簡單，每次 Applet 調用 IDisplay_Update 的時候，AEE 都
會做出判斷，假如執行這個操作的 Applet 不是活動 Applet，那麼，AEE 將不會允許它
去“真正”更新LCD，從而達到了只有當前活動Applet才能操作LCD的設計目標。
  [結論]
    所有的Applet，不管活動與否，都可以收到系統訊息並處理，但只有活動Applet
可以擁有鍵盤和LCD。
六．  Applet的各種狀態剖析
在邏輯概念上，一個Applet存在如下幾種狀態：
a)  Active（Run）；
b)  Suspend：掛起狀態；
c)  Background：後台狀態；
上述的所有狀態，都只是邏輯概念上的，活動狀態與其它兩種狀態的唯一區別就在
於可以獲得鍵盤和 LCD 的控制，除此之外，只要一個Applet不是Close狀態，那麼，
他們都可以獲得各種系統訊息並得到處理權。
至於Suspend和Background的區別，其實也很簡單。處於Suspend狀態的Applet，
假如當前活動Applet關閉的話， 那麼下一個Suspend的 Applet將自動成為Active狀態。
UnRegistered即 Suspend狀態的Applet仍在AEE的自動調度範圍內。而Background的Applet，則不
會自動變成Active，除非我們人為啟用它。說白了，在 AEE 內部，這兩種類型的Applet
肯定是放在兩個不同的隊列裡面。另外，由於 Background  Applet 具有不自動啟用的
特性，所以，在很多時候，一些Service用這種狀態的Applet來實現最好不過。
Applet的各種狀態之間是如何進行狀態切換的呢？ActiveàSuspend是由AEE自動
完成的， 即每次啟動一個新的Applet， 那麼當前Applet就會變成掛起狀態並收到Suspend
訊息。一旦當前活動 Applet 退出了，那麼它的下一個 Applet 就會由 Suspend 狀態變為
Active 狀態，並收到 Resume 訊息。ActiveàBackground 的狀態切換有點特殊，要使一
個 Applet進入後台狀態， 必須調用IShell_CloseApplet去關閉Applet， 這個時候， Applet
會收到On_Stop訊息，假如它在這個訊息裡返回True，那麼，這個Applet就真正Close
了。關鍵在於對On_Stop訊息的處理，每一個希望進入Background狀態的Applet必須
在這個訊息裡面做如下處理，簡單的範例程式碼如下：
  case EVT_APP_STOP:
        {
            boolean *pb = (boolean *)dwParam;
            if(pb)
            {
                *pb = FALSE;    /* Set the app to background app */
                pMe->bSuspended = TRUE;
            }
            break;
    這樣之後，一個 Applet 就進入了後台狀態，假如它想切換回 Active 狀態，很簡單，
直接調用IShell_StarApplet就ok。 請大家注意IShell_StartApplet （）， 此代碼將視不同的Applet
發送不同的訊息。對於Background  Applet，它將發送一個On_Start的訊息給當前Applet，
對於掛起的Applet，它將發送一個Resume的訊息給當前Applet。
七．  後記
上述文檔，是對當前 AEE 運行機理的一個簡單分析，由於 AEE 的相關代碼，
Qualcomm沒有公開源碼，所以無法得到一個更為準確的分析結果。不過，大家如能將
上述的AEE 運行機理好好體會，相信對於將來開發Brew應用一定會大有協助。
最後謝謝大家耐心把本文看完，謝謝。
UnRegistered