最近大家都对AP兴趣很大,也不知CP大家玩转了木有,反正咱也不知道咱也不敢问,这次楼主就扯下AP中的状态管理SM和执行管理EM部分。
言归正传:AP的应用,在通过工具配置后,会生成可供APP开发使用的代码和JSON的Manifest配置信息文件,经编译后APP会生成可执行文件BIN。
EM作为执行管理,其会负责读取APP的Manifest文件,获取APP的配置信息,不同的 APP在 Manifest 文件中被关联到不同的系统状态 (Machine State) 中,SM是状态管理,通过改变进程所属的功能组状态可对进程进行启动和停止,两者之间的关系如下:
首先,SM和EM其实从本质上看都属于AP的一个进程,在AP中每个进程的生命周期如下:
EM是AP第一个启动的进程,EM启动就绪后,EM将把MachineState的状态由OFF切换到Startup状态。
EM启动起来后会将SM的进程启动起来,SM可通过ExecutionClient::ReportExecutionState向EM报告此时自己进程的状态(每个进程都可通过该API向EM报告状态)。
SM正常启动运行起来后,就可通过StateClient::SetState函数对某个功能簇的工作状态进行控制,从而对隶属于相应功能簇的进程进行统一管理。
这里要介绍下功能簇的概念,功能簇可以理解为进程的集合,每个功能簇有自己的状态和过程,成为功能组Function Group States,功能组的最小单位就是一个进程,一个功能组可以配置一组进程,当SM请求相应功能组进入到对应状态时,配置在该状态下的进程都会被启动,下面就是个小示例:
其中,Machine State、Function Group1 和 Function Group2 为不同的功能组,A～F 代表不同的进程,为了简化,每个进程只有Idle、Running、Terminated三个进程状态。
进程 A 依赖于 Machinestate功能组的的 Startup 状态, EM 在启动后会Machine state 设置为 Startup状态,因此,EM 启动后将直接启动进程 A;而进程 A 为自终止进程,将在运行一次后自动终止。
进程 B 依赖于 Machinestate功能组的 Startup 和 Running 状态,同时依赖于进程 A 的终止状态,因此,进程 B 将在进程 A 终止后启动,而在 machine state 离开 Running 时终止。
进程 C 仅依赖于 Machinestate 的Running 状态,在 Machine state 进入 Runing 时启动,在离开Running 时终止。
进程 D 仅依赖于 FunctionGroup1 的 FG1:Running 状态。
进程 E 依赖于FG1:Running 和 FG2:Running 状态。
进程 F 依赖于FG2:Running 和 FG2:Fallback 状态