启动性能概述
做移动端开发这么多年，启动性能一直是我最重视的指标。说白了，用户对你的 App 第一印象，就取决于它启动快不快。你想想看，点开一个应用，盯着白屏看两三秒，是不是特想直接划走？这章咱们就把启动性能的核心概念讲清楚。
什么是启动性能
启动性能，就是从用户点击 App 图标，到 App 完全可交互的整个过程耗时。听起来简单，但里面的环节可不少。
我个人习惯把启动拆成几个关键阶段：
- 进程创建 —— 系统分配资源，拉起进程
- Pre-main 阶段 —— 动态库加载、ObjC 初始化、C++ 静态对象构造
- main 函数执行 —— 业务代码开始跑起来，SDK 初始化
- 首帧渲染 —— 第一个 UI 界面绘制完成，用户看到内容
- 可交互 —— 页面完全就绪，用户能正常操作
我在一个电商项目里遇到过，Pre-main 阶段就占了将近 1.5 秒。我们排查了很久，最后发现是某个第三方 SDK 在 +load 里做了大量计算。嗯，后面我会专门讲这类坑。
为什么启动性能如此重要
启动慢，用户就跑。这是铁律。我见过太多项目，因为启动慢导致留存掉了好几个点，花大价钱买来的流量全浪费了。
数据不会骗人：
- 启动耗时每增加 1 秒，用户流失率提升约 20%
- App 启动超过 3 秒，超过半数用户会选择退出
- 启动优化后，次日留存率平均能提升 5%–15%
核心数据： Google 统计显示，启动耗时从 2.5s 优化到 1.5s，用户转化率提升约 8%。这可不是小数目。
你想想，花那么多精力做推广，结果被启动速度劝退了，多冤。所以我现在做项目，启动性能一定是首屏必盯的指标。
冷启动与热启动
启动类型不同，优化策略也不一样。理解这个区别，是优化的大前提。
| 启动类型 | 定义 | 典型耗时 | 触发场景 |
|---|---|---|---|
| 冷启动 | App 进程不存在，需从头创建 | 1.5s – 5s | 首次安装、被系统杀后台后重启 |
| 温启动 | 进程存在，但 Activity 需重建 | 0.5s – 1.5s | 切到后台较久，部分资源被回收 |
| 热启动 | 进程和 Activity 都还在内存中 | 0.2s – 0.5s | 按下 Home 键后立即切回 |
避坑指南： 我曾经以为热启动不需要优化，结果发现有个模块在热启动时重复初始化，导致内存暴涨。别轻视热启动，它同样会出问题。
这里有个容易忽略的点——冷启动是优化的主战场，因为它耗时最长、体验最差。但温启动和热启动也要监控，特别是热启动场景下的资源泄漏，往往藏得很深。
常见启动耗时基准
没有基准，就没法衡量好坏。这是目前业内比较公认的标准：
- 优秀： 冷启动 < 1.5s，热启动 < 0.3s
- 良好： 冷启动 1.5s – 2.5s，热启动 0.3s – 0.5s
- 及格： 冷启动 2.5s – 4.0s，热启动 0.5s – 1.0s
- 不及格： 冷启动 > 4.0s，热启动 > 1.0s
注意： 基准不是的。不同业务容忍度不一样。工具类 App 可以放宽些，但支付、社交类 App 必须严格。另外，中低端机的启动耗时可能是旗舰机的 2–3 倍，定基准时一定要覆盖主流设备。
在实际项目中，我一般把冷启动控制在 2 秒以内。超过这个值就得拉警报了。好，基础概念梳理完了，下面这张图可以帮你把知识体系串起来。