1、性能基准测试概述：什么是性能基准？为什么需要性能基准？性能基准的分类与常见误区
大家好，我是你们这次课程的讲师。做性能优化这么多年，我见过太多团队一上来就对着代码盲调，结果调了半个月才发现——连目标都没对齐。所以咱们开篇先讲清楚一个基础问题：你到底要测什么？怎么才算“好”？这就是性能基准要回答的事。
1.1 什么是性能基准？
性能基准，说白了，就是一把标尺。
你定一个场景，跑一组操作，记录下关键指标（比如启动耗时、帧率、内存占用）。这组数据就是你的“基准线”。以后每次改动，都拿这个线来比——快了还是慢了？涨了还是降了？一目了然。
我记得刚入行时带我的老工程师说过一句话：“没有基准的性能优化，就是瞎折腾。” 当时我不太理解，后来自己踩了坑才明白——你真以为优化了，实际上可能只是心理作用，或者测试环境不一样导致的数据波动。基准就是用来消除这种不确定性的。
1.2 为什么需要性能基准？
我把它拆成三个价值点来讲：
- 目标对齐： 产品说“要快”，研发觉得“快了2秒”，测试说“快了0.5秒”。到底谁说了算？基准数据说了算。大家对着同一个数字讨论，不多废话。
- 回归防护： 我最怕的就是改了A模块，B模块反而变慢了。没有基准，这种问题要等到用户投诉才发现。有了基准，每天跑一遍CI，哪个指标飘红了立刻报警。
- 优化方向： 我举个例子：你App启动从5秒优化到3秒，看起来很大进步。但如果基准告诉你，竞品只要1秒，那2秒的差距其实依然不可接受。基准帮你找准真正需要下功夫的地方。
有一次我接手的项目，内存泄漏已经拖了三个月。团队里人人都在猜是哪段代码的问题。我建了一套内存基准用例，跑完数据直接定位到某个图片缓存库的错误使用。修复后基准数据立竿见影。没有基准，就只能继续猜下去。
1.3 性能基准的分类
我习惯把性能基准按视角分成以下三类，方便理解：
| 类别 | 关注点 | 典型指标 | 使用时机 |
|---|---|---|---|
| 用户视角基准 | 用户真实体感（冷启动、滑动流畅度、页面加载） | 启动时间、FPS、ANR率、白屏时长 | 日常迭代回归、发版前验收 |
| 系统视角基准 | 资源消耗（CPU、内存、磁盘IO、网络流量） | CPU占有率、PSS内存值、GC次数、磁盘读写量 | 性能压测、竞品对比 |
| 代码视角基准 | 具体函数/模块的执行效率 | 方法耗时、布局measure/layout/draw时长、线程休眠时长 | 定位瓶颈、优化验证 |
你想想看，用户视角决定“是否能用”，系统视角决定“能否稳定”，代码视角决定“能否优化”。三个维度缺一不可。
1.4 常见误区
做基准测试这些年，我见过太多翻车现场。这里列几个最常见的坑：
- 误区一：一次测量就当成基准
有一次项目赶进度，测试同学跑了一次启动耗时，记下来当基准。第二天再跑，差了200ms，一下就慌了。其实设备温度、后台进程、系统负载都会影响单次结果。我建议至少跑5~10次，取中位数或平均值。 - 误区二：不控制测试环境
“咦，为什么昨天和今天数据差这么多？”——因为昨天是在低电量模式下测试的，今天插着充电器。或者昨天后台开了微信，今天没开。环境变量不一致，基准就是废纸。我自己的习惯：固定设备型号、系统版本、充电状态、后台进程数，甚至屏幕亮度都要一致。 - 误区三：忽略统计波动
嗯，这里要特别说一句。就算环境固定，数据还是有波动。我见过有人把一次优化后5.2s和基准5.3s的0.1s差异吹成重大提升。其实波动范围可能就有0.3s。0.1s不过是噪音而已。正确的做法是用置信区间或显著性检验来判断。
每发一个新版本、每改一段关键逻辑，都应该重新采集基准数据。别等到线上用户抱怨了才后悔。
1.5 性能基准测试的知识体系
我画了一张图，帮大家从整体上理解：性能基准测试到底包含哪些环节，它们之间怎么关联。这张图你之后学完每一章都可以回来对照看，相当于一张全景地图。
从图里你能看到：先定义基准 → 按三个视角分类 → 制定具体方案 → 执行采集与分析 → 输出报告并持续跟踪。同时右侧提醒你一定要避开那些常见误区。
1.6 本章小结与建议
性能基准不是什么玄学。它就是一组可重复、可对比的测量数据。我个人的习惯是：每开始一个新项目，第一件事不是写代码，而是把基准采集架子搭好。哪怕初期数据不好看，没关系，至少你知道自己现在在哪。