2、Android性能指标体系：核心指标及其含义
做Android性能优化，先得搞清楚「度量什么」。我见过不少团队一上来就抓帧率，结果CPU跑满、内存狂飙、App疯狂掉帧——你说问题在哪？其实每个指标都有自己的脾气。今天咱们把这六个核心指标掰开揉碎了讲。
2.1 帧率（FPS）—— 流畅度的第一道门槛
帧率就是每秒画面刷新的次数。60fps意味着每帧16.67ms内要完成绘制。低于这个数，用户就会觉得「卡」。
关键阈值：
- 60fps → 流畅体验
- 30-59fps → 可接受但能感知卡顿
- <30fps → 严重掉帧，用户体验极差
我遇到过一款视频编辑App，主界面滚动时频繁掉到45fps。一查发现列表里每个item都做了实时滤镜渲染——明明用户没在编辑，滤镜却一直在跑。优化后去掉非必要渲染，帧率稳定在58-60fps。
测帧率别只看平均值。90%低百分位（P90）或掉帧次数更有意义。一个App平均59fps，但每10秒卡住一次，用户照样骂娘。
2.2 CPU —— 性能的「发动机」
CPU使用率直接反映计算负载。通常关注两个维度：整体使用率和线程级使用率。
我习惯把CPU使用率控制在：前台场景 ≤ 30%，后台 ≤ 10%。超过这个范围，要么算法低效，要么跑着不该跑的线程。
注意：单核飙到100%比多核各30%更危险——App会「抢占」系统资源，导致其他线程卡顿，甚至引发ANR。
2.3 内存 —— 管好你的「仓库」
Android给每个App分配了Java堆和Native堆。常见指标是PSS（比例集大小）和USS（唯一集大小）。我重点关注两个数字：
- 峰值内存：App在复杂操作时涨到的最高点，不能超过系统限制（通常200-400MB视机型而定）。
- 内存泄漏增速：每次操作后PSS是否持续增长。我见过一个新闻App，每次刷新文章列表涨5MB，看20篇文章后直接OOM崩溃。
我以前处理过一个直播App的内存泄漏：每次开播时创建了大量匿名共享内存，但退出房间时没释放。线上崩溃率从2%降到0.1%，就是多写了几个release()。
2.4 网络 —— 别让用户「转圈圈」
网络指标不只是看延时。我把它拆成三块：
| 指标 | 含义 | 个人经验阈值 |
|---|---|---|
| DNS解析时长 | 域名解析耗时 | ≤200ms |
| 连接建立时长（TCP+TLS） | 三次握手+证书验证 | ≤500ms |
| 数据传输速率 | 下载/上传速度 | 大于200KB/s（弱网下） |
我曾经优化过一款社交App的图片加载：每次请求都新建连接，每个图片多浪费300ms。改成HTTP/2多路复用后，首屏加载时间从8秒降到2.5秒。
2.5 功耗 —— 「电量焦虑」的元凶
功耗优化常被忽视，但它直接决定用户是否卸载App。指标包括：
- 电池消耗%：App占用的电量比例
- 唤醒锁（WakeLock）时长：后台不必要唤醒CPU
- 网络扫描频率：Wi-Fi或蓝牙频繁扫描耗电极大
避坑指南：我曾经接手一个天气App，后台每5分钟唤醒CPU更新定位。单次唤醒耗电0.03mAh，一天288次就是8.6mAh——用户手机电量就这么被耗空了。
2.6 启动时间 —— 第一印象决定留存
启动时间分冷启动和热启动。从点击图标到第一个可交互界面出现，我设定：
- 冷启动 ≤ 2秒
- 热启动 ≤ 1秒
- 启动不应用时闪屏或白屏超过1秒，用户大概率会关掉
为什么会有启动慢？我见过一个极端的案例：一个阅读App在Application.onCreate里初始化了三个数据库、两个网络SDK、一个保活服务，冷启动用了5秒。后面改按需加载，启动时间降到800ms。
这六个指标不是孤立的。帧率低可能是CPU过载，也可能内存不足触发GC卡顿。功耗高往往伴随网络频繁请求。实际优化时，我习惯先拉出所有指标曲线图，找相关性最高的那个「元凶」。
嗯，指标体系是性能优化的「地图」。每个指标都有自己的单位、测量方法和典型问题。我个人建议先建立基础监控，每个指标跑2-3次真实场景，把基线定下来。后面你再改代码，就知道到底有没有进步。
你想想看，如果一个App帧率只有40fps，但CPU才20%、内存平稳——那问题大概率在渲染管线里。反之，如果CPU飙到80%、内存狂涨，那就是计算或逻辑层有问题。这就是指标体系的价值：不是看单一数字，而是看组合拳。