4. 启动链路分析：进程启动流程、主线程任务队列、关键路径识别方法

启动优化做到一定程度，你会发现一个现象：拍脑袋改代码，不如先画图。我见过太多团队，上来就优化某个函数，结果启动时间没降多少，反而引入了一堆 bug。说白了，你得先搞清楚你的 App 从点击图标到首页渲染，到底走了哪些路。

这一章，我们就来聊聊怎么把这条「路」画出来，并且找到那条最长的、最拖后腿的路径。

4.1 进程启动流程：从点击图标到 main()

很多人以为 App 启动是从 application:didFinishLaunchingWithOptions: 开始的。其实不是。在那之前，系统已经干了一大堆活。

我记得有一次排查一个启动崩溃，发现是某个第三方库的 +load 方法里做了大量计算，导致 dyld 阶段直接超时被系统 kill 了。你想想看，你的代码还没跑呢，App 就已经挂了。

4.2 主线程任务队列：谁在抢占你的 RunLoop

进入 main() 之后，主线程就成了一个「任务调度器」。iOS 上是 RunLoop，Android 上是 Looper + MessageQueue。说白了，就是一个队列，谁先排上谁先执行。

但问题在于：队列里的任务不是均匀的。有些任务是你主动加的，有些是系统偷偷塞的，还有些是第三方库帮你加的。

任务来源	典型内容	是否可控
系统回调	UIApplicationDelegate 方法、View 生命周期	部分可控
开发者代码	didFinishLaunching 中的初始化、首页数据加载	完全可控
第三方 SDK	埋点初始化、推送注册、IM 连接	间接可控
系统隐式任务	Auto Layout 计算、图层渲染、首帧绘制	不可控

我在项目中遇到过最夸张的一次，是某个 SDK 在 viewDidLoad 里同步做了网络请求，直接把首帧渲染堵了 800 毫秒。嗯，这就是典型的「不知道自己占了主线程」。

4.3 关键路径识别方法：找到那条最长的链

关键路径，说白了就是「从启动开始到首页渲染完成，耗时最长的那个任务链」。你优化了非关键路径上的任务，用户感知不到任何变化。

怎么找？我一般用三步法：

1. 打点：在关键节点埋入时间戳（main()、didFinishLaunching、首帧渲染完成）。
2. 建图：把每个任务的开始、结束、依赖关系画成有向无环图（DAG）。
3. 计算：用拓扑排序找出最长路径。

举个例子，假设你有以下任务依赖：

A (main()) → B (SDK 初始化) → C (首页数据请求) → D (渲染)
A → E (UI 布局) → D
B → F (数据库打开) → D

关键路径就是 A → B → C → D，因为这条路径的总耗时最长。你优化 E 或 F，对整体启动时间影响不大。

4.4 实战：用 SVG 画出你的启动链路

光说不练假把式。下面这张图，是我在一个项目中实际用过的启动链路分析图。你可以把它当作模板，替换成你自己的模块。

这张图里，我故意把 SDK 初始化画成了红色路径。为什么？因为它在实际项目中往往是「隐形杀手」——你以为是并行的，其实它阻塞了后面的渲染。

4.5 避坑与技巧

最后，分享几个我在实战中踩过的坑：

• 不要相信「异步」：很多库号称异步初始化，实际上在内部用了 dispatch_sync 切回主线程。用 Time Profiler 抓一下就知道真相了。
• 注意 +load 和构造方法：ObjC 的 +load 方法是在 main() 之前执行的。如果你在里面做了大量工作，用户感知到的就是「点击图标后白屏了很久」。
• 关键路径不是一成不变的：每次版本迭代，依赖关系都可能变化。我建议每个大版本都重新跑一次链路分析，别偷懒。