一、Activity启动流程（基于API30）
这里把Activity 启动流程分为三个阶段
App进程中----(通过binder)---->系统进程中----(通过Binder)----->回到App进程。
最起码要熟悉 “App进程中” 和 “回到App进程” 的部分。
下面依次进行梳理。（只保留关键部分）
1. App进程中
1.1 ContextImp startActivity()/Activity startActivity()
这里需要简单说明一下，对于开发者来说，在代码中主动启动activity 的入口有两重，一个是Activity 的startActivity()系列方法（startActivityForResult 也是可以直接调用的），一个是其他Context的startActivity()方法，其他Context的startActivity()方法最终实现在ContextImp类内。两个入口都调用到了Instrumentation 的execStartActivity()方法。
ContextImpl的startActivity 方法如下，可以看到最后会进入到了Instrumentation.execStartActivity方法中，这个和Activity startActivity()方法是一样的，后面的分析可以看到。这里还需要注意的是，调用Instrumentation.execStartActivity方法前有对Intent进行判断，从主动抛出的异常信息描述可以看出，对Intent 的 flags 是有要求的，一般我们都是给Intent 添加Intent.FLAG_ACTIVITY_NEW_TASK 。这里也是跟调用Activity 的 startActivity 不一样的地方。
public void startActivity(Intent intent, Bundle options) {
warnIfCallingFromSystemProcess();
final int targetSdkVersion = getApplicationInfo().targetSdkVersion;
if ((intent.getFlags() & Intent.FLAG_ACTIVITY_NEW_TASK) == 0
&& (targetSdkVersion < Build.VERSION_CODES.N
|| targetSdkVersion >= Build.VERSION_CODES.P)
&& (options == null
|| ActivityOptions.fromBundle(options).getLaunchTaskId() == -1)) {
throw new AndroidRuntimeException(
"Calling startActivity() from outside of an Activity "
+ " context requires the FLAG_ACTIVITY_NEW_TASK flag."
+ " Is this really what you want?");
}
mMainThread.getInstrumentation().execStartActivity(
getOuterContext(), mMainThread.getApplicationThread(), null,
(Activity) null, intent, -1, options);
}
在Activity中调用了startActivity方法后，不管调用的是哪个重载，最后都会进入到startActivityForResult(Intent, int, Bundle)中。
public void startActivityForResult(@RequiresPermission Intent intent, int requestCode,
@Nullable Bundle options) {
……
mInstrumentation.execStartActivity(
this, mMainThread.getApplicationThread(), mToken, this,
intent, requestCode, options);
……
}
然后就进入到了Instrumentation.execStartActivity方法中。
1.2 Instrumentation execStartActivity()
public ActivityResult execStartActivity(
Context who, IBinder contextThread, IBinder token, Activity target,
Intent intent, int requestCode, Bundle options) {
……
ActivityTaskManager.getService().startActivity(
whoThread, who.getBasePackageName(), intent,
intent.resolveTypeIfNeeded(who.getContentResolver()),
token, target != null ? target.mEmbeddedID : null,
requestCode, 0, null, options);
……
}
在这里，通过ActivityTaskManager.getService()获取到一个IActivityTaskManager对象。通过其获取方式：
// ActivityTaskManager类
public static IActivityTaskManager getService() {
return IActivityTaskManagerSingleton.get();
}
private static final Singleton<IActivityTaskManager> IActivityTaskManagerSingleton =
new Singleton<IActivityTaskManager>() {
@Override
protected IActivityTaskManager create() {
final IBinder b = ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE);
return IActivityTaskManager.Stub.asInterface(b);
}
};
可以看到，这是一个Binder对象，用于跨进程调用系统服务。
注意！重点！
在之前的版本中，Instrumentation都是通过Binder的方式调用AMS的方法启动Activity的；但是在api29之后，IPC的对象变成了ActivityTaskManagerService（ATMS）。
2. 系统进程中
2.1 ATMS（ActivityTaskManagerService）
ATMS运行在系统服务进程（system_server）之中。当App通过Instrumentation和ATMS跨进程通信之后，ATMS就代管了接下来的启动流程。
ATMS在进行了简单处理之后，就会交给ActivityStarter处理。
public final int startActivity(...args) {
return startActivityAsUser(...args);
}
public final int startActivityAsUser(args) {
// ...
return getActivityStartController().obtainStarter(intent, "startActivityAsUser")
.......
.execute();
}
2.2 一些重要的类
接下来的工作，就是一系列的类协同处理了。代码非常复杂，但是看个大概流程还是不难的，毕竟Android源代码近亿行，不可能全部都仔细读完。
这部分主要涉及了几个类：ActivityStarter、ActivityStackSupervisor、ActivityRecord、TaskRecord、ActivityStack。
ActivityStarter
顾名思义，ActivityStarter是用来启动Activity的，同时也在其中判断了启动模式的逻辑；
ActivityStackSupervisor
顾名思义，ActivityStackSupervisor则是ActivityStack的管理者。
ActivityRecord
而每次启动一个Activity，都有一个对应的ActivityRecord被记录下来。这个ActivityRecord是在ActivityStarter.startActivity(IApplicationThread, ...)方法中被创建的，也就是在这里，Activity的启动信息完成了从intent到ActivityRecord的蜕变。ActivityRecord包含了一个Activity的所有信息，可以看做是Activity的“身份证”。
TaskRecord
任务。一个TaskRecord就是在四种启动模式中所说的“栈”。一个TaskRecord，或者说一个Task、任务，根据官方说法，任务是用户在执行某项工作时与之互动的一系列 Activity 的集合。也就是说，一个任务是包含了若干个Activity的。对于启动模式为singleInstance的Activity来说，会单独存在于一个栈中，也就是这个任务中只有一个Activity；而其他启动模式的Activity则会在当前栈中进行。具体的参考官网定义启动模式。
ActivityStack
ActivityStack顾名思义，也就是Activity栈。通常来讲，一个系统里面有两个ActivityStack，一个是系统Launcher所在的ActivityStack，一个是用户App运行的ActivityStack。通常App所在的栈就是后者。
系统进程中的过程请看
https://blog.csdn.net/zengsidou/article/details/117177399
3.回到App进程
3.1. ApplicationThread / ActivityThread
ApplicationThread是ActivityThread的内部类，继承自IApplicationThread.Stub，是一个Binder类，用于当前应用进程和系统进程之间的跨进程通信。
而ApplicationThread的scheduleTransaction方法其实是调用了ActivityThread的同名方法。而ActivityThread自身并没有定义这个方法，而是继承自ClientTransactionHandler来的。看下这个方法：
// ClientTransactionHandler
void scheduleTransaction(ClientTransaction transaction) {
transaction.preExecute(this);
sendMessage(ActivityThread.H.EXECUTE_TRANSACTION, transaction);
}
// ActivityThread
private void sendMessage(int what, Object obj) {
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
mH.sendMessage(msg);
}
所以scheduleTransaction方法其实就是给ActivityThread内部HandlermH发送了一个值为ActivityThread.H.EXECUTE_TRANSACTION的消息，并把事务传递了过去。
而mH的处理方式就是把这个事务交给mTransactionExecutor来执行。
3.2. TransactionExecutor
public void execute(ClientTransaction transaction) {
...
executeCallbacks(transaction);
executeLifecycleState(transaction);
mPendingActions.clear();
}
public void executeCallbacks(ClientTransaction transaction) {
final List<ClientTransactionItem> callbacks = transaction.getCallbacks();
...
for (int i = 0; i < size; ++i) {
final ClientTransactionItem item = callbacks.get(i);
item.execute(mTransactionHandler, token, mPendingActions);
}
}
private void executeLifecycleState(ClientTransaction transaction) {
final ActivityLifecycleItem lifecycleItem = transaction.getLifecycleStateRequest();
...
cycleToPath(r, lifecycleItem.getTargetState(), true, transaction);
lifecycleItem.execute(mTransactionHandler, token, mPendingActions);
}
逻辑很简单，就是分别调用了这个事务Callback和LifecycleState的execute方法；另外就是调用了cycleToPath方法，这个方法用于生命周期的过渡。
这里的在Callback和LifecycleState是在之前ActivityStackSupervisor的realStartActivityLocked方法中创建的，分别对应的是LaunchActivityItem和ResumeActivityItem这两个类，即启动和恢复Activity。
这里按照顺序平铺下来为：LaunchActivityItem.execute() -> cycleToPath() -> ResumeActivityItem.execute()。
看看这两个类的execute方法和cycleToPath方法：
// LaunchActivityItem 的 execute 方法
public void execute(...args) {
client.handleLaunchActivity(...args);
}
// ResumeActivityItem 的 execute 方法
public void execute(...args) {
client.handleResumeActivity(...args);
}
// TransactionExecutor.cycleToPath
private void cycleToPath(...args) {
...
performLifecycleSequence(r, path, transaction);
}
private void performLifecycleSequence(...args) {
...
// 这里的state是ON_START
switch (state) {
...
case ON_START:
mTransactionHandler.handleStartActivity(r.token, mPendingActions);
}
}
而这里的client参数和mTransactionHandler是TransactionExecutor对象创建的时候就传入的，实际上都是是对应应用进程的ActivityThread对象。
也就是说，到头来最终还是分别调用了ActivityThread的handleLaunchActivity，handleStartActivity和handleResumeActivity方法，分别对应了Activity的onCreate、onStart、onResume回调。
3.3. ActivityThread
handleLaunchActivity的核心是调用performLaunchActivity方法。performLaunchActivity大体上依次做了这些事：
通过反射创建Activity实例，这是通过Instrumentation.newActivity方法实现的；
- 通过Activity.attach方法，实例化Window对象；
- 通过Instrumentation调用Activity的onCreate回调；
在handleStartActivity方法中：
- 主要是调用了对应Activity的performStart方法，其中调用了onStart回调；
- 通过Instrumentation调用onRestoreInstanceState回调；
与handleLaunchActivity类似的，handleResumeActivity则是调用了
performResumeActivity方法。其大体上依次做了：
- 如果需要，调用待Resume Activity的onNewIntent、onActivityResult回调；
- 调用Activity的performResume方法，其中调用了onResume回调；
四、图示
