iOS 性能优化 系列 05｜启动优化怎么做才有收益

启动优化是很容易被做成“零碎技巧收集”的一个主题。

大家通常会记住很多经验：

• 少做初始化
• 延迟加载
• 首屏简单点
• 不要启动时打太多请求

这些建议当然都对，但如果没有抓住核心判断，最后常常会变成“我们好像改了很多地方，但启动为什么还是不明显变快”。

启动优化真正的关键不是技巧数量，而是一个非常朴素的问题：

哪些工作真的属于用户看到首屏之前必须完成的关键路径，哪些工作只是因为方便而被顺手塞进启动阶段了？

一、启动慢的根源，通常不是某一个点特别离谱，而是关键路径越来越胖

很多项目最初启动都不慢。
真正变慢通常是因为随着功能增加，越来越多逻辑被默认塞进“App 一启动就做”：

• 配置初始化
• 埋点初始化
• 网络环境准备
• 用户状态恢复
• 首页请求
• 本地缓存读取
• 各种 SDK 注册

单看每件事都好像合理，问题在于它们一起叠到启动阶段后，关键路径会越来越重。

所以启动优化最常见的真实问题，不是“某一个函数特别差”，而是：
本来不该都挤在这一刻做的工作，被长期堆在了这一刻。

二、先分清冷启动、热启动和用户真正感知到的“可用时刻”

如果这一层没分清，后面的优化很容易偏。

因为用户口中的“启动慢”，可能指的是不同东西：

• 点击图标后很久没画面
• 首页出来了，但还不能操作
• 首页框架先出来，内容很久才补齐

这些其实对应的是不同阶段的慢。

从工程上看，你至少应该分清：

• 冷启动：进程从无到有
• 热启动：进程已在内存中恢复
• 用户真正可用时刻：用户能看到并开始交互的时间点

启动优化不是单纯追一个数字，而是要知道你现在到底在哪一段丢了时间。

三、最值得做的第一步，不是“砍功能”，而是给启动阶段的工作分层

我通常会先把启动阶段的工作分成三类：

1. 首屏前必须完成的

例如：

• 最基本的界面骨架
• 核心依赖初始化
• 启动后马上必须知道的用户关键状态

2. 首屏出现后尽快完成的

例如：

• 次要数据预取
• 某些配置刷新
• 非关键 UI 补充内容

3. 完全可以延后或后台化的

例如：

• 某些埋点准备
• 不影响当前页面的缓存清理
• 次级页面资源预热

这一步比任何单点技巧都更有价值，因为它会直接让你看到：
原来很多慢不是“做不到更快”，而是“本来就不该现在做”。

四、很多启动优化之所以没收益，是因为它只是把局部代码写快了，但没有改变关键路径

这是很高频的误区。

例如你把某段初始化从 40ms 优化到 10ms，听起来不错。
但如果这段初始化本来就不该出现在关键路径上，那最有效的优化可能不是“写得更快”，而是“根本先别在这里做”。

所以判断一项启动优化值不值得做，我最常看的不是“它本身能省多少”，而是：

• 它是不是关键路径上的工作
• 它能不能被移出关键路径
• 它是不是用户当前就必须依赖

这比单纯盯函数耗时更重要。

五、首页内容加载为什么经常拖慢启动体验

很多 App 启动看起来慢，不一定是进程真正起来得慢，而是首屏可用内容出现得太晚。

比如：

• 首页骨架已经渲染了
• 但必须等多个请求回来才像“真正可用”
• 某些模块互相等待
• 本地缓存没有先顶上

这时用户感受到的慢，其实更接近“首屏内容策略问题”，而不只是启动技术问题。

所以启动优化经常和首屏策略绑定在一起：

• 哪些模块必须同步出现
• 哪些模块可以骨架屏兜底
• 哪些内容可以先展示缓存结果

很多所谓启动慢，最后其实是首屏内容组织不合理。

六、一个更接近实战的判断：当前慢的是“初始化”还是“首屏装配”

这两个经常会混在一起。

初始化慢

问题更偏：

• SDK
• 全局服务
• 配置读取
• 依赖注入

首屏装配慢

问题更偏：

• 首页模块太重
• 页面一出现就做太多工作
• 首屏数据依赖链过长

这两个方向的优化完全不同。
前者要拆初始化和延后执行，后者更像要重看页面结构和内容策略。

七、结论：启动优化真正有收益的前提，是先把关键路径画出来

如果只用一句话总结，我会说：

启动优化真正有收益，不是因为你会多少技巧，而是因为你先分清了：哪些工作属于首屏前必须完成的关键路径，哪些只是长期被顺手塞进启动阶段的负担。

关键路径一旦不清楚，优化就很容易变成局部勤奋。
关键路径一旦清楚，很多优化方向反而会非常明确。