1. 数据来源与两个最容易被人忽略的计算前提做 Android 性能监控这一年多我花最多精力的地方不是怎么上报数据而是把 CPU 采集这件事的底层逻辑啃明白。因为项目里陆续出现 CPU 数据对不上的问题最后我总结出 8 个坑它们的共同点是读出来的数据和真实情况之间隔着一层又一层的口径、采样和语义差异。先说清楚背景。Android 上没有一行 API 能直接返回“当前 App 的 CPU 占用率”所有常见的性能监控方案原始数据都来自 /proc 这一层。读 /proc/stat 能拿到整个系统的 CPU 时间占比读 /proc/[pid]/stat 能拿到某个进程所有线程累计的 CPU 时间再往下钻一层/proc/[pid]/task/[tid]/stat 是单个线程的。这些文件看起来都特别直白打开就是一串数字但真正要把它们变成能用的 CPU 使用率需要先搞懂三件事这些数字是什么单位、是累计值还是瞬时值、计算结果要归一化到什么口径上。1.1 三张核心数据表路径、字段与增量关系我习惯先用一张表把数据源理清这样后面不管踩什么坑起码知道自己拿到的到底是什么。数据源文件路径拿到什么系统全局/proc/stat开机以来所有 CPU 核累计 tick包含 user/system/idle/iowait/irq 等分类进程级/proc/[pid]/stat该进程全部线程累计 CPU tick核心字段 utime/stime线程级/proc/[pid]/task/[tid]/stat单个线程的累计 tick频率信息/sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq核心当前运行频率核心拓扑/sys/devices/system/cpu/possible有哪些 CPU 编号/proc/stat 第一行是 cpu 开头后面跟着 user、nice、system、idle、iowait、irq、softirq、steal 这些数值。这行代表从开机到现在所有核心在这些状态下分别花了多少个 tick。一个 tick 是内核的时间片计数单位对应的时间长度由 CONFIG_HZ 决定常见的有 100Hz10ms和 250Hz4ms。所以这一行的数字只增不减只能在两次采样之间做减法。/proc/[pid]/stat 的坑在第二字段 comm。这个字段是进程或线程名理论上可能包含空格、括号、特殊符号。如果直接拿整行按空格 split取第 14 个字段当 utime很容易因为名字里有空格而全部错位。正确做法是找到最后一个右括号括号之后的内容再按空格切分从那里开始数字段。这一点后面讲线程识别时还会再展开。1.2 CPU 时间片口径busy、idle、iowait 的取舍计算全局使用率公式本身不复杂使用率 (totalDelta - idleDelta - iowaitDelta) / totalDeltatotalDelta 是两次采样之间系统总 tick 增量idleDelta 是空闲 tick 增量iowaitDelta 是等待 I/O 的 tick 增量。我习惯把 iowait 也归到“未干活”一侧因为它本质上是 CPU 在等外部设备没有真正执行指令。如果你把 iowait 算进 busy会出现一个很烦人的现象App 在做持续磁盘 I/O 时整机 CPU 使用率会被悄悄拉高看起来像计算负载上涨其实只是等待。移动设备上 iowait 通常很微小但如果整机 IO 压力大这个口径差异就会让监控数据和系统 top 对不上。所以我建议把 idle、iowait、busy 分开记录而不是只留一个聚合值这样口径可以随时切换不用重新跑一遍数据。1.3 正确公式与最容易出错的两种写法代码里最常见的错误有两种我都犯过。第一种是把 /proc/stat 的累计值直接拿来相除。开机两天后 idle 早就占了大头直接相除得到的是一个被历史平均淹没的数它和“此刻 CPU 在做啥”没有任何关系。正确写法必须先缓存上一次的读数用两次读数之间的增量来计算。第二种错误出在进程和线程使用率的归一化上。进程的 utimestime 增量是所有线程消耗的 CPU tick 之和一个进程在 8 核机器上理论上能同时占满 8 个核所以它的取值范围天然是 0 到 800%。做监控时通常要把它归一化到“相当于占用多少整核”double processCpu procDelta * 100.0 * coreCount / sysDelta;这段代码里的 coreCount 必须乘。procDelta 是进程跑的 tick 数sysDelta 是系统在同样时间窗口里所有核累计的 tick 数。sysDelta 本身已经包括了所有核心不乘核心数一个跑满单核的进程在 8 核设备上会被算成 12.5%。这个错误特别隐蔽因为 12.5% 这个数字看起来“好像有点低但也不至于离谱”。2. 坑一到坑三公式和口径不对后面全是白搭前三个坑全部集中在解析和口径层面属于“代码看起来没问题、结果却莫名其妙”的类型也是整个 CPU 采集过程中最容易发生误用的地方。2.1 坑一把累计值直接当成瞬时使用率我第一次写全局 CPU 采集的时候犯过最典型的错误就是直接拿 /proc/stat 的 busy/total 当 CPU 使用率上报。当时我在一台一直开着视频循环播放的手机上看数值稳定落在 8% 到 10%我一度以为这是正常的系统后台负载。直到某天大脑突然短路去查了开机时间才发现这台手机已经连续跑了 20 个小时。我算出来的根本不是“此刻 CPU 在跑什么”而是“过去 20 小时里 CPU 的平均忙碌程度”。排查的过程没什么悬念用 top 命令先对比发现 top 显示 60%我的数据却是 9%再用系统级 trace 抓一段确认真实负载确实偏高最后回到代码里读 /proc/stat 的原始值才发现自己用了累计值。这个坑一旦踩过就很难忘。所有 /proc 下的 CPU tick 数据都是单调递增的累计值要做的事永远只有一件——两次采样做差。这里还顺带提醒一点解析 /proc/stat 时第一行 cpu 是所有核的汇总下面 cpu0、cpu1 那些行是单独每个核的数据。如果只解析了第一行拿到的就是全局使用率如果解析了下面每一行才能做每核的分布统计。2.2 坑二多核归一化口径混乱8 核设备上数据忽高忽低坑二比坑一隐蔽得多因为它通常不会让代码报错只会让不同版本、不同设备上的数字打架。我印象最深的一次某次性能评估8 核旗舰机上 App 的 CPU 占用显示一直很高4 核中端机上反而很低大家都以为旗舰机负载更重。后来排查才知道两个测试团队用了两套计算逻辑。一方是 procDelta 除以系统总 tick 增量再乘 100%另一方是 procDelta 除以墙钟时间再乘 100%。前者在 8 核设备上天然偏小后者天然偏大根本没有可比性。正确理解是这样如果目标是“这个进程占用了多少个 CPU 核心的算力”就用下面这个公式单核归一化 procDelta / totalDelta × coreCount × 100%如果目标是“和 top 看到的值对齐”就用top 口径 procDelta / 墙钟时间8 核设备上一个满载 8 核的进程top 口径是 800%单核归一化是 100%。两个值都正确只是语义不同。问题出在团队里没有统一用哪个更没有在字段名里体现出来。我现在要求所有 SDK 上报时原始字段先给 procDelta 和 sysDelta百分比字段必须注明公式。宁可多传两个原始值也不要让下游同学拿着已经加工过、口径不明的百分比去做分析。2.3 坑三采样越频繁越准抖动和开销会打脸坑三来自我对“采样频率越高数据越准”的错误直觉。刚做监控 SDK 时为了捕捉瞬时卡顿我把采样周期压到了 50ms结果得到的 CPU 使用率曲线疯狂上下跳动每两个采样点之间可能差出 60 个百分点。原因是 CPU 时间在调度器里的累计粒度是 jiffy通常 10ms 或 4ms 一跳。采样窗口如果只够覆盖几个 tick只要调度器把某个线程多调度一个 tick计算出来的百分比就会突变。50ms 的窗口里总共就那么几个 tick任何抖动都会被放大。这也是为什么你用 top 的刷新间隔太短时会看到数字在乱跳。高频采样还有第二层代价读 /proc 是实打实的文件系统操作。监控模块每 50ms 遍历一次全部线程的 /proc/[pid]/task/[tid]/stat意味着每秒打开几十次文件CPU 占用被自己拉高。我后来用一个脏办法验证过把采集线程暂停 5 分钟看数据变化发现开着采集比关掉采集App 的 CPU 确实多了零点几个百分点。最后的方案是双轨平时 1 秒采样一次保证稳定检测到卡顿瞬间时临时切到 100ms 抓 10 秒尖峰。常规监控绝对不建议低于 100ms。3. 坑四到坑六大小核、睡眠和线程识别三块硬骨头前三个坑还停留在“代码层”后面这三个坑开始涉及到设备特性和线程生命周期不亲自动手很难发现而且踩坑时常常会误判成业务代码的问题。3.1 坑四大核小核频率差一倍百分比会骗人现在的旗舰机基本都是 143 或者 242 的三丛集架构同一台设备里小核最高 1.8GHz大核最高 3.2GHz这是很普遍的配置。同样是跑满一个核小核和大核的实际算力可以差出一倍多。只看 CPU 百分比很多判断都会失真。我遇到过的真实场景是这样做某种图像处理测试时同一段算法在小核上显示 100% CPU迁移到大核后显示 42%。如果不看背后的频率很容易得出“算法优化后 CPU 占用大幅下降”的错误结论实际上任务完成时间大幅变短了消耗的能耗甚至可能更高。要修正这个问题可以在采样时额外读取每个 CPU 核心的当前频率。读取节点是 /sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq代码逻辑大概是private int readCurFreq(int cpuIndex) { File f new File(/sys/devices/system/cpu/cpu cpuIndex /cpufreq/scaling_cur_freq); if (!f.exists()) return -1; try { return Integer.parseInt(readFile(f).trim()); } catch (Exception e) { return -1; } }拿到之后用一个简易公式做加权有效负载 ≈ CPU% × (当前频率 / 集群最大频率)这个近似不能算精确因为 CPU 的缓存命中和内存带宽也会影响真实算力但至少让大小核之间的数据具备了可比性。读取失败时记得降级不要在异常路径上报错误数据。另有一个文件 /sys/devices/system/cpu/cpuX/cpu_capacity 能直接给出核心算力权重能用就用读不到再用频率近似。3.2 坑五设备睡眠后采样结果被平均成一条直线手机和平板跟服务器最大的区别在于它真的会睡。屏幕灭掉以后系统会进入 deep sleep这时候绝大多数核心都进入低功耗状态/proc/stat 里的 idle tick 会暴增。如果两次采样之间夹着一段休眠期你的 CPU 使用率会被拉到非常低。我遇到过的误判是测试同事在灭屏 20 分钟之后导出数据发现 App 的 CPU 占用几乎为 0怀疑采集线程挂了。实际上数据没错只是这个“0”是把 20 分钟睡眠全部算进分母以后得到的平均值它根本不反映用户真实使用时的负载。判断睡眠窗口的办法很简单Android 提供了两个时间源SystemClock.elapsedRealtime() 是包含睡眠的墙钟时间SystemClock.uptimeMillis() 不包含深度睡眠。两个时间源在同一窗口内的增量差近似就是睡眠时间。代码逻辑就是在两次采样前后各记一对时间戳如果睡眠增量超过 50ms这个样本直接标记为 invalid。前台不可见的样本也别和前台可见的样本混在一起统计否则用户感知和指标之间的对应关系会越来越模糊。我现在做监控时前台可见和后台不可见会分成两个数据集报表里也分开展示。3.3 坑六括号、截断、PID 复用线程识别处处是坑线程级采集是很多人忽略的高危区。第一个高危点是 /proc/[pid]/stat 里的 comm 字段。真实项目里线程名经常是 “CpuThread-1” 这种没问题但也见过 “WorkQueue (cpu0)” 这种带括号的。如果整行直接按空格 split字段索引全部错位取出来的 utime 和 stime 完全是垃圾值。正确解析方式前面提过先找最后一个右括号括号后再按空格拆分。第二个高危点是线程名截断。内核里线程名的上限是 15 个字符超过的部分直接砍掉。比如 “VideoDecodeThread-12”从 /proc 里读出来是 “VideoDecodeT”。两个不同线程截断后可能一模一样所以线程数据必须同时记录 tid不能只看 name。做聚合分析时要用 tid 做 keyname 只能当展示字段。第三个高危点是 TID 复用。一个线程退出之后同一个 tid 可能被新线程复用。做长时监控尤其要注意不要只根据“目录存在”判断线程还活着。稳妥做法是解析 /proc/[tid]/stat 里的 starttime 字段线程身份 tid starttime两个都匹配才算同一个线程。这个坑在短时间内看不出问题但线上跑一两天后线程图里会出现幽灵数据一度让我以为是采集解析出了 bug。4. 坑七坑八按核统计的语义误区以及采集器自己就是噪声最后两个坑一个和“按核”的语义有关一个和采集器自身有关。这两个坑我在项目里都见过不止一次每次解释起来都要花不少口舌。4.1 坑七cpuN 行是全局累计分布不是“某个进程在哪个核上”有人会天真地想/proc/stat 里有 cpu0、cpu1那我按核统计某个进程的使用率不就行了吗这个想法我从严否定。 /proc/stat 的 cpuN 行含义是“第 N 颗 CPU 从开机到现在累计执行了多长时间”它无法区分这些时间到底是哪个进程贡献的。如果你想回答“进程 A 在 cpu2 上跑了多久”这一行给不了答案。反方向用 /proc/[pid]/stat 的第 39 字段 processor 判断线程当前在哪颗核上也很有局限性。这个字段只是瞬时快照。Android 的 EAS 调度器和负载均衡器会把线程搬来搬去你隔 50ms 抓一次每次抓到的核号基本在随机跳。我观察过一个 8 核设备上的测试线程1 秒内被迁移了三次以上用快照画“核心分布”完全不可信。要得到真正的核级归因只能用系统 trace 这类能记录调度的工具看调度切换事件。工程上建议放弃按核统计的思路除非你有明确的绑定核需求。如果只是想看某个线程的整体 CPU 消耗用前面说的进程/线程 tick 累计值就足够了。4.2 坑八采集线程自己就是负载Profile 结果被采集器污染第八个坑是测量者效应。我最早写的采集器开了三个线程一个读系统 /proc/stat一个遍历 App 的所有线程一个做数据整理上报。三个线程每 200ms 一起动一次结果监控开启后App 的 CPU 用量肉眼可见地涨了一截。为什么因为采集线程也是线程它也要被调度器调度也要消耗 CPU 时间。读 /proc 要打开文件内核要为每次 open 分配文件描述符解析字符串要做内存分配和 GC。这些开销最后都会落到进程自己的 CPU 统计里你以为在测量其实在自导自演。现在的处理方法是采集线程尽量做成单线程循环设置后台优先级避免在 UI 线程和渲染线程里做任何文件读取。遍历线程列表前先判断当前应用是否在前台不在前台就退化成低频采样减少无用功。更专业的做法是调用 native 层直接读文件避免 Java 层的字符串输出和临时对象分配。还有一个小技巧在采集模块里记录“采集线程自身消耗的 CPU 时间”上报数据时作为一个独立字段。这样即使没能完全消除自干扰至少能在分析时知道误差大概有多大。4.3 用 perfetto 做一次离线校准提到 perfetto它是 Android 上可用的系统 trace 工具能够从内核侧抓取调度和频率数据几乎不经过你的 App 代码。用它对拍自研采集模块是最直接的校准方式。具体做法是抓 3 到 5 秒的复现场景导出 trace 文件后在指标面板里看整机每个核的 CPU 使用率曲线。然后打开自己 SDK 的日志把同一时间段的数据画在同一张图里。先看形状两条曲线的波峰波谷是否一致再看量级自己算的整体使用率和 trace 里的整体使用率误差多大。误差在 5% 以内算健康超过 10% 就回去查是公式问题还是采样周期问题。校准不需要天天做但每次调整采集方案、换设备、换内核版本之后都值得跑一轮。测量工具本身必须先接受检验这是做性能工程的基本纪律。5. 现在我的采集模块长这样一份可复用的设计参考前面把 8 个坑说完接下来是我的落地实现。这套方案不一定适合所有项目但至少能帮你少踩大部分雷。5.1 核心设计决策先说决策表每一行都是踩坑之后定的。决策点我的选择理由常规采样周期1 秒稳定开销低短时追溯周期100ms持续 10 秒捕捉瞬时尖峰进程 CPU 口径procDelta / totalDelta × coreCount跨核数可比线程 CPU 口径线程 tick / 墙钟时间单线程上限 100%睡眠窗口丢弃并标记 invalid避免被平均频率加权有则用无则降级大小核可比性线程身份tid starttime防复用核心原则是宁可样本少一点也好过上报一批口径混乱、语义不明的数据。每次改方案都要重新过一遍这七个决策确认没有引入新的坑。5.2 核心代码骨架Java 解析 /proc 两件套系统总 tick 解析代码private long[] readSystemTicks() throws IOException { try (BufferedReader reader new BufferedReader(new FileReader(/proc/stat))) { String line; while ((line reader.readLine()) ! null) { if (!line.startsWith(cpu )) continue; String[] f line.split(\\s); long user Long.parseLong(f[1]); long nice Long.parseLong(f[2]); long system Long.parseLong(f[3]); long idle Long.parseLong(f[4]); long iowait f.length 5 ? Long.parseLong(f[5]) : 0; long irq f.length 6 ? Long.parseLong(f[6]) : 0; long softirq f.length 7 ? Long.parseLong(f[7]) : 0; long steal f.length 8 ? Long.parseLong(f[8]) : 0; long total user nice system idle iowait irq softirq steal; return new long[]{total - idle - iowait, total}; } } return null; }进程 tick 解析重点在括号定位private long readProcessTicks(int pid) throws IOException { String raw readFile(/proc/ pid /stat); int closeBracket raw.lastIndexOf()); if (closeBracket 0) return 0L; String[] fields raw.substring(closeBracket 1).trim().split(\\s); long utime Long.parseLong(fields[11]); long stime Long.parseLong(fields[12]); return utime stime; }字段索引 11 和 12 对应 utime 和 stime。为什么这么偏因为括号后的第一个字段是原来的第 3 个字段所以第 14 个字段落在下标 11。每次看代码都要在心里默算一遍建议在注释里写清楚免得后来人改错。5.3 输出字段统一的数据结构最后上报的数据固定成这些字段字段含义proc_cpu_pct进程单核归一化百分比thread_cpu_ms采样窗口内线程累计 CPU 毫秒sys_cpu_pct全局使用率core_count设备核心数freq_ratio当前频率 / 最大频率sleep_mark是否跨越睡眠窗口wall_ms墙钟时间字段名一旦定下来就不要改否则下游每个报表都要跟着改。原始 tick 值也可以同时上报一份方便事后换公式重算。我在做数据清洗层时最喜欢的就是这种结构不需要再猜字段是什么意思。6. 最后我怎么判断一组 CPU 数据能不能信最后分享一个判断数据可不可信的思路每一步都是教训换来的。第一道闸门是口径闸门。拿到任何 CPU 数据先问三个问题公式里有没有乘核心数iowait 算不算忙采样间隔是多少如果这三个问题答案不明确数据再漂亮也不能用来做结论。第二道闸门是有效性闸门。看样本是否跨过睡眠窗口是否混入已经退出的线程是否在后台极低频采样。无效样本宁可扔掉也不要留在地图上添乱。第三道闸门是交叉验证闸门。定期用系统级 trace 对拍曲线形状要对得上量级误差要在合理范围内。如果对不上第一反应应该是怀疑自己的采集代码而不是怀疑系统工具。我在实际项目里养成的一个习惯是每当看到“CPU 占用高”的告警不急着定位业务代码先打开采集日志看样本窗口和计算口径。很多性能问题查到最后其实是采集层自己造出来的假象。搞清楚这些坑之后CPU 数据才有可能真正指导优化决策。