1. 性能优化概述：什么是无感启动、核心指标与优化原则

大家好，我是你们这趟性能优化之旅的向导。做了十几年性能优化，我见过太多应用因为启动慢、界面卡顿被用户无情卸载。今天咱们先聊聊最基础的东西——到底什么是无感启动，以及我们该关注哪些指标。

1.1 什么是无感启动？

说白了，无感启动就是让用户感觉不到应用在“加载”。你想想看，用户点开一个 App，最烦的就是盯着白屏或者菊花转圈。我个人的习惯是，如果某个应用启动超过 2 秒，我基本就不会再用第二次了。

无感启动不是真的“零等待”，而是通过技术手段把等待时间藏起来。比如：

• 先展示一个有意义的界面骨架，而不是白屏
• 把耗时的初始化操作放到后台线程
• 预加载用户最可能用到的数据

我在项目中遇到过这样一个场景：一个电商 App 的首页启动需要加载 20 多个接口。如果等所有接口都返回再展示，用户得等 3 秒以上。后来我们改成先展示本地缓存的商品列表，同时后台拉取最新数据，用户几乎感觉不到等待——这就是无感启动的典型实践。

1.2 性能优化的核心指标

做优化不能凭感觉，得有数据说话。我一般会盯着三个核心指标：启动时间、帧率、内存占用。这三个指标就像汽车的油门、方向盘和刹车，哪个出问题都不行。

1.2.1 启动时间

启动时间是用户对应用的第一印象。通常我们把它分成三个阶段：

阶段	定义	目标值
冷启动	进程从零开始创建，没有缓存	< 1.5 秒
温启动	进程还在，但 Activity 需要重建	< 1 秒
热启动	进程和 Activity 都在，直接恢复	< 0.5 秒

嗯，这里要注意：冷启动是最难优化的，因为它涉及类加载、布局渲染、数据初始化等一系列操作。我曾经接手过一个项目，冷启动时间高达 4.2 秒，光是 Application 的 onCreate 里就做了 8 个第三方 SDK 的初始化。后来我们用了延迟初始化和按需加载，硬生生砍到了 1.8 秒。

1.2.2 帧率

帧率决定了界面流畅度。Android 和 iOS 都是 60Hz 刷新率，意味着每一帧必须在 16.67ms 内完成渲染。一旦超过这个时间，就会出现掉帧，用户就会觉得“卡”。

我习惯用 FrameMetrics 或者 Choreographer 来监控帧率。如果发现连续掉帧超过 3 次，基本就能判定有性能问题了。

1.2.3 内存占用

内存占用是性能优化的“隐形杀手”。内存太高会导致：

• 系统频繁 GC，引发卡顿
• 被系统 LMK（Low Memory Killer）杀掉
• 应用崩溃（OOM）

我曾经遇到过一个问题：一个图片浏览应用，用户翻到第 50 张图时直接闪退。查了半天发现是图片缓存没有做 LRU 限制，内存涨到了 800MB。后来加了个 Glide 的缓存策略，内存稳定在 150MB 以内。

这三个指标是相互影响的。比如内存占用过高会导致 GC 频繁，GC 又会引发掉帧，掉帧多了用户就觉得卡，卡了就会卸载——你看，一个指标崩了，连锁反应就来了。

1.3 优化原则与策略

做了这么多年优化，我总结出几条铁律。这些原则不是书本上抄来的，是踩坑踩出来的。

原则一：先测量，后优化

没有数据支撑的优化都是耍流氓。我见过太多人上来就改代码，改完发现性能没变化，甚至更差了。正确的做法是：

1. 用工具（如 Profiler、Systrace）定位瓶颈
2. 量化当前性能数据
3. 针对瓶颈做优化
4. 再次测量验证效果

原则二：二八定律

80% 的性能问题往往集中在 20% 的代码上。别想着面面俱到，先找到那 20% 的“热点代码”。常见的性能热点包括：

• 主线程上的 IO 操作
• 频繁的 GC 触发点
• 过度绘制（Overdraw）
• 大图加载

原则三：延迟加载，按需初始化

别在启动时把所有东西都准备好。用户可能根本用不到某些功能。我常用的策略是：

• 异步初始化：把非关键路径的初始化放到子线程
• 懒加载：用到时才初始化
• 预加载：预测用户行为，提前加载可能用到的资源

原则四：缓存为王

网络请求、图片解码、布局解析——这些耗时操作都可以用缓存来优化。但缓存不是越多越好，要控制好大小和淘汰策略。

下面这张图是我自己总结的性能优化知识体系，你可以看看各个模块之间的关系：

1.4 本章小结

这一章我们聊了无感启动的概念、三个核心指标（启动时间、帧率、内存占用），以及四条优化原则。说白了，性能优化不是炫技，而是让用户用得爽。后面的章节我们会深入每个指标的具体优化手段，到时候再细聊。