Android O Framework架构分析：以AMS视角看Activity启动过程
在Android系统中，Activity的启动是一个非常频繁发生的过程，在Framework层中，这个过程牵涉到的模块也非常多。本文将基于Android 8.0源码，以ActivityManagerService模块（以下简称AMS）的视角来分析其过程中主要发生的行为。
一. AMS中层次结构
AMS模块中涉及Activity的数据结构主要有三个：ActivityRecord，TaskRecord，ActivityStack. 其中ActivityRecord抽象地表示了每一个Activity，这个数据结构记录、管理了Activity的各种信息、属性、状态等。TaskRecord抽象地表示了任务的概念，任务是由一系列Activity以栈的形式组成的，一般情况下启动Activity都会在同一个任务中启动，添加了特殊的flag（FLAG_ACTIVITY_NEW_TASK）或者特殊的启动模式则会在新任务中启动一个Activity. 任务和进程并无限制关系，同一任务中也可存在其它进程的Activity，同一进程的Activity也可以存在与不同任务中。具象来看的话，系统中的最近任务界面显示的任务就和AMS里的TaskRecord描述的是一样的概念。ActivityStack则是用来管理TaskRecord的结构，是由一系列TaskRecord以栈的形式组成的。它是一个抽象的概念，在系统中无法具象地看到它。从6.0开始只有两个ActivityStack（桌面所在的TaskRecord在单独的ActivityStack中，其他TaskRecord在另一个），到8.0中已经有八个（为分屏，最近任务，画中画，自由模式等创建的），ActivityStack随着Android大版本升级越来越多。
二. Activity启动的主要流程
Activity启动时，客户端通过Binder向system server端进行通讯，通知AMS进行相应地处理，其时序图为（红色代表app进程，蓝色代表system server进程）：
上面的时序图其实仅仅描述了在Activity启动时，AMS端的一些通用逻辑，绝大多数的情况下，在Activity启动时首先都会经历上述的流程。在上面时序图最后，也就是第10步的调用，会根据不同的情况进入不同的分支，后面会具体分析。
客户端的Instrumentation类会通过Binder call调用到AMS端的startActivity（上图步骤4），其参数列表为：
| 参数 | 解释 |
| IApplicationThread caller |
调用者的IApplicationThread对象 |
| String callingPackage |
调用者的包名 |
| Intent intent |
客户端进程传递过来的Intent对象 |
| String resolvedType |
ContentResolver相关 |
| IBinder resultTo |
调用者的token |
| String resultWho |
调用者Activity的mEmbeddedID字段 |
| int requestCode |
客户端传过来的，为startActivityForResult使用的请求码 |
| int startFlags |
0 |
| ProfilerInfo profilerInfo |
null |
| Bundle bOptions |
客户端传过来的ActivityOptions参数 |
接下来进入到system server进程，从上图步骤4 - 10则为AMS中的行为，下面我们简单分析下在这一系列调用栈中，AMS所发生的一些主要行为：
ActivityStarter.startActivityMayWait （步骤6）：
1. 解析intent（ActivityStackSupervisor.resolveIntent，最终会通过PackageManagerService解析），获得ResolveInfo对象。
2. 通过Intent以及刚刚解析出来的ResolveInfo对象去获取ActivityInfo对象（ActivityStackSupervisor.resolveActivity）。
3. 即将启动的activity是否处于heavy-weight进程中，如果是会进行相关处理。
ActivityStarter.startActivityLocked -> startActivity （步骤7 - 8）:
1. 检查调用者进程是否为空。
2. 获取调用者（sourceRecord）的ActivityRecord对象，根据launch flags计算activity result需要发送回的ActivityRecord对象。
3. 对传递进来的参数进行检查，如果存在非法值则返回。
4. 创建待启动的ActivityRecord对象。
5. 检查这次启动是否需要加入PendingActivity的列表中，需要则加入后返回，不需要则启动之前PendingActivity列表中的所有activity
ActivityStarter.startActivity -> startActivityUnChecked （步骤9 - 10）:
1. setInitialState：为一些全局变量进行赋值，以及一些简单的初始化工作。
2. computeLaunchingTaskFlags：根据要启动的task，更新mLaunchFlags，和Activity的启动模式相关。
3. getReusableIntentActivity：获取可复用的ActivityRecord对象。如果存在可复用的ActivityRecord对象，则获取其task，并根据一些条件通知客户端进程进行一些处理（如回调onNewIntent）。接下来会为其设置对应的Stack，并将其移动至前台。即：如果启动的Activity已经存在，在此处则会进入ActivityStack.moveTaskToFrontLocked流程。
4. 如果未发现可复用的Activity时（首次启动Activity），则需要根据条件创建/复用Task和Stack。此时会通过ActivityStack.startActivityLocked做一些Stack相关的处理。
5. 无论是否找到可复用的Activity，接下来AMS都会通知客户端进程去paused前一Activity，至此通过客户端进程调用的startActivity触发的AMS行为结束。当前一Activity的进程paused结束后，会再次通知AMS，从而会触发新一轮的行为。
上面提到，在启动过程中会检查待启动的Activity是否存在可复用的Activity（通常情况下可复用指的是启动一个在后台的Activity，如回桌面时，由于桌面的Activity不会被销毁，所以每次启动时都可以找到可复用的Activity），下面分析一下这两种情况的不同的处理流程：
1. 非首次启动，调用栈：ActivityStarter.startActivityUnchecked（上面时序图步骤10） -> ActivityStarter.setTargetStackAndMoveToFrontIfNeeded -> ActivityStack.moveTaskToFrontLocked，看这个调用栈的名字可以发现，如果要启动的Activity已经存在，会把其对应的任务移动至前台。其主要行为：
(1) insertTaskAtTop：更新mTaskToReturnTo字段，调整目标TaskRecord在ActivityStack中的位置。通知WMS TaskRecord的位置变化：StackWindowController.positionChildAtTop
(2) ActivityStackSupervisor.moveFocusableActivityStackToFrontLocked：将ActivityRecord移动到顶部，将当前ActivityStack设置为mFocusedStack，即当前具有焦点的ActivityStack
(3) updateTransitLocked：通知WMS设置过渡动画类型。
(4) ActivityStackSupervisor.resumeFocusedStackTopActivityLocked
2. 首次启动，调用栈：ActivityStarter.startActivityUnchecked（上面时序图步骤10） ->ActivityStack.startActivityLocked，其主要行为：
(1) 查看首次启动的ActivityRecord是否以New Task形式启动，如果是，则通过insertTaskAtTop将TaskRecord移动至栈顶；否则，找到当前TaskRecord在全局中的位置。如果WMS端没有对应的WindowContainer，则通知其创建一个（用于和WMS通讯）。
(2) 检查是否需要创建一个新进程（ProcessRecord）。
(3) 通知WMS设置过渡动画类型。
(4) ActivityStackSupervisor.resumeFocusedStackTopActivityLocked
无论是否首次启动，最终都会进入ActivityStackSupervisor.resumeFocusedStackTopActivityLocked中，接下来会进行一些生命周期相关的处理。下面我们简单分析一下Activity的生命周期是如何调度的。
三. Activity的生命周期
当一个Activity启动时，一般情况下会涉及两个Activity生命周期的变化。根据前文所述，当startActivity被调用时，AMS最终都会触发到ActivityStackSupervisor.resumeFocusedStackTopActivityLocked方法中去，这个方法逻辑非常多，首先会检查当前是否有需要进入paused状态的Activity，如果有，则通知其对应的客户端进程进行相关处理，其时序图如下：
这里的步骤1就是上面startActivity在AMS中都会最终进入的逻辑，这里会检查是否有需要进入paused状态的Activity，如果有，则通知客户端进程，AMS端的startActivity流程结束。客户端进程由ActivityThread接收到AMS端发来的通知，进行相关处理。此时旧的Activity将进入paused状态，其onPause回调被执行（步骤12）。当客户端paused相关调度执行完后，仍然会通知AMS，AMS会进行相关处理。接下来主要分为3种情况，针对这3种情况AMS会进行不同的处理：
1. 前一个Activity进入paused状态后通知AMS，新创建的Activity启动，如果新创建的Activity已经存在对应进程，则进入onCreate -> onStart -> onResume的生命周期：
这种情况为在已存在的进程下启动一个新的Activity，比如同一个app中启动一个新的Activity，可以看到Activity中一些关于生命周期的回调被执行，其顺序也符合我们贴的那张官方提供的生命周期的图：onCreate （步骤15）-> onStart （步骤18）-> onResume （步骤23）。
2. 如果新创建的Activity还没有已经存在的进程，则AMS端的处理会有些不同：
这种情况为待启动的Activity还没有对应的进程，比如从桌面启动一个从未启动过的app，其AMS端的处理会完全不同。发起点（步骤1）还是一样，仍需要等待客户端进程通知AMS旧Activity已经进入paused状态了，不同的是AMS需要首先为其创建一个进程，如步骤8所示，这个过程比较复杂，在本文中不做分析。进程创建完后，新创建的进程会通知AMS（步骤10），接下来AMS会在一系列处理后通知该进程（步骤13），对生命周期进行处理。scheduleLaunchActivity在客户端进程所产生的行为与上面情况1一致，即新Activity都会进入onCreate -> onStart -> onResume的生命周期中。
3. 如果启动一个已存在的Activity，则会进入onRestart（如果之前是stopped状态，则执行onRestart；否则，从onStart开始执行） -> onStart -> onResume
这种情况是启动一个已存在的Activity（之前处于paused或stopped状态，取决于其可不可见），比如从app回到桌面时，桌面的Activity经历的生命周期为onRestart（若桌面之前不可见，步骤13）-> onStart（步骤16）-> onResume（步骤18）。
至此，Activity启动过程基本完成。简单梳理一下其过程，可以将其主要逻辑概括为：
1. 客户端进程调用startActivity，通过Binder调用到system server进程中AMS模块；
2. AMS模块首先进行一些处理，其中包括：检查传递的参数是否合法，根据参数创建其对应的ActivityRecord对象，为其寻找/创建对应的TaskRecord和ActivityStack，并将其移动到前台，通知WMS模块进行相关处理等等。
3. 之后会对生命周期进行管理，首先会旧Activity会进入paused状态，AMS通过Binder通知对应客户端进程。客户端paused行为处理完后会再次通知AMS，AMS会根据新启动的Activity的不同情况（是否是可复用的Activity，是否已存在进程等）进行不同的处理。最终新的Activity都将进入resumed状态。