最近大家都對AP興趣很大,也不知CP大家玩轉(zhuǎn)了木有,反正咱也不知道咱也不敢問,這次樓主就扯下AP中的狀態(tài)管理SM和執(zhí)行管理EM部分。

言歸正傳:AP的應(yīng)用,在通過工具配置后,會生成可供APP開發(fā)使用的代碼和JSON的Manifest配置信息文件,經(jīng)編譯后APP會生成可執(zhí)行文件BIN。

EM作為執(zhí)行管理,其會負責讀取APP的Manifest文件,獲取APP的配置信息,不同的 APP在 Manifest 文件中被關(guān)聯(lián)到不同的系統(tǒng)狀態(tài)  (Machine State)  中,SM是狀態(tài)管理,通過改變進程所屬的功能組狀態(tài)可對進程進行啟動和停止,兩者之間的關(guān)系如下:

首先,SM和EM其實從本質(zhì)上看都屬于AP的一個進程,在AP中每個進程的生命周期如下:

EM是AP第一個啟動的進程,EM啟動就緒后,EM將把MachineState的狀態(tài)由OFF切換到Startup狀態(tài)。

EM啟動起來后會將SM的進程啟動起來,SM可通過ExecutionClient::ReportExecutionState向EM報告此時自己進程的狀態(tài)(每個進程都可通過該API向EM報告狀態(tài))。

SM正常啟動運行起來后,就可通過StateClient::SetState函數(shù)對某個功能簇的工作狀態(tài)進行控制,從而對隸屬于相應(yīng)功能簇的進程進行統(tǒng)一管理。

這里要介紹下功能簇的概念,功能簇可以理解為進程的集合,每個功能簇有自己的狀態(tài)和過程,成為功能組Function Group States,功能組的最小單位就是一個進程,一個功能組可以配置一組進程,當SM請求相應(yīng)功能組進入到對應(yīng)狀態(tài)時,配置在該狀態(tài)下的進程都會被啟動,下面就是個小示例:

其中,Machine State、Function  Group1 和 Function Group2 為不同的功能組,A～F 代表不同的進程,為了簡化,每個進程只有Idle、Running、Terminated三個進程狀態(tài)。

進程 A 依賴于 Machinestate功能組的的 Startup 狀態(tài), EM 在啟動后會Machine state 設(shè)置為 Startup狀態(tài),因此,EM 啟動后將直接啟動進程 A;而進程 A 為自終止進程,將在運行一次后自動終止。

進程 B 依賴于 Machinestate功能組的 Startup 和 Running 狀態(tài),同時依賴于進程 A 的終止狀態(tài),因此,進程 B 將在進程 A 終止后啟動,而在 machine state 離開 Running 時終止。

進程 C 僅依賴于 Machinestate 的Running 狀態(tài),在 Machine state 進入 Runing 時啟動,在離開Running 時終止。

進程 D 僅依賴于 FunctionGroup1 的 FG1:Running 狀態(tài)。

進程 E 依賴于FG1:Running 和 FG2:Running 狀態(tài)。

進程 F 依賴于FG2:Running 和 FG2:Fallback 狀態(tài)