后台调度：看不见的帧率杀手

做性能分析这么多年，后台调度一直是最容易翻车的地方。你想想看，前台动画明明优化得不错，流畅度数据也漂亮，可用户一开后台App回来，帧率直接掉到20多。怎么回事？大概率就是后台调度在搞鬼。

路径一：线程调度——优先级倒挂与抢占延迟

Android渲染线程通常跑在boost或fifo:120这类高优先级上。但后台任务如果也用了高优先级（比如某些第三方SDK），就会把渲染线程踢出CPU——这就是经典的“优先级倒挂”。

我曾经接手过一个直播App的卡顿问题。用户刷礼物时动画卡得不行，Perfetto一看，后台有个推送服务的线程把渲染线程打断了8ms。嗯，8ms看起来不多，但60fps的帧间隔也就16.67ms，直接吃掉一半。解决方法是把第三方SDK的优先级降到background组。

在Perfetto里怎么抓？看sched切片的comm和prio字段就行。我习惯先加一个sched/switch的filter，然后按时间轴看线程切换间隔。

路径二：CPU频率——系统没有你想的那么快

现代SoC的CPU频率由内核调度器动态调节。后台任务一拥而上，如果调度器误判负载，会把核心频率降到最低档。渲染线程瞬间变慢。

你想想看，一个渲染线程就算优先级再高，如果CPU只有最低频率，一个draw call就能跑出2ms。正常情况是0.5ms。翻4倍。

我在调试一个短视频App的列表滑动卡顿时，发现后台正在下载HDR视频，CPU频率被限制到了1.2GHz。Perfetto的cpu_frequency追踪一看就明白了。解决方案是给渲染线程绑定到一个独立的小核组，并且通过dds（Dynamic TripleScheduling）锁频。

路径三：负载——后台任务抢脏了CPU时间片

负载问题最容易诊断但也最难根治。后台有大量短时任务（比如日志刷写、数据库写入），虽然每个任务只跑1~2ms，但架不住数量多。渲染线程在队列里排队，实际拿到CPU的时间片被切得稀碎。

我之前遇到一个典型案例：某个新闻App，用户看视频时后台定时刷新广告位。Perfetto里看到io.workqueue和binder_transaction频发，渲染线程的sleeping状态占比从5%飙升到80%。说白了，CPU被后台I/O吃掉了。

这时候看什么？看thread_state里的R（可运行）和S（睡眠）比例。如果渲染线程长期是R但没拿到CPU，说明系统调度器负载太高。

实战分析：用Perfetto一次性定位三道关口

我建议你按照这个路径来分析：

1. 先加sched/sched_switch + power/cpu_frequency + cpu/load三个跟踪
2. 在Perfetto UI里找到渲染线程（通常是RenderThread或Chrome_ChildThread）
3. 看它的状态片段：绿色多（Running）说明正常；橙色多（Runnable）说明调度延迟；红色多（Sleeping）说明在等锁或等I/O
4. 再叠加CPU频率曲线，看橙色区域是否对应频率低谷
5. 最后看系统负载指标（cpu_load），确认是后台任务导致

常见误区与避坑

误区一：只有后台高负载会造成抖动。 其实后台低负载但高频率（比如每个后台任务都跑完再休眠）也会拉高总功耗，触发温控降频。我遇到过蓝牙耳机在后台持续发送心跳包，把CPU频率锁死在中档。

误区二：线程优先级设为最高就万事大吉。 我曾经在一个游戏App里把渲染线程设成SCHED_FIFO，结果后台一个NAnti-task也用了FIFO，两者互抢。建议只对关键渲染线程用FIFO，其他最高给到RR。

知识结构速览

影响路径	Perfetto关键字段	典型表现	排查要点
线程调度	sched/switch.prio, sched/switch.next_prio	渲染线程出现>3ms的Runnable状态	检查抢占线程的优先级是否过高
CPU频率	power/cpu_frequency.freq	帧率低时频率低于1.5GHz	用SQL聚合频率分布，确认降频原因
系统负载	cpu/load.load_avg, sched/switch.comm	渲染线程Running时长占比<30%	按进程统计上下文切换次数，定位后台任务

这张图把后台调度影响帧率的完整链条画出来了。从左到右：后台任务（红）进入调度器（蓝），调度器决策后产生三个中间影响（橙），最终汇聚到渲染抖动（紫）。最下面就是我们的武器——Perfetto（绿）。