Android Activity启动流程全解析：从startActivity到onResume的完整链路

做 Android 开发这几年，我一直觉得能把 Activity 启动过程讲清楚的人，才算真正摸到了 Framework 的门槛。面试的时候，Activity 启动流程几乎是必考题，但大多数人背了一堆时序图，真到排查问题的时候依然一头雾水。我自己也是踩了不少坑、翻了不少源码之后才慢慢建立起完整的认知，今天就把这条链路从头到尾拆开揉碎了讲一遍。

这篇文章不打算只贴一堆源码片段然后草草收场，而是会按照实际的调用顺序，把客户端发起请求、系统服务调度、回到应用进程执行生命周期这一整条路径都梳理清楚。适合正在准备进阶面试的开发者、遇到启动异常无从下手的调试人员，以及所有对系统源码有好奇心、想弄懂底层原理的人。

1. 源码解析这趟路，该怎么读才不迷路

1.1 先建立整体流程地图

很多初学者读源码最大的问题就是一头扎进某个方法里出不来。看ActivityStarter的时候觉得逻辑好多，看ActivityTaskManagerService的时候又觉得状态机复杂到爆炸，最后看了几天源码，脑子里只剩一团乱麻。

我从第一次啃这块源码到现在总结出一个经验：源码阅读必须先有地图，再谈细节。没错，你得先知道整条链路分几段，每一段的起点和终点在哪里，然后再逐个击破。Activity 启动这条链路，宏观上就是三件事：

1. 应用进程通过 Binder 调用系统服务，发起启动请求。
2. 系统服务（system_server 进程中的 ActivityTaskManagerService）完成一系列校验、状态判断和调度，决定 Activity 应该以什么方式启动，并处理好任务栈。
3. 系统服务把执行指令通过 Binder 回传给应用进程，应用进程在主线程消息循环里执行真正的生命周期回调。

这三件事分别发生在两个进程里，中间隔着两次跨进程通信。理解这一点特别重要，因为很多人把整个流程当成单进程的调用链去理解，结果怎么都对不上。实际上，startActivity这个方法的执行是异步的，调用方发出请求之后并不会阻塞等待结果，所有流程都是通过 Messenger、Binder 加消息循环这套机制联动起来的。

有了这张地图，再看源码就不会迷路。下面的每个章节都会对应地图中的一段，我们一段一段来串。

1.2 三处关键代码入口：client、system_server、client

我在给团队做技术分享的时候特别喜欢强调一个观点：Activity 启动流程不是一条直线，更准确地说是一个环。你从应用进程出发，经过系统服务，最后还会绕回应用进程。理解这个环形结构，比记住某一处代码更有价值。

第一处入口在应用进程。当我们调用startActivity(Intent)的时候，实际进入的是ContextImpl.startActivity()，它会经过Instrumentation.execStartActivity()，在这里完成对 ActivityManager 服务的 Binder 调用。这第一段代码的目标非常明确：把启动请求"打包"并通过 Binder 送出去。

第二处入口在 system_server 进程。ActivityTaskManagerService.startActivity()收到请求后，会通过ActivityStarter做一系列决策，比如 Activity 是否存在、有没有权限、要放入哪个任务栈、是否需要创建新的 task、退场动画怎么做等。这一段的逻辑是全流程中最复杂的，因为设计到窗口、任务、栈、进程多方面的调度。

第三处入口又回到了应用进程。系统服务决策完成后，需要通过IApplicationThread接口回调应用进程。老版本的 Android 会直接调用scheduleLaunchActivity()，新版本则引入了ClientTransaction事务机制，统一封装了启动 Activity 和生命周期状态的变更，由TransactionExecutor负责逐项执行。应用进程收到回调后，通过主线程 Handler 切换到 UI 线程，最终执行ActivityThread里的handleLaunchActivity()，走到Activity.onCreate()/onStart()/onResume()。

如果你能把这三次逻辑跳跃印在脑子里，剩下的所有代码细节，都可以被归类到这三个阶段里的某一处。读源码的效率会翻倍，面试被问到的时候思路也会顺畅很多。

2. 启动链路核心类拆解：从 startActivity 到 ATMS

2.1 客户端入口：ContextImpl 和 Instrumentation

平时我们调用startActivity()其实只是站在了一长串代码的最顶端。Activity和ContextWrapper里的startActivity最终都会委托给ContextImpl。为什么不是直接交给Activity自己处理？因为ContextImpl是 Context 的真正实现类，它不依赖于具体组件，任何有 Context 的地方（比如Service、Application）都可以用它来发起跳转。

我们看一下ContextImpl.startActivity()的关键路径：

@Override public void startActivity(Intent intent, Bundle options) { warnIfCallingFromSystemProcess(); ... if ((intent.getFlags() & Intent.FLAG_ACTIVITY_NEW_TASK) == 0 && options != null && ActivityOptions.fromBundle(options).getLaunchDisplayId() != INVALID_DISPLAY && mDisplay != null) { // 处理多屏相关 ... } final ActivityThread mainThread = mMainThread; ... if (mActivityTaskManager != null) { ... } final int result = ActivityTaskManager.getService().startActivity( mMainThread.getApplicationThread(), getOpPackageName(), intent, ...); ... }

注意这里的ActivityTaskManager.getService()。在现代 Android 版本里，Activity 的调度职责已经从ActivityManagerService拆分到了ActivityTaskManagerService（简称 ATMS），单看ActivityManagerService你会发现它只负责进程和内存管理了。这是一个很重要的架构演进，面试的时候能讲清楚会非常加分。

Instrumentation.execStartActivity()则在ContextImpl之前拦截了一步。Instrumentation是系统用来监控应用运行状态的工具类，测试框架、性能监控、启动耗时统计都会依赖它。它在这里做的事情是：把启动请求包装好，调用 ATMS，并在调用出错时统一抛出异常（比如常见的ActivityNotFoundException）。

有一个小细节值得注意：如果启动方向传了Bundle options，里面通常包含启动动画、窗口模式、共享元素等参数。系统会把这些参数解析成ActivityOptions对象，最终传递给ActivityStarter。后面我们讲动画设置的时候还会再提到。

2.2 跨进服务的门：ActivityTaskManager.getService()

跨进程通信是理解 Android Framework 的一大难点，但我建议从使用角度先记住结论：ActivityTaskManager.getService()返回的是一个 Binder 代理对象，通过它可以直接调用 system_server 进程里的 ATMS 方法。

代码层面，IActivityTaskManager是一个接口，它的实现类ActivityTaskManagerService运行在 system_server 进程中。调用方的getService()拿到的是一个ActivityTaskManagerProxy，这是典型的 Binder 代理模式：

public static IActivityTaskManager getService() { return IActivityTaskManagerSingleton.get(); }

IActivityTaskManagerSingleton内部通过ServiceManager.getService(Context.ACTIVITY_TASK_SERVICE)拿到底层 Binder，再通过asInterface转换成IActivityTaskManager。这个模式在 Android 里到处都是，PackageManager、WindowManager、AlarmManager全都长这样，看多了就会有一种"天下 Binder 一大抄"的感觉。

到了ActivityTaskManagerService.startActivity()，其实真正的实现也不会堆在这里。它会快速转发给ActivityStartController.obtainStarter()，用一个建造者模式构造ActivityStarter，然后执行execute()。这句代码是整条链路里第一个真正的逻辑分叉点，因为从这里开始，启动请求就进入了系统侧的任务栈调度逻辑。

2.3 服务端调度：ActivityStarter 和 ActivityStackSupervisor

ActivityStarter是整个启动流程里面代码量最大、分支最多的类之一，它的executeRequest()方法就是名副其实的"决策室"。它会做这些事情：

• 从 Intent 里解析出ActivityInfo，也就是目标 Activity 的清单信息，如果解析不到就直接抛异常兜底。
• 计算启动标志和启动模式（standard、singleTop、singleTask、singleInstance），结合 Intent flags 和 manifest 配置确定最终的启动方式。
• 与ActivityStackSupervisor协作，找到合适的任务栈（Task）。比如singleTask模式下会复用已有 task，并清空它上面的其他 Activity。
• 判断是否需要开启新进程。如果目标 Activity 所在的进程还没创建，会调用ProcessList.startProcessLocked()启动新进程。

我见过很多开发者卡在这一步理解不了，因为他们总觉得"启动一个 Activity"就是创建一个对象。实际上，创建 Activity 对象、创建进程、创建任务栈是三件独立的事。系统会先决定 Activity 该放哪，再决定进程是否需要拉起，最后才会考虑在应用进程里反射出 Activity 实例并回调生命周期。

ActivityStackSupervisor的逻辑同样值得关注。它内部管理了mRootWindowContainer、mRecentTasks、mActivityMetricsLogger等等，负责 Activity 窗口层级和返回栈的调度。启动流程走到这里时，ActivityStarter已经基本完成了任务，接下来就要把舞台交给ActivityStackSupervisor去处理"谁上前台"的问题，也就是resumeTopActivity的逻辑。

如果是第一次启动应用，这一步还会触发冷启动链路，涉及ProcessList创建进程、ActivityThread.main()入口、attach()回绑系统服务。这段内容比较多，我们留到第三节再说。

2.4 动画与 Uri 传递：ActivityOptions 与 content:// 的注意点

开发中经常会遇到Activity切换动画失效、共享元素不起作用的问题，根源多半就是对ActivityOptions不够熟悉。ActivityTaskManagerService.startActivity()的入参里，Bundle options最终会转化成ActivityOptions，里面携带了启动的动画资源 ID 或者自定义动画对象。

常见的设置动画方式：

Intent intent = new Intent(this, SecondActivity.class); Bundle options = ActivityOptions.makeCustomAnimation( this, R.anim.slide_in_right, R.anim.slide_out_left).toBundle(); startActivity(intent, options);

如果你在启动时没有传 options，系统会使用主题里定义的windowAnimationStyle。有时候换了主题但动画没生效，问题往往出在主题父类或者windowAnimationStyle被覆盖了。我在实际排查中遇到过一个情况：同一个页面，用普通方式打开有动画，用PendingIntent方式打开就没动画，因为PendingIntent的创建需要显式传入ActivityOptions，否则系统会采用默认的淡入淡出或者完全无动画模式。

另外要说一下content://这类 Uri 传递。你在Intent里携带 FileProvider 生成的 Uri 时，除了要配置grantUriPermission，还应该明确添加访问权限的 flag：

intent.setData(uri); intent.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

跨应用跳转时，如果没有这一步，目标应用读取 Uri 极有可能抛出SecurityException或者FileNotFoundException。源码层面看，系统在ActivityStarter里会检查Intent的 flags 和 grant 状态，提前校验是否有权限访问该 Uri。这也是为什么很多人用FileProvider.getUriForFile()生成了合法的 Uri，对方应用还是读不到文件的原因——你只在 manifest 里加了 provider 配置，却忘了在跳转时显式授权。

3. 回到应用进程：事务机制和生命周期回调全流程

3.1 ClientTransaction 与执行器：现代版本的事务设计

Android 10（API 29）之后，系统侧回调应用进程的机制有了很大变化。早期版本是直接调用IApplicationThread.scheduleLaunchActivity()，一个方法负责一件事。后来引入了ClientTransaction的概念，把"启动一个 Activity"和"执行一系列生命周期状态变更"统一封装成一条事务，然后由系统侧的一次 Binder 调用发送给应用进程。

这个设计的价值在于统一和可扩展。比如启动 Activity 的同时，系统可能还想让前一个 Activity 进入onPause或onStop状态，这些变化在旧版本里分散在多个回调中，时序容易出现偏差。现在它们都被打包进同一条事务里，应用进程端只需按顺序执行即可。

看关键的几个类：

• ClientTransaction：封装了事务的内容，包括一个 callback（比如LaunchActivityItem）和一系列ActivityLifecycleItem（比如PauseActivityItem、ResumeActivityItem）。
• ClientTransactionHandler：应用进程端的处理接口，ActivityThread实现了它。
• TransactionExecutor：负责真正执行事务里的所有内容，决定执行顺序并驱动事务执行。

TransactionExecutor.execute()的逻辑核心是两层循环：先执行 callback，也就是创建 Activity； 再执行 lifecycleItem，让它按顺序经历生命周期状态。

public void execute(ClientTransaction transaction) { ... executeCallbacks(transaction); executeLifecycleState(transaction); ... }

一句话总结：启动 Activity 是事务的第一步，后续的onStart、onResume是事务的后续状态更新。它们在同一趟携带过程中被送往应用进程，再由应用进程在指定线程上逐项执行。

3.2 ActivityThread 怎么处理客户端事务

应用进程的主入口是ActivityThread.main()。它内部有一个名为H的内部 Handler，负责处理来自系统服务的各种消息。H的handleMessage()方法里，有一类消息专门对应EXECUTE_TRANSACTION，也就是"执行客户端事务"。

ActivityThread实现ClientTransactionHandler接口后，在handleMessage的分支里会拿到ClientTransaction对象，并调用TransactionExecutor.execute()。于是，从 Binder 回调到主线程消息队列再到最终执行，这是一条完整的事件流。

在主线程里执行启动，保证了 UI 操作不会因为线程问题崩掉。但也正因为所有生命周期回调都发生在主线程，一个耗时操作就可能导致后续的 Activity 无法及时启动，这也是为什么会派生出一系列启动优化方案。源码里你能看到大量traceBegin/traceEnd埋点，官方工具Systrace和Perfetto能分析启动耗时的每一步，原理就是读取这些 trace 标记。

3.3 生命周期时序：onCreate → onStart → onResume 的调用真相

生命周期回调的顺序，在TransactionExecutor执行LaunchActivityItem.execute()和随后的ResumeActivityItem.execute()时就已经基本确定了。

先看LaunchActivityItem.execute()：

@Override public void execute(ClientTransactionHandler client, ActivityClientRecord r, PendingTransactionActions pendingActions) { client.handleLaunchActivity(r, pendingActions, null /* customIntent */); }

handleLaunchActivity()内部会调用performLaunchActivity()，这一步做了非常核心的事情：

1. 通过LoadedApk获取 ClassLoader，Class.forName(className)反射创建 Activity 实例。
2. 创建Application（如果还没创建），并调用application.attach(context)。
3. 调用activity.attach()，在这里完成Window、WindowManager等 UI 基础设施的绑定。
4. 回调activity.onCreate()，这会读取ActivityInfo里配置的theme，并调用setContentView。
5. 接着回调activity.onStart()。

随后TransactionExecutor继续执行ResumeActivityItem，走到handleResumeActivity()，通过performResumeActivity()回调activity.onResume()，并真正把DecorView交给WindowManager去添加渲染。这里有个值得留意的细节：屏幕上的真正显示，其实发生在onResume之后的WindowManager.addView()流程里。

所以，很多人以为onResume执行完画面就已经显示了，严格来说这个说法不够准确。onResume只是系统层面的"正确时点"，真正出帧还得看ViewRootImpl的绘制调度和硬件渲染的配合。

3.4 一个真实的启动时序对比表

为了帮助理解，我整理一个简化版的时序表，把它当成面试回答的提纲也非常好用：

这张表串起来就是一条比较完整的链路了。如果再往下追问，每一行都可以继续展开成一篇独立的源码分析，但对日常开发和面试来说，能把这张表讲透，很多问题已经可以答得很有体系了。

4. 常见异常与排查思路：从源码角度找问题

4.1 找不到 Activity 和 Uri 授权问题

先看一种很常见的崩溃：

android.content.ActivityNotFoundException: No Activity found to handle Intent

这个错误的信息虽然直白，但背后的原因可能有很多种。从源码角度看，ActivityStarter在启动时会调用ActivityInfo的解析逻辑，通过PackageManager匹配 Intent 的 action、data、category。如果匹配不到任何组件，就会直接抛异常。

排查思路一般是：先看目标 Activity 有没有在 manifest 里注册，再看 intent 的 action 是否准确，最后确认setPackage()有没有设置目标包名。跨应用跳转时，如果两个应用的签名不同，还可能需要配置android:exported="true"，这个属性在 Android 12 之后变得尤为严格，漏配就是崩溃，一点都不留情面。

还有的同学会碰到ClassNotFoundException或者 "Activity class does not exist" 这类报错。这种情况下目标 Activity 类名往往被混淆了，或者模块冲突导致类被裁掉了。排查时我会先打开 build 产物里的 mapping 文件，确认混淆后类名到底变成什么，再看 APK 里classes.dex是否真的包含这个类。

前面提到的content://Uri 授权问题，也是启动时特别容易踩的坑。最常见的报错是SecurityException，原话大概长这样： "Permission Denial: reading com.xxx.FileProvider uri from pid=..., uid=... requires the provider be exported, or grantUriPermission()"。

问题根源在于系统在跨进程传递数据时，对content://Uri 有严格授权校验。你在进程 A 通过 FileProvider 生成了一个 Uri，想让进程 B 读取，必须要在 Intent 上显式加上FLAG_GRANT_READ_URI_PERMISSION，或者通过clipData的方式一并授权。如果还是读不到，就得确认 FileProvider 的paths配置是否正确，缓存目录、外部私有目录每类路径都要对号入座。

4.2 生命周期乱序、二次回调

第二种典型问题是：明明是第一次启动 Activity，onCreate却被调用了两次，或者跳转 A 到 B 时，A 的onStop迟迟不来，导致页面一直闪烁或者出现"任务切换"的视觉效果。

从生命周期源头看，这些乱序问题大多发生在ClientTransaction执行阶段。比如键盘弹起、窗口焦点变化、配置变更都会触发额外的 activity relaunch 或者 configuration change，这些都会走一遍 display 流程，导致onDestroy和重新onCreate。如果你在onSaveInstanceState里漏了状态保存，就会看到"数据丢失"的坑。

还有一个细节问题值得留意：当 A 启动 B 后，A 的onPause会立即执行，但onStop的执行时机取决于窗口是否完全不可见。如果 B 的启动动画还没有结束，A 的窗口可能仍然可见，Finalizer 就不会触发onStop。很多开发者在这个地方容易焦虑，其实不是生命周期乱序，而是窗口层面的可见性判断逻辑没走完。

遇到这类问题，我一般会先用adb shell dumpsys activity activities查看 ActivityRecord 的状态机，确认各个 Activity 处于什么 state。再结合 Trace 文件看TransactionExecutor的执行轨迹，基本上半小时内能定位个大概。

4.3 启动慢和 ANR 的排查参考

启动慢是一个非常综合的问题，从源码角度拆解，可以分成几个阶段去测：

• Application.attach/attachBaseContext阶段：如果是冷启动，Application 对象的创建和onCreate会阻塞主线程，任何在这个阶段的耗时都会直接影响启动速度。
• Activity.onCreate/onStart：布局填充、数据初始化、第一次网络请求，这三座大山是启动耗时的主要来源。
• onResume之后的首帧渲染：ViewRootImpl初次绘制、Choreographer注册 frame callback、Measure/Layout/Draw三步曲，都会影响首帧显示。

启动如果卡到 ANR，最常见的原因就是onCreate里执行了重度同步任务，比如大的数据库查询、IO 读写、网络同步。ANR 的底层原理，其实就是在主线程消息队列里埋了一个超时消息，如果在规定时间内没被移除，系统就判定为 ANR。读源码时能看到AppNotRespondingDialog的触发链路，它在ProcessRecord的appNotResponding()里。

排查启动 ANR 我有几个稳定的小技巧：

1. 用adb shell am start -W <package>/<activity>输出启动耗时曲线，关注TotalTime和WaitTime。
2. 抓一份 ANR trace，用Android Studio的APK Analyzer或者Perfetto打开，看主线程卡在哪。
3. 如果主线程卡在Binder调用上，还要看是不是系统服务太忙，比如PackageManager的并发查询导致长时间持锁。

4.4 从源码角度看冷启动优化

最后聊点实在的冷启动优化方向。我们平时说的冷启动优化，本质上是跟源码里的这条链路抢时间，核心思路无外乎以下四个方向：

减少 Application 初始化耗时。把不必要的懒加载都挪到onCreate之后，或者拆到子线程。很多人会在 Application 里初始化一堆 SDK，实际很多 SDK 支持子线程初始化或者延迟初始化，硬塞在主线程里等于在源码的handleCreateApplication()阶段白白浪费时间。

布局优化。减少嵌套层级，用ConstraintLayout或merge标签合并布局。源码级别来说，onCreate里setContentView的耗时直接决定了performLaunchActivity的时间，所以这块优化收益来得最直观，业界现在也有不少X2C或者LayoutInflater.Factory2替换方案来缩短 inflate 时间。

异步起线程。启动阶段如果非做耗时任务不可，建议把任务交给子线程，并通过Handler回到主线程做 UI 更新。这里需要特别注意不要让 App 提前进入onResume再回来改 UI，避免造成不必要的重绘。

使用启动器框架。像常见的启动器框架（如AnchorTask、Alpha等）本质上都是对onCreate阶段的 task 进行拓扑排序，把能并行的任务并行化，把有依赖的任务按顺序执行。理解了源码里Application到Activity.onCreate的整个过程，你就知道这种框架到底优化了哪个时间段。

我自己在实际项目里做过一个对比：一个冷启动时间原本在 2.8 秒左右的应用，通过拆分 Application 初始化、游戏化首帧渲染、减少首屏布局嵌套，最终降到了 1.3 秒左右，提升还是很明显的。启动优化不是一味地堆代码，而是要知道系统在哪几个关键节点安排了什么工作，你才能见缝插针。

5. 高级技巧：从源码到实际开发的延伸

5.1 利用 ActivityLifecycleCallbacks 做全局监控

理解了生命周期回调的来源之后，你就可以用一个非常简单的工具做到全局状态监听，那就是Application.ActivityLifecycleCallbacks。

它的原理其实是ActivityThread在每次执行生命周期回调的时候，会同步通知所有注册过的 callbacks，因此我们可以在不侵入任何一个 Activity 的情况下，统一处理以下场景：

• 统计每个页面的停留时长，判断是否进入后台。
• 在onActivityCreated时记录启动耗时埋点。
• 在onActivityDestroyed时做资源释放兜底。

这个工具用起来简单，但理解原理之后再去看它的文档，你会明显感觉自己能掌控它，而不是只会调用接口。比如我后来排查过一个问题，某个 Activity 的onDestroy被调用了但isFinishing()却返回 false，最后发现是因为 Activity 被系统强行回收，而LifecycleRegistry的同步没有走到 onDestroy 的标记逻辑，这种问题不看源码根本猜不到。

5.2 Activity 动画设置的几个实战参数

前面提到ActivityOptions，这里再补充几个实战中经常配置的参数，尤其是针对需要自定义转场动画的场景：

// 1. 自定义进入/退出动画 Bundle options = ActivityOptions.makeCustomAnimation( context, R.anim.slide_in_right, R.anim.slide_out_left).toBundle(); // 2. 打开新页面时让页面以缩放形式进入 Bundle options = ActivityOptions.makeScaleUpAnimation( sourceView, startX, startY, startWidth, startHeight).toBundle(); // 3. 共享元素转场 Bundle options = ActivityOptions.makeSceneTransitionAnimation( activity, sharedView, "shared_element_name").toBundle();

共享元素动画在源码里要经过ActivityOptions解析、RemoteTransition注册、Transition协调等步骤，跨进程通信时会有额外的时间开销，所以动画有掉帧或者延迟感，不一定是你代码问题，也有可能是系统在等下一帧的 choreographer 信号。调优时留意过渡期间不要做重的onResume逻辑即可。

5.3 从启动流程看多进程架构

再来扯一下多进程开发的灵感。很多人看源码到 system_server 那一段时，都会惊叹它的架构设计：一个核心服务，一群通过 Binder 连接的应用进程。这套架构放到应用开发里其实也通用，比如音视频播放器中，我们可以把一个播放器核心放到独立进程，UI 进程和播放器进程通过AIDL通信，这样即使播放进程崩了，UI 也不会被拖垮。

Activity 启动源码背后那种"服务拆分、状态机驱动、事务化通信"的思路，完全可以借鉴到大型应用的模块解耦上。一个典型例子是把扫码、地图、推送这些模块拆成独立服务，通过统一接口和路由层调度，而不是让所有业务都挤在单进程里。理解了系统侧的ClientTransaction封装后，你在设计自己的跨进程通信协议时也会更加注重事务的一致性和顺序性。

5.4 面试答题的梳理提示

关于面试，不少同学纠结要不要把源码细节全部背下来。我的建议是：不用背，但要能把链路讲顺，并且能围绕几个关键点展开。

常见的追问有以下几种：

• Intent 里带一个自定义 Object 为什么不能直接传递？因为Binder传输的是 Parcelable，你要么序列化，要么走全局静态（不推荐）。
• Activity A 启动 B，A 和 B 的onPause/onStop/onCreate顺序是怎样的？这个要看是同一个进程还是不同进程。同一进程里通常是 A.onPause → B.onCreate → B.onStart → B.onResume → A.onStop；不同进程时，由于 binder 调度和进程启动的并行，时序可能略有偏差。
• 为什么要用TransactionExecutor而不是多个scheduleXxx？因为事务可以保证一批操作原子性和顺序性，避免生命周期乱序。
• 冷启动为什么慢？可以回答主要时间消耗在进程创建、Application 初始化、Activity 创建和首帧渲染四个环节，再逐一展开。

面试官往往看重的不只是你说出多少类名和方法名，而是你能否把"为什么要这样设计"解释清楚。有源码打底，讲出来会比背书生动得多。

6. 结尾：一点个人体会

Activity 启动源码我前前后后读过很多遍，每次读都会发现新的细节。刚开始只是想知道一个 Activity 到底是怎么创建出来的，后来慢慢在里面看到了系统对自己内部架构的反思和演进。从早期的方法直调，到现在的ClientTransaction事务机制，Android 团队的设计思路也在持续变化，这对我们写业务代码其实非常有启发。

对于想深入源码的同学，我给的建议是从一条最简单的链路开始，遇到不懂的类就查官方文档，再对照手机上的dumpsys输出一点点磨。不要追求一下子就懂所有细节，能把主链路讲清楚就是很大的进步了。等你把 Activity 启动流程吃透了，再去看Service的绑定流程、ContentProvider的初始化流程，你就会发现它们之间有不少相似的地方，整个 Android Framework 的代码就不再是一个黑盒了。希望这篇分享能帮你跨过那道坎，真正啃下这块硬骨头。