Ability的生命周期和JS中的回调函数

本文作者：江苏润和软件股份有限公司 郎建中

一、总体介绍
在分布式调度里面，我们介绍了一个例子：从分布式调度拉起远程FA的过程。在这个介绍中，我们最后讲到远端（轻量设备侧）软总线收到消息后，dmslite（分布式调度）通过AMS（Ability Manager Service）的方法StartAbility来启动本地的一个应用。整个系统的架构图如下：

AMS通过AppSpawn服务拉起了AbilityMain进程，AbilityMain进程就是App应用的native实现，其中包含了Ability生命周期实现、JS应用框架（Jerry）的初始化、App中的JS代码的执行、UI控件的绘制等工作。
AMS拉起FA的参考时序图如下：

上面的流程大体上分以下几个过程：
1、从dmslite收到软总线消息后，通过samgr调用ams的StartAbility（步骤1~3）。
2、AMS内部启动了一个StartAbilityTask任务去调用AppSpawn（步骤4~15）。
3、AppSpawn孵化出AbilityMain进程（步骤16~17）。
4、AbilityMain进程从main函数开始执行，在主线程函数ThreadMain中，发消息ATTACH_BUNDLE给AMS。
5、AMS执行attach bundle的过程，一直到调用PageAbilityRecord::ActiveAbilty()函数开始Ability的生命周期过程。
从PageAbilityRecord::ActiveAbility()之后的流程将开启Ability的生命周期，下面主要介绍这个过程中生命周期中Ability状态的变化以及在这个过程中如何回调到App的JS代码中Ability的回调函数。
约束：本文涉及的场景都是在鸿蒙轻量设备侧。
二、代码目录
本文涉及的代码：
foundation/appexecfwk：ams服务和AbilityMain主程序。
foundation/ace：JS应用开发框架。
三、代码分析
3.1 Ability启动时的生命周期和JS中的回调函数

我们从运行在foundation进程中的AMS的PageAbilityRecord::ActiveAbility()函数开始：

大家注意上面代码中参数state是 STATE_ACTIVE。
–> AppRecord::AbilityTransaction()

–> AbilityThreadClient::AbilityTransaction()

上面代码中，state被压入Ipc的参数中，最后调用Transact()发送IPC消息到AbilityMain进程，消息为SCHEDULER_ABILITY_LIFECYCLE。这个消息将在AbilityMain进程中的AbilityScheduler::AmsCallback()被处理，代码如下：

–> AbilityScheduler::AmsCallback()

–> AbilityScheduler::PerformTransactAbilityState()

上面代码中的scheduler_就是AbilityThread实例。
–> AbilityThread::PerformTransactAbilityState()

AbilityThread::PerformTransactAbilityState()函数控制Ability的状态变化的主入口。接收从AMS发过来的消息做状态变化，消息中目标的状态是STATE_ACTIVE，这个函数大致分3个步骤完成。
①AbilityThread::PerformTransactAbilityState()步骤一：初始化AceAbility
函数在第一次被调用时，因为abilities_中没有任何东西，因此find函数肯定找不到对应token的ability，因此代码会走进红框中。然后判断当前的ability是JS App对应的还是由一个Native的Ability生成的，这里因为我们是FA，因此是JS