最近大家都对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 状态。
