📚 课程目录第4章帧率抖动产生的根本原因分析（一）

4、帧率抖动产生的根本原因分析（一）：CPU瓶颈归纳总结

大家好啊，我是做手游性能优化出身的老工程师。帧率抖动这东西，后台排查的时候发现绝大多数案子都卡在CPU上。今天就专门讲讲CPU瓶颈到底有哪些表现，以及怎么快速定位。

我个人习惯把CPU瓶颈分成三大类：计算超载、调度失衡、缓存塌方。每类成因不同，但最终表现都一样——掉帧、卡顿、发热。下面我一个个拆开说。

4.1 计算超载——CPU累到跑不动

计算超载是最好理解的一类：主线程或者渲染线程在一帧内要做的事情太多，根本做不完。你有没有遇到过列表滑动时突然顿一下、然后瞬间又滑过去？那就是典型的主线程超载——掉了一帧，然后积压的任务在下一帧暴力补上。

我做过一个项目，一个帧内要更新300多个UI控件，每个控件都要做布局计算、阴影渲染。最后用Profile看，主线程每帧干了12ms的活儿，但16.67ms的节奏（60fps）里只剩4ms给渲染，怎么可能不抖？

具体原因常见的有以下几种：

Layout 过重：RelativeLayout 嵌套太深，每次测量都递归好几次。
Draw 指令过量：一次性提交大量Canvas绘图指令，或者过度绘制严重。
业务逻辑偷跑：在UI线程做了数据库查询、网络解析、I/O读写。
GC 频繁：每帧都触发垃圾回收，STW（Stop The World）时间一到直接断帧。

我曾经排查过一个案例：某界面滑动时平均帧率只有45fps，但CPU使用率才20%多，不合理啊！后来发现是主线程被一个for循环里的字符串拼接拖了后腿，每帧都在new StringBuilder。换成String.format后帧率直接冲到58fps。很多时候瓶颈不在CPU空闲，而在于你花了低效的钱。

4.2 调度失衡——CPU在，但核不够分

你以为CPU算力够就没事？太天真了。移动端的CPU是多核异构架构——大核（性能核）和小核（效率核）。系统调度器会根据负载情况把线程分配到大核或小核上。一旦多个高优先级的线程同时抢夺大核，或者你的渲染线程被分到了小核，帧率立马打折扣。

我个人习惯在定位帧率抖动时，先看CPU核心负载分布。如果发现渲染线程被挤到了小核上，但大核却在跑一些不紧急的后台任务，那八成是调度失衡。

注意：调度问题在低端机上尤其突出。很多中低端机只有2-4个大核，一旦同时加载网络图片、解码视频、跑UI线程，大核瞬间就被吃满。渲染线程只能在小核上抢时间，帧率直接崩到30fps以下。

我总结了几种典型的调度失衡场景：

场景	表现	排查要点
后台任务抢核	后台下载、日志写入与UI线程抢大核	看CPU各核利用率曲线，大核跑到80%+但帧率跌
线程优先级翻转	低优先级线程持有锁，高优先级线程阻塞等待	Systrace中看锁标记，找长时间waiting的线程
渲染线程被迁移	帧间隔突然变长，且核ID发生变化	绑定CPU亲和性，或者通过线程池固定核

小技巧：在Android上可以用setThreadAffinityMask()把渲染线程绑到大核上。不过要注意——不同厂商的核编号不一样，得动态获取。我记得在联发科平台上就踩过坑，绑错了核导致发热更严重。

4.3 缓存塌方——CPU空转等数据

缓存问题比较隐蔽。你从CPU利用率上看，核心可能只跑了40%，但帧率就是上不去。为什么？因为CPU大部分时间都在等内存数据。L1 Cache命中一次只要1ns，但L2 miss之后去RAM读数据就要100ns。一个帧里如果多几次L3 miss，累积时间就非常可观。

我印象最深的是处理一个列表快速滑动的卡顿。用PerfDog看Jank很高，CPU负载却不高。后来用硬件计数器一测，发现L2 cache miss率从5%飙到了35%。问题出在列表每一项的图片解码是线程池跑的，线程之间不停地切换上下文，把缓存打散了。

缓存塌方常见原因：

数据结构不连续：用链表遍历1000个节点，每一步都跳内存地址。
多线程交替访问同一缓存行：两个线程同时读写相邻变量，触发缓存行伪共享（False Sharing）。
批量处理突然变串行：原本向量化的代码因为数据依赖被打散，导致CPU流水线停滞。

// 伪共享经典例子：两个线程写不同字段，但它们在同一个缓存行
struct MyData {
    volatile int a;   // 线程1写
    volatile int b;   // 线程2写
};
// 编译器可能把它们放在同一缓存行（64字节），导致互相失效
// 解决：通过padding对齐到64字节边界
struct MyDataAligned {
    volatile int a;
    char pad1[60];    // 填充到64字节
    volatile int b;
    char pad2[60];
};

实际项目教训：我曾经做过一个帧动画更新模块，每帧要更新几十个顶点的坐标。用std::vector存顶点数据，但在渲染循环里反复用push_back插入顶点。结果每次插入都可能触发realloc，导致整个vector拷贝，缓存全部失效。换成std::array预分配后，帧率提升了12fps。你看，缓存友好度直接决定了CPU能不能吃饱。

4.4 快速定位CPU瓶颈的“三板斧”

说了这么多，实际操作起来怎么快速定位？我总结了一个三步走的思路：

第一步：用系统工具看CPU总负载
用PerfDog/Instruments/系统自带profile看CPU整体使用率、各核频率、瞬态峰值。如果CPU使用率忽高忽低，或峰值超过80%，先怀疑计算超载。
第二步：看线程级调度
用Systrace（Android）或Xcode Time Profiler看帧边界内的线程运行状态。如果渲染线程频繁被挂起、同帧内多次线程切换，优先排查调度失衡。
第三步：看微架构指标
如果前两步没问题，但帧率还是抖，那就得用硬件计数器（ARM PMU/Intel PEBS）看cache miss、branch mispredict、TLB miss。这些指标能直接告诉我们CPU在哪里“空转”。

我个人习惯在代码里埋一个轻量级的帧耗时打点。每帧记录主线程、渲染线程的耗时区间。一旦发现某一帧的耗时突然>16ms，立即把前后的CPU调度日志转储出来。这个“现场快照”比事后分析管用十倍。

4.5 避坑指南——我曾经掉过的坑

坑一：只看CPU总利用率不看细分。 总利用率50%不代表没事，可能主线程已经爆了而其他核闲着。一定要按线程/核分开看。
坑二：在大核上盲跑所有线程。 渲染线程绑大核是对的，但不要把所有子线程都绑大核。否则大核过热降频，帧率反而更低。建议只绑关键的高优线程。
坑三：忽视编译器优化对缓存的影响。 曾经我想优化一个循环，手动展开了四次迭代，结果因为增加代码体积导致指令缓存miss暴增。不该手动优化的地方交给编译器，自己别瞎动。
坑四：在低端机上用复杂的数据结构。 std::map在高端机上存取延时可以忽略，但在发哥P60上，每次插入都触发cache miss。换成静态数组+二分查找后，帧率从23飙到40。