企业官网建设流程全解析

做启动性能优化做得越多，我越觉得一个项目里最难的部分往往不是“怎么优化”，而是“怎么定义优化目标”。

很多团队一说启动优化，第一反应就是压冷启动耗时，把几十个初始化任务丢到异步线程，跑一轮机器看到数字降了就算交差。但真到线上，用户还是说“打开慢”，你一头雾水。等把整个链路拉通之后，你才会发现真正的问题往往藏在 Boot、冷启动、热启动三种窗口的交界处：你优化了 A 场景，用户感知的 B 场景却更差了——因为你根本没把启动链路的时间漏斗画完整。

这篇是稳定性性能系列的第九篇。我不打算给你列一份“启动优化 checklist”，而是想从三种启动窗口的边界讲起，把冷启动优化真正值得动手的杠杆、热启动和 Boot 场景容易被忽略的隐性耗时、以及“优化之后怎么保证稳定”这件事讲透。内容面向做应用性能、稳定性、框架优化的小伙伴，也适合刚接手启动性能专项、想建立全局判断的同学。

1. 先把时间漏斗画清楚：Boot、冷启动、热启动的边界到底在哪

1.1 三个启动窗口的差异

在移动端项目里，“启动”并不只有我们在测试环境按一下冷启动那一下。从设备上电到用户点开应用，再到用户第二次、第三次从最近任务切回，整个过程至少可以分成三个完全不同的窗口：Boot、冷启动、热启动。

Boot 指的是设备从开机到系统可用这一整段窗口。这个阶段系统在做包扫描、系统服务初始化、桌面启动、开机广播分发等大量工作，CPU、磁盘 IO、内存带宽都属于“被争抢”的状态。很多应用会注册开机广播，在 Boot 窗口内做自启、拉活、数据预取。这个窗口的特点是你看到的每一项任务单独看都不大，但叠加在一起会明显拉长开机完成时间，也会让开机后的第一次应用冷启动变得异常缓慢。

冷启动是应用进程从头创建的过程。系统里原本没有这个应用的进程，用户点击图标后，系统要创建进程、创建 Application、创建 Activity、完成第一帧渲染，再到用户真正可以操作。这是整个启动链路里成本最高、也是大多数团队重点优化的场景。

热启动则分成两种常见形态：一种是应用进程还活着，Activity 也还在任务栈里，用户只是切回前台；另一种是进程还活着，但 Activity 已经被系统回收，用户切回时需要重建 Activity 而不是重建进程。很多人把热启动等同于“切后台再切回来”，这其实不够准确。重建 Activity 的热启动，恢复成本很多时候比你想的要高。

1.2 为什么边界不清会让优化“白做”

我见过不少团队在冷启动上花了很大力气，结果线上首帧数据好看，用户却依然觉得“打开慢”。原因往往出在三个地方。

第一，首帧定义被系统启动图“骗”了。Activity 还没有真正创建时，系统已经把 windowBackground 作为启动图显示出来了，这个画面出现得很快，但它不能代表业务代码已经就绪。如果你以这一帧作为结束点，所有优化都会显得“已经到底了”。

第二，热启动路径没有纳入优化范围。用户冷启动优化完之后，日常使用中最频繁的反而是热启动。如果热启动恢复路径上有大量重复初始化、状态恢复、图片重新解码，用户感知到的“慢”会被归因到冷启动头上，但你无论如何压冷启动都压不动。

第三，Boot 窗口的影响被误判成机型性能问题。中低端机开机后的第一次冷启动，经常比平时慢出好几倍。如果不看系统启动状态，只拿开机后的首启数据做优化前后对比，结论可能是错的。

所以在动任何优化之前，先把三种窗口的时间漏斗画出来：Boot 阶段的资源竞争、冷启动的进程创建与初始化、热启动的 Activity 恢复与状态回填。每个窗口的优化手段和度量口径都不一样，混在一起做，得到的只能是一团糊涂账。

2. 度量先行：不同启动场景的埋点口径与样本采集

2.1 系统工具能告诉你什么

启动优化如果只靠人手一只秒表，基本等于瞎优化。第一步是先建立起一套可复现的度量方式。

在 Android 侧，最基础的工具是adb shell am start -W。这条命令可以打印从启动 Activity 到首帧呈现的系统侧耗时，适合在固定机型上做横向对比。实际使用中我一般会配合am force-stop先杀掉应用进程，保证测的是冷启动语义：

# 先停止应用，确保进程不存在 adb shell am force-stop com.example.debug # 再启动目标 Activity，并打印启动耗时 adb shell am start -W -n com.example.debug/.MainActivity

am start -W输出的参数可以拿来评估同一台设备、同一个版本的前后变化，但不要直接把它当成线上用户可感知的启动时间。原因在于：Activity 首帧出现并不等于页面真正可交互，而且这条命令覆盖不到 Application 初始化之后的大量异步逻辑。

2.2 埋点里最容易被带偏的两个口径

真正要建立的是应用内的自定义启动打点。建议把启动过程切成几段：进程创建、Application.attachBaseContext、Application.onCreate、Activity.onCreate、首帧、reportFullyDrawn、用户可交互。

第一段是进程创建。如果你在 API 29 及以上，可以拿到进程真实的启动时间，低版本则在attachBaseContext里记录一个近似起点。注意attachBaseContext在多进程场景下会被调用多次，必须用进程名过滤，只统计主进程。

第二段是结束点。首帧和“用户可交互”不是同一回事。reportFullyDrawn()这个机制可以让你在首帧之后、布局和数据都准备好的时机主动上报“完全绘制”。我建议同时统计首帧时间和 fully drawn 时间，两个都上报，后续分析时才不会因为某个页面“首帧很快、内容很慢”而被误导。

还有一个容易翻车的点：冷、热启动的判定。你可以在进程内维护一个标记位，进程第一次执行到启动流程时必然是冷启动；Activity 只是从后台回前台、没有重新执行 onCreate 的属于热启动；Activity 被重建、但是进程仍然在的，属于“温启动”，统计时建议单独归类。很多团队把冷启动和热启动混在一个指标里，版本对比自然不稳定。

2.3 样本分布决定优化方向

启动耗时是典型的右偏分布，少数中低端机、后台任务繁忙、存储接近满的场景会把平均值拖得很难看。所以线上大盘不要只盯平均启动耗时，至少要看 P50、P90、P95 三档。

P50 代表大多数普通用户能感受到的水平，P90 到 P95 代表尾部用户，也就是最容易在应用商店打低分的那批人。如果优化后 P50 降了但 P95 反而涨了，说明你在提升平均体验时伤到了某些机型，这时候要做的是分层优化，而不是直接上线。

样本数量也要注意。新版本刚发布时，启动打点样本量可能不够，尤其是低端机样本很少，这时候得出的分位值波动会非常大。我一般会等新版本样本覆盖到指定比例之后再对比，避免把版本升级后用户分布变化误判成优化收益。

3. 冷启动优化真正值得动手的四个杠杆

3.1 初始化任务重排：从“首帧前必须完成”倒推

冷启动优化最有效的动作，往往不是“把代码写快”，而是“把不该放在启动路径上的代码移走”。

我建议把 Application 启动过程里所有初始化任务列成一张表，逐项回答三个问题：第一帧渲染必须要它吗？业务主流程必须要它吗？用户首次操作前必须准备好吗？

整理完之后，任务通常能分成三类。

• 第一帧前必须完成的任务：渲染核心、崩溃采集、启动必用的基础配置。
• 首帧后但不一定要立刻完成的任务：网络库、推送、埋点、部分安全组件、账号状态同步。
• 真正可以懒加载的任务：地图、浏览器内核、广告、低频业务模块。

对于第二类任务，不要简单丢到一个线程池里就算完。任务之间往往有依赖关系，比如登录态要先初始化，网络库才能发请求；配置先读出来，业务模块才能初始化。这种场景适合用有向无环图的方式做任务编排，把“并行初始化”变成“按依赖关系并行”，而不是靠线程数硬堆。并行度并不是越高越好，线程太多反而会增加锁竞争和 CPU 调度开销。

3.2 主线程减负：布局、存储与类加载

主线程上的每一毫秒浪费，在冷启动阶段都会被放大几倍。 这三个方向是我每次排查启动性能时必查的。

布局方面，启动路径上第一个业务页面的 View 树复杂度会直接影响首帧耗时。不要只看布局文件里有多少层，还要看有没有嵌套过深、权重测量、复杂 RelativeLayout 约束。减少一层无用容器、把一个重量级自定义 View 拆成更轻的实现，效果可能比你想的更可观。

存储方面，启动过程最怕在主线程做磁盘 IO。SharedPreferences 首次读取、数据库连接初始化、大文件扫描，这些操作在主线程上很容易造成明显的启动卡顿。如果首帧前一定要读配置，应该把配置读进内存后复用，而不是每次启动都重新解析；数据库迁移这类重活，尽量放到独立线程或者升级后的专门流程里。

类加载方面，Java 和 Kotlin 类第一次被使用时要经历加载、校验、初始化等过程，启动路径上类的数量越多，耗时越长。这句话的另一面是：如果你用 R8/ProGuard 做代码缩减，把启动路径上用不到的类剪掉，冷启动收益通常很直接。但反射场景要格外小心，缩减规则配错会直接导致运行时崩溃。反过来，“提前预加载”也要克制，只有在确实测到某个类首次加载阻塞了主线程时才值得做，否则只会白白增加启动内存和 IO。

3.3 首帧到可交互的过渡时间别忽略

冷启动优化如果只盯首帧，很可能会漏掉真正影响体验的“半秒空白”。

首帧画出来了，用户看到的是一个壳子，业务数据还没回来，按钮点了没反应，这种状态往往比白屏更让人烦躁。所以首帧之后到 fully drawn 之间的过渡时间，反而是优化空间很大的区间。

操作上，可以在首帧之后的第一次主线程空闲时，再去触发真正耗时的初始化，比如数据预加载、页面渲染、部分上报。用 IdleHandler 或者类似的空闲回调，比硬编码 sleep 可控得多。不过要注意，不能把所有延迟任务都塞进空闲回调，因为用户可能在空闲回调触发前就退出了应用，导致任务永远执行不完。

另一个常见问题是：首帧之后立刻发起一大堆线程任务，把主线程和 CPU 全部打满，结果页面滑动掉帧、网络请求互相排队。启动优化讲究的是“前慢后快”，该慢的初始化宁可晚一点，也别让首帧和用户交互抢资源。

3.4 启动图与闪屏：看着快了但不一定是真快

很多团队会用 windowBackground 做一个品牌启动图，系统在 Activity 创建前就把这张图显示出来，视觉上“秒开”。但这只是把白屏换成了图片，并没有减少 Activity 初始化和业务加载的时间。

如果启动图展示的是品牌图，而 Activity 真正的首帧要等 2 秒才出现，用户的真实感受是“卡在启动图半天进不去”。更合理的方式是：用 windowBackground 消除白屏，同时让真实的启动页或者业务页尽快接管，接管之后立刻做无缝转场，不要故意用“启动图倒计时”拉长展示时长。

这里说一句可能不太讨喜的话：启动图广告本质上是用性能换营收，它会把用户感知的启动时间拉长，和启动优化是直接冲突的。如果你同时负责这两块，心里要有数——你压下去的启动耗时，很可能被商业策略又加了回来。

4. 热启动与Boot场景：容易漏掉的隐性耗时

4.1 热启动不是“换个页面”，恢复路径也要做减法

热启动看起来快，但并不意味着没有优化空间。特别是“进程还在、Activity 被系统回收”这种场景：无需重新创建进程和 Application，但 Activity 的 onCreate、setContentView、布局 inflate、数据恢复全部要重新执行一遍。

最容易出问题的是状态恢复。如果 onSaveInstanceState 里塞入了大对象、位图或者复杂的序列化结构，恢复路径上就会出现反序列化开销；如果恢复数据还要重新从磁盘读，这个成本会进一步放大。热启动优化的方向不是压缩系统启动逻辑，而是给 Activity 的“重建”做减法：能不入栈的数据不入栈，能缓存在内存的重用缓存，避免每次回来都重新计算。

另外还要关注进程被系统 Trim Memory 之后的情况。很多页面把图片缓存放在内存里，内存紧张时候这些缓存被清掉，用户切回页面时只能重新解码，热启动瞬间会感觉特别卡。治本的方法是把热启动路径上的资源缓存策略调整成“内存不足时先释放可重建的低优资源”，而不是把页面恢复依赖的资源也一起清掉。

一个参考判断：如果你们热启动的 P50 比冷启动 P50 的一半还高，大概率是因为启动流程里有重复初始化和恢复开销。这时候回头查 Activity 重建路径，收益往往比继续压冷启动更大。

4.2 Boot窗口：开机广播与冷启动的“低气压区”

Boot 窗口是很多应用团队完全没接管、却直接影响用户体验的一块。

系统开机后要做包扫描、预加载系统组件、恢复上次运行状态，磁盘和 CPU 都处于繁忙状态。如果你的应用注册了开机广播，并且在广播回调里同步做了大量初始化，你抢到的不是“自己的启动速度”，而是整个系统开机完成的时间，还会连累同窗口内其他应用。

对于绝大多数应用，开机广播里最该做的事情是：什么都不做。把真正的任务交给系统级延迟调度，等到系统空闲、满足网络条件或充电条件后再执行。即使业务上确实需要开机后尽快运行，也应该控制启动的线程数、IO 量和锁的持有时间，不要在系统最忙的时候添乱。

Boot 窗口还会直接影响应用冷启动。应用更新后首次启动、系统对代码做编译优化时，冷启动会比平时慢很多。这种慢不是业务代码造成的，而是系统在后台做包优化。如果你在线上发现某次版本发布后冷启动数据突然变差，先确认是不是新包触发了系统编译优化，再决定要不要追业务代码。这类问题的处理方式不是“优化”，而是“区分责任”，把系统侧耗时从业务侧指标里剥离出来。

5. 快之外的稳定性红线：别把启动优化做成事故

5.1 异步化不等于安全化

启动优化最常用的手段是异步化，但异步化恰恰是启动阶段引入崩溃和 ANR 的高发区。

一个典型的例子：某个初始化任务原来在主线程上，执行顺序确定的，改成异步之后，另一个任务依赖它的结果却不知道它在哪个线程执行完，于是一边等待一边超时，最后主线程被卡死，出现 ANR。还有的团队把崩溃上报 SDK 初始化改成异步，结果应用在异步初始化完成之前就崩溃了，线上崩溃直接漏报。

我给所有做启动优化的团队一个很实用的建议：把启动任务按“同步必要性”和“状态一致性”分等级，而不是简单地分成“主线程任务”和“异步任务”。以下几类任务要非常谨慎：

• 崩溃采集和日志上报：必须最早初始化，通常不要异步，或者异步后要有“等待完成”的兜底。
• 影响 UI 展示的数据：可以异步加载，但主线程要有一个明确的超时和空态策略。
• 多个模块共享的状态：必须保证初始化顺序，或者提供统一的“就绪回调”，不能靠猜。
• 与账号、支付、安全相关的能力：不要为了启动快而牺牲正确性。

5.2 上线前必须锁定的联合指标

启动优化上线之前，不只是看启动耗时降了多少，还要同时锁定一组稳定性指标：冷启动崩溃率、启动 ANR 率、启动后 1 秒和 3 秒的线程数、内存 PSS 峰值、文件描述符数量、GC 次数。

为什么强调联合指标？因为启动优化的很多手段是“拆东墙补西墙”。比如把数据库初始化挪到异步线程，首帧快了，但用户第一次进入数据页时，主线程因为等待数据库就绪而卡顿，ANR 率反而上升；比如把图片压缩力度加大，启动快了，但放大后清晰度下降，用户觉得页面糊。这些都是优化生效但整体体验变差的案例，只靠一个指标根本发现不了。

我看一个启动优化改动是否成立，会要求同时给出“优化前后启动指标对比”和“优化前后稳定性指标对比”。只要稳定性指标出现恶化，即使启动耗时降了很多，也不会轻易放它上线。

6. 从本机跑分到线上大盘：一套能落地的回归闭环

6.1 线下的固定基线：让“跑分”可复现

启动优化的基础功，是维护一批固定的测试设备，覆盖高中低端、不同内存档位，用固定的脚本在每个版本上跑启动测试。测试脚本至少要做到：自动清理进程、自动启动目标页面、自动抓取系统启动耗时和应用内埋点。

不要靠人工按秒表，人的反应误差有时候比优化幅度还大。也不要只跑一次，同一台机器上连续跑多次，会因为有系统缓存而越来越快。常规做法是先杀掉进程，跑两三次“预热”，让系统完成必要的包编译和缓存构建，然后再连续采样并取中位数。

脚本本身也可以写成固定命令，配合 CI 在每次版本出包后自动跑：

# 清理最近任务并强停应用，保证冷启动语义 adb shell am force-stop com.example.debug # 启动并等待首帧 adb shell am start -W -n com.example.debug/.MainActivity # 抓取应用内启动埋点日志 adb logcat -d -s StartupMetric

线下固定基线的意义不是“测得绝对精确”，而是让前后版本之间具备可比性。所以线上机型、系统版本、测试流程都不要随意更换，每次对比都用同一台基线机。

6.2 线上的分位值监控：别被平均数骗了

线下测完，不等于优化闭环结束。真正起作用的是线上大盘：冷启动 P50、P90、P95，热启动 P50、P95，首帧到可交互的分段耗时，启动崩溃率和 ANR 率。

线上版本对比时要特别小心两点。

第一，统计口径不能随便改。启动完成时间从首帧改成 fully drawn，相当于换了一条新的基线，前后数据没有可比性。如果必须调整口径，要把新旧口径并行统计一个版本周期再切换。

第二，不要只看版本平均值。新版本用户结构可能发生变化，比如灰度账号偏高端机，导致启动数据虚好。所以我会按机型档位做分层对比，重点看中低端机上的 P95，一旦优化对低端机不友好，马上能看出来。

另外建议建一个启动性能回归看板，每个版本发布后自动比对。它的价值在于：当你下次再改某项功能时，能第一时间发现“这个版本给启动路径加了 50 毫秒”，而不是等到用户反馈变差之后才追查。

我现在的工作习惯是：任何启动优化改动，必须附带三类数据——固定基线机上的前后对比、启动任务链路各分段时间、线上灰度后的分位值和稳定性指标。拿不出这三样，就不要说自己优化了启动。启动性能是一个长期维护的地基工程，不是某一次上线完成就结束的事情。