2、性能优化基本方法论与度量指标归纳总结
说到性能优化，很多人第一反应是「哪里卡就优化哪里」。我刚开始做SDK开发时也这么想，结果发现修了个兔子洞，修完一个坑又冒出一个新坑。后来我总结出一套思维模型，才慢慢稳住局面。说白了，性能优化不是拼手速，而是拼方法论。
2.1 性能优化的核心思维
我个人习惯把优化过程拆成四个阶段：测量 → 分析 → 优化 → 验证。听起来简单，但很多人只做了一半。
- 测量：没有数据就没有发言权。先确认「性能到底差在哪里」，而不是凭感觉猜。
- 分析：把数据拆开，找到根因。比如CPU高，是主线程卡了？还是子线程抢资源？
- 优化：针对根因做改动。切忌一顿乱改，然后期望有效。
- 验证：优化完后必须复测，确认问题真的解决了，并且没有引入新问题。
我在项目中遇到过一位同事，他花了两周优化启动速度，结果上线后内存涨了一大截。为什么？因为他只看了测量阶段的启动时间，没做后续的验证。
2.2 度量指标的定义与分类
讲指标之前，先解决一个基础问题：什么样的指标才值得关注？我一般用这两个原则筛选：
- 可测量：能在真实环境中搞到数字，不能是模糊感觉。
- 可归因：指标的变化能对应到具体代码或场景，否则没法改。
按照SDK的审计场景，我把指标分成五大类，下面这个表整理清楚了。
| 分类 | 典型指标 | 测量点 |
|---|---|---|
| 启动性能 | 冷启动耗时、热启动耗时、首屏渲染时间 | Application.onCreate() 到第一个 Activity.onResume() |
| 内存 | PSS、Java Heap、Native Heap、GC 次数 | 任意时刻快照 + 连续采样 |
| CPU | CPU 占用率（整体/线程级）、主线程卡顿率 | 每隔 100ms 采样一次线程状态 |
| 网络 | 请求耗时、成功率、流量消耗、DNS 解析时间 | AOP 拦截 OkHttp/URLConnection |
| 卡顿/帧率 | FPS、掉帧率、ANR 发生率、帧耗时分布 | Choreographer 回调 + Looper 监控 |
重要提醒：同一类指标在不同版本、不同设备上的基准线可能差很多。我习惯把指标归一化为「相对于基线的变化率」，而不是裸数字。比如「内存比上版本涨了 15%」比「内存是 150MB」更有意义。
2.3 常见性能指标详解
启动耗时
启动快慢直接影响用户第一印象。注意区分冷启动、温启动和热启动。冷启动最重，也是我们打点的主战场。
我曾经遇到一个坑：某个版本启动时间突然从 1.2s 降到 0.9s，团队高兴坏了。结果仔细一看，是因为我们把某些初始化推迟到了 UI 显示之后。用户看到白屏时间没变，只是打点时机变了。所以测量启动耗时一定要跟「用户感知」对齐，不能只依赖 SDK 内部的打点。
内存
PSS（Proportional Set Size）是 Android 上最常用的指标，因为它考虑了共享库的分摊。但光看 PSS 不够，还要关注 GC 频率和 GC 暂停时间。GC 太频繁说明内存抖动，即使 PSS 不高，卡顿也会很严重。
CPU
CPU 占用率高不等于性能差。得看是在哪个线程、什么时间段。比如后台线程做大量计算，对前台体验影响小，而主线程稍微高一点就会导致卡顿。
网络
审计 SDK 经常跟服务端打交道。我最关心的是「成功率」和「尾部延迟」。平均耗时很多时候被小概率的超时拉偏了。你想想看，如果 99% 的请求都在 200ms 内，但 1% 的请求超时 30s，平均耗时也会很难看。所以我建议额外看 P99、P95 分位值。
卡顿/帧率
FPS 虽然是经典指标，但我个人觉得「掉帧次数」更有用。掉帧一次用户未必感知到，但连续掉帧肯定明显。另外 ANR 发生率是底线指标，必须监控到个位数。
2.4 指标采集与归因方法
指标采集不是简单的埋点。我总结出三条原则：
- 低侵入：采集代码不能影响宿主性能，否则测出来的全是噪声。能用 hooks 就别用 AOP，能用采样就别全量。
- 时间戳对齐：所有指标要带上统一的时间轴。比如启动耗时和第一帧时间必须能对应到同一个时钟，否则归因对不上。
- 上下文关联：光记录 CPU 占用率没用，得知道此时触发的事件是什么。我会同步采集设备状态、当前页面、网络状态等上下文。
归因的难点在于「链式分析」。比如用户反馈卡顿，你不能只看帧率。我会把卡顿发生时的 CPU 占用、内存堆栈、主线程堆栈、最近 2s 的网络请求全部抓出来，画成一条 Timeline。下面这个 SVG 图展示了完整的归因链路。
2.5 优化方法论：测量-分析-优化-验证闭环
有了指标和归因链路，接下来就是闭环操作。我个人习惯这样走：
- 建立基线：在目标设备（比如低端机）上跑出一组性能数据，作为参考线。
- 假设驱动：根据归因结果提出一个假设，比如「主线程执行了过多的 JSON 解析操作」。
- 单点修改：每次只改一处代码，且修改足够小。
- A/B 对比：在同一设备、同一网络环境下，对比修改前后的指标。
- 全量回归：确认改完后没有破坏其他指标（比如启动快了但内存涨了）。
小技巧：每次优化前，先拍个性能快照保存到文件。优化后再拍一次，用 diff 脚本自动计算变化。我常用自制的小脚本把 GC 次数、线程状态、帧率变化输出成表格，一眼就能看出问题。
2.6 避坑指南
- 不要只看平均值：我之前接手的 SDK，平均启动时间 900ms，但 P99 分位值到了 4.5s。如果只看平均，根本不会发现有人在某些机型上卡死。
- 不要忽略冷启动与热启动的差异：热启动有缓存，冷启动没有，优化方向完全不同。
- 采样频率要合理：100ms 采样一次足够，太快了采集本身就会影响性能。
- 排除非目标因素：如果测网络耗时，记得过滤掉手机断网、弱信号等极端情况，否则数据噪声太大。
注意：千万不要在生产环境做全量、高频的性能事件采集。我见过有团队把主线程 Looper 日志全量打出，结果线上卡顿更严重了。建议使用采样上报 + 本地回捞策略，既保证数据完备性，又避免频繁 I/O。
好了，这一章的内容差不多就是这些。记住：方法论比具体技巧更重要。你掌握了测量-分析-优化-验证这个闭环，再去处理具体的卡顿、内存泄漏等问题，心里会更有谱。