1. Android 基准测试概述
说到性能优化，很多人第一反应就是「卡顿」「掉帧」「内存泄漏」。但我想问一句：你怎么知道你的 App 变快了还是变慢了？ 靠感觉？靠用户反馈？那可不行。
基准测试，说白了就是把性能指标量化。就像体重秤，测之前你可能觉得「嗯，还行」，上了秤才发现——哦，原来问题这么大。我在项目中见过太多团队，上线前拍胸脯说「很流畅」，结果灰度一开，用户骂声一片。为什么？因为没有基准数据做对比。
为什么我们需要基准测试？
我经常跟团队说：性能优化不是撞大运，而是一场有数据支撑的战役。基准测试至少解决三个关键问题：
- 定量评估 —— 你的优化到底提升了多少？10% 还是 50%？不能说「我觉得快了」。
- 回归防护 —— 新功能上线后，性能有没有变差？基准测试能帮你第一时间发现。
- 竞品对标 —— 你的 App 启动时间比竞争对手慢 0.5 秒，这对用户留存的影响有多大？只有数据能回答。
我记得有一次，我们优化了一个列表页面的滑动帧率，从 35fps 优化到 55fps。开发同学觉得「已经很好了」，但用基准测试一看，在低端机上还是只有 20fps。嗯，这才是真相。
基准测试的分类
你想想看，性能问题千千万，但通常可以归为几类。我习惯把它们分成三种：
| 类型 | 测量对象 | 典型场景 |
|---|---|---|
| 微观基准 | 单个函数或算法耗时 | JSON 解析速度、Bitmap 缩放性能 |
| 宏观基准 | 完整用户场景 | App 冷启动时间、页面滑动帧率 |
| 专项基准 | 特定资源维度 | 内存占用峰值、网络请求延迟 |
微观基准 适合开发者自测。比如你改了一个排序算法，到底快不快？写个微 benchmark 跑一下。Android 官方提供了 Microbenchmark 库，我经常用它来验证代码变更的影响。
宏观基准 是最重要的，因为它直接反映用户感知。我曾在一个电商项目中，把首屏加载时间从 3.2 秒优化到 1.8 秒，转化率提升了 12%。但这个优化如果没有持续跑基准测试，下次合入一段异步加载代码就可能打回原形。
专项基准 则针对特定痛点。比如你发现某个页面内存只增不减，那就要写个专项测试——反复打开关闭页面，监测 GC 次数和堆内存变化。
常用工具与流程
说到工具，Android 生态里选择不少。我按自己的使用频率排个序：
- Android Profiler —— 集成在 AS 里，适合快速看 CPU/内存。但精度有限，尤其是帧率。
- Systrace / Perfetto —— 系统级 trace，能定位到具体线程和函数调用。我拿它抓过很多次启动卡顿。
- FrameMetrics / Choreographer —— 代码内手动采集帧时长，适合集成到自动化测试中。
- PerfDog / 第三方工具 —— 跨平台、低开销。我在做竞品分析时经常用。
一个完整的基准测试流程，我通常这样走：
1. 定义测试场景（启动、滑动、点击）
2. 确定关键指标（帧率、时长、内存）
3. 编写自动化脚本（UiAutomator + 数据采集）
4. 在固定设备上跑 10 次以上取中位数
5. 对比基线，判断是否达标
6. 将结果存入 CI 管道，持续监控嗯，这里要注意：测试环境必须严格一致。我踩过一个坑：在开发机上跑完基线，隔天换了一台测试机，数据完全对不上。后来才发现两台手机的 CPU 降频策略不同。所以我现在会固定几台「黄金参考机」，专门用来跑基准测试。
核心指标速览
初学者往往容易被各种指标搞懵。我帮你理一下哪些是真正有用的：
| 指标 | 含义 | 及格线（参考） |
|---|---|---|
| 帧率 (FPS) | 每秒绘制的帧数 | 稳定 > 50fps |
| 渲染时长 (FrameTime) | 每帧从绘制到显示的时间 | < 16ms |
| 冷启动时间 | 从点击图标到首帧展示 | < 2s (推荐 < 1.5s) |
| 内存 PSS | 进程独占物理内存 | 视功能而定，避免持续增长 |
| GC 次数 | 垃圾回收频率 | 连续操作中 < 5 次/分钟 |
我个人最关注的是 帧时长分布。光看平均帧率没意义——哪怕平均 55fps，只要有几次掉到 10fps，用户就会觉得「卡」。所以一定要看 P99 或者 P95 的帧时长，这才是真实体验。
最后唠叨两句
基准测试并不是银弹，它不能替你定位 bug，但它能给你一把尺子。有了这把尺子，你才知道自己走了多远。接下来的章节我会手把手带你搭建一套可落地的 Android 基准测试体系，包括帧率监控、自动化脚本、CI 集成等。嗯，准备好了吗？