CPU频率谁在管？Android调频机制与限频提频链路全解析

做性能优化的同学，肯定都经历过这种诡异场景：明明在跑重负载，CPU 频率却死活上不去，掉帧掉到怀疑人生；反过来，只是刷了个列表，频率却“唰”地冲到顶，电量和温度一起飙。上一篇文章把 CPU 频率的构成、DVFS 基线状态聊完了，这一篇我们盯住一个更本质的问题：频率到底是谁在管，谁有资格限频，谁有本事提频。

这不是一个简单答案能说清的事。现代 Android 系统里，CPU 频率不是某个模块独自决定的，而是被一套“多决策者、多优先级”的机制共同控制。搞懂这一层，再回头看跑分波动、游戏降频、后台异常耗电，思路会清晰很多。本文适合做系统性能调优、应用性能优化、游戏优化和功耗优化的人，哪怕你是刚入门想做性能分析，也建议先把这套理论框架搭起来。

1. 一次调频决策的完整链路：从负载信号到最终频率

很多人一上来就翻 sysfs 节点，看到scaling_cur_freq觉得频率是某个服务写出来的。这不对。频率是内核里一套 DVFS（动态电压频率调节）机制实时算出来的结果，sysfs 只是“结果展示窗口”。想搞清楚谁限频或提频，得先知道一次频率变化从哪来、到哪去。

1.1 频率不是“每个核”自己的事，而是“频率域”的事

先从最底层说起。大多数移动平台的 CPU 并不是每个核独立调频，而是分成几个频率域（frequency domain），也叫簇（cluster）。同一个域里的几个核，必须共享同一个频率，比如大核簇里 4 个核，在某一时刻统统运行在同一个频点。

这个设计是物理约束决定的：同一块电压域，共享同一组 PLL 和时钟树，强行分开调频，成本和复杂度都不可接受。所以我们在/sys/devices/system/cpu/cpu*/cpufreq/下看到一堆 cpuX 目录，其实同一簇的related_cpus是一样的，它们只是把同一个 policy 重复暴露出来而已。

调用scaling_cur_freq看到的只是当前频率的“快照”，真正维护这个值的是内核里的 CPUFreq 框架。它分三层：policy（频率域的属性，如最大/最小频率、可用频点表）、governor（决策者，负责算出目标频率）、driver（执行者，真正操作 PLL/时钟寄存器，把频率切过去）。

1.2 一次完整调频要经历哪些环节

我把一次调频的完整链路摊开，你可以对着 trace 一步步验证：

1. 触发：任务被唤醒、任务被加入运行队列、某个核的负载发生变化，调度器感知到运行需求变化。
2. 通知：内核通过cpufreq_update_util把最新的负载信息推给已注册的 governor。
3. 决策：governor 根据负载算法算出一个“目标频率”，这是它认为当前任务量下最合适的频点。
4. 钳制检查：目标频率不是直接生效的，它要经过 policy 的上限和下限过滤。上限可能被热管理或省电模式压低，下限可能被性能锁抬高。
5. 执行：driver 拿到过滤后的最终频率，切换时钟源和电压。频率切换本身有时间开销，通常需要几十到几百微秒，所以内核会用rate_limit限制切换频率，避免频繁来回跳。

从这里就能引出整个专题最重要的一句话：最终生效频率 = clamp(governor 目标频率, 下限, 上限)。谁限频，本质上是改了上限；谁提频，本质上是抬了下限或直接改了目标。

1.3 系统里至少有四类“指挥者”都在伸手管频率

把链路看明白后，我们要回答“谁”这个问题，答案至少有四类角色：

• governor：日常调频的“生产大队”，按负载实时决策，负责多数提频和降频；
• 调度器：它虽然不直接写频率，但负载数字是它喂给 governor 的，任务放到哪个核也由它决定，所以它间接掌控了提频的时机；
• 热管理模块：温度一高，直接压上限，属于一票否决；
• 用户态框架与厂商性能服务：应用/框架层通过性能锁、Boost 机制临时抬高下限或请求提频。

第四类里还包括电源策略，比如低电量模式、省电模式，本质是通过框架层接口改上限或切换 governor。搞清楚这四类角色之后，剩下的事就是看具体场景里“谁出手了”。我后面几节会把每一类的决策逻辑、触发条件和优先级依次展开。

2. 平时负责提频的 governor：schedutil 与 interactive 的算频逻辑

先说最常被点名背锅的 governor。安卓早年默认 interactive，现在新平台基本都切到 schedutil 或基于 schedutil 的定制版本。它的职责只有一个：根据负载把目标频率算出来。但它怎么算，直接决定了用户体验是“快、卡、还是挺省电”。

2.1 从 interactive 到 schedutil：响应速度的质变

interactive 时代，调频逻辑里有一个明显的“采样”味道：它周期性看 CPU 运行队列的使用率，然后查一张target_loads映射表，决定要不要升频或降频。问题在于采样有间隔，如果任务只突发跑 2 毫秒就结束，而采样周期在几毫秒到十几毫秒之间，调度器很可能睁眼闭眼就错过了这次负载高峰，等频率升上去任务早跑完了，用户感知就是“偶发顿一下”。

schedutil 的思路完全不同：它直接把 governor 的更新回调挂到调度器的负载更新路径上。任务唤醒、任务阻塞、运行队列状态变化，这些调度事件发生的瞬间，负载数字就会推给 schedutil，它当场决定要不要调频。所以它是事件驱动，不是轮询驱动，对突发的短任务响应更快。

这也是为什么很多平台把交互体验类优化建在 schedutil 之上：提频的“时机”比“幅度”更影响手感。频率到位慢 50 毫秒，用户就觉得滑不动；到位快 30 毫秒，哪怕频点没那么高，体感也顺。

2.2 负载是怎么算出来的：PELT 与 WALT 的分歧

schedutil 只是“读负载”，负载本身由调度器的统计框架生成。这里有个关键区别：同一段运行任务，用不同的负载统计算法，算出来的 util 曲线长得完全不一样。

• PELT（Per-Entity Load Tracking）：Linux 主线默认。它把每个调度实体的历史负载做指数衰减加权，近期负载权重高、远期权重低，得到一个平滑的 util 值。它的平滑是好是坏全看场景：对稳定负载非常准，但对“刚醒来的短 CPU 突发”反应偏慢，因为 util 需要几个周期爬坡。
• WALT（Window Assisted Load Tracking）：移动平台厂商经常引入。它按固定窗口（比如 20ms/32ms）统计 CPU 忙时间，只要最近一个窗口里任务跑得很满，next 窗口的 util 立刻很高。所以它对突发交互任务的提频速度远快于 PELT，代价是噪声也敏感，容易在“瞬间忙一下”时把频率拉得偏高。

你可以这样理解：PELT 像一个做长期平均的财务分析师，扭亏为盈的“盈”要几个季度才看得出趋势；WALT 更像是看流水台账的店长，这个星期生意好不好，一翻账本马上知道。

对做性能优化的人来说，这个差异的意义在于：如果你发现某个场景“任务明明在跑，频率却不升”，先别怪 governor 参数，大概率是你平台的负载统计用了 PELT 这种偏平滑的信号，导致突发负载被摊薄、提频滞后。反之，如果频率总是过度反应，那可能是 WALT 噪声触发，需要从窗口长度和 busy 阈值上找平衡。

2.3 不只是 governor 在算，调度器已经决定了“谁来跑”

还有个容易漏掉的因素——EAS（能耗感知调度）。在 big.LITTLE 架构里，调度器会估算任务放在大核还是小核更“划算”。它用的 capacity 值与频率强相关：大核低频时容量可能和小核中频差不多，调度器会根据历史运行情况决定要不要搬家。

这意味着你看到的频率曲线，不只是 governor 的功劳，而是“调度器搬运任务 → 某簇运行队列负载变化 → governor 看到新负载 → 调频”这个合力的结果。举例：一个任务先在小核跑，util 已经把小核频率推到顶了，但任务仍然跟不上，调度器把它迁到大核。此时大核的负载变量刚开始爬升，大核频率并不会瞬间顶满，中间会有几十毫秒的过渡。如果你只看大核频率，会觉得“提频太慢”；实际上调度器在换跑道，频率慢半拍是机制使然。

所以判断“谁提频”时，要把调度器视为一个幕后推手。调频问题的排查，大概率要同时打开 sched 和 cpu_frequency 的 trace，才能看清提频和核间迁移的前后因果关系。

3. 一票否决的限频力量：温度墙与电源策略的强制钳制

governor 再勤奋，也扛不住一句“我不允许”。这里说的就是 thermal 和电源策略。它俩改的不是 governor 的目标频率，而是 policy 的最大频率上限。目标频率 2.8GHz 不算数，上限被压到 1.4GHz，最终就只能跑 1.4GHz。

3.1 温度墙的工作流程：从传感器到冷却档位

设备里分布着很多温度传感器：CPU 表面、电池、主板、充电芯片等。每个传感器对应一个 thermal zone。内核的 thermal 框架会为每个 zone 设置 trip point（温度阈值），比如 70 度、80 度、90 度。温度越过某档，thermal governor（常见的是 step_wise）会提高对应 cooling device 的状态。

CPU 频率本来就是一种 cooling device。它的工作方式是把“冷却状态”映射到“最大允许频率”：状态 0 表示不限制，状态 1 把 max 压到某个频点，状态 2 压到更低的频点，逐级下降。这类设备在内核里注册后会出现在/sys/class/thermal/cooling_device*/cur_state，你看到 cur_state 大于 0，就已经有温控在压频率了。

实际案例很典型：某款设备跑大型游戏，前 20 分钟稳如老狗，20 分钟后帧率开始掉，一看scaling_cur_freq，大核从 2.8GHz 一路降到 2.0GHz、1.4GHz。这不是代码问题，是温度墙到了，thermal 在逐级切冷却档位。你断开充电、把机器放凉，或换个散热环境，频率自己就回来了。

这里有个细节值得注意：温控降频通常带回滞（hysteresis），即温度降到阈值以下后，不会马上恢复频率，而是要多降几度才回升一级。这是为了避免测温噪声导致频率反复横跳。所以“温度正常了但频率还没恢复”是正常现象，不要误判成 bug。

3.2 省电模式与低电量：框架层直接改上限

除了温控，另一只常伸出来的手是电源策略。Android 的省电模式（Battery Saver）、低电量保护逻辑，会在 framework 层通过 PowerManager 服务向内核写限制。常见动作有两种：把 governor 切到偏省电的模式；或者直接改scaling_max_freq。

你可以在省电模式开启前后对比一下：

adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

大多数平台上，开启省电模式后scaling_max_freq会明显降低，甚至可能被压到最高频的 60-70%。频率上限一降，governor 即使算出来 2.8GHz，也只能望洋兴叹。低电量场景更粗暴，电压稍微不稳，平台电源管理模块可能直接拉低允许频率，优先保稳定。

这类“限频”有一个共同特点：它改的是 max，不是目标频率。所以排查时别只盯 trace 里 governor 的决策，还要看 max 有没有被外部改写。sysfs 里的scaling_max_freq只是一个最终值，谁写的、什么时候写的，需要 dmesg、thermal 日志或框架层 log 才能往上追。我习惯把这层叫“一票否决者”，因为无论提频请求来自性能锁还是高负载，只要 max 被按住，一切都白搭。

4. 用户态伸向频率的手：性能锁、boost 与 Power HAL 的真实链路

governor 和 thermal 都在内核里干活，接下来要说的这层“人”在用户态，但能量一点不小。应用可能会发现某些平台有“性能模式开关”，跑分工具能瞬间把频率顶满，游戏还能申请到大核高频。这帮操作靠的正是性能锁和 boost 机制。

4.1 性能锁到底锁了什么：不是锁频点，是保底频率

先说概念。所谓的“锁频”，很多人以为是“把频率钉在 2.8GHz 不能动”。实际不是，它是给某个频率域的scaling_min_freq临时抬到某个值。比如游戏请求一个大核性能锁，把大核簇的 min 从 300MHz 提到 1.8GHz，持续 3 秒，到期后 min 恢复原值。

所以 lock 的本质是地板，不是天花板。它保证“频率至少不低于某档”，但 governor 完全可以在满足下限的基础上自由调高，比如负载上来后继续冲到 2.8GHz。反过来，如果温控把 max 压到了 1.5GHz，而你的锁要求 min 1.8GHz，最终结果也是 1.5GHz——地板再高也高不过天花板。

这个理解特别重要。很多人看到“锁频失败”，以为是锁没生效，其实是有别的制约者压着。判断标准很简单：看当前scaling_min_freq和scaling_max_freq，中间有没有有效区间。如果 min 已经抬上去了但频率没到，那隔在中间的就是 max 限制，往上查 thermal 或省电策略即可。

4.2 从应用请求到频率变化的完整链路

Android 里有一条完整的请求链路：

1. 应用或系统服务发起性能请求。比如前台应用切到游戏场景，framework 会收到窗口焦点变化或应用自己的性能 hint 请求。
2. PowerManagerService 收到请求，调用平台的 Power HAL（老版本是 HIDL 接口，新版本有 AIDL 的 setBoost/setMode），把“性能模式”“CPU 密集”“交互响应”这类 hint 传给厂商实现。
3. 厂商的 Power HAL 或独立的性能服务（常见实现里有 perfd 之类的守护进程）接到 hint，解析成具体的调频策略，通过内核接口写入某个频率域的 min/max，或者触发一次 boost 事件。
4. 内核收到后更新 policy 的下限/上限。如果 boost 是短时事件式，通常还会设置一个定时器，到期自动恢复。

这条链的每一步都有日志可查，但不同平台差异很大。比较通用的观察方法是抓一次 Perfetto trace，在 trace 里同时开sched、cpu_frequency和 Power HAL 相关的事件，对比频率爬升的时间点与 hint 下发时间点是否对齐。如果 hint 下去了频率没动，说明卡在 thermal/省电这一步；如果 hint 没下去，就要往框架层和权限层查。

4.3 隐式 boost：你没主动请求，但它偷偷提频了

除了显式性能锁，还有很多隐式提频。最常见的叫 input boost：用户点击屏幕，触摸事件驱动内核短暂提升 CPU 频率，以保证 UI 第一时间响应。你可能没写过任何性能代码，刷个微博都能看到频率瞬间冲高，这就是 input boost 干的。

其他隐式触发点包括：应用启动、Activity 切换、动画播放、充电场景等。某些平台还会在游戏启动时根据包名白名单自动进入高性能模式。这类提频的目的是“预判性能需求”，代价是短时间功耗上升。排查异常耗电时，如果发现频率偷偷顶格，记得查这些隐式 boost 的触发记录，它们往往能解释你“没在高负载却看到高频”的疑惑。

5. 定位“谁动了频率”：从状态检查到 trace 的排查清单

讲完理论，该给一套能落地的排查方法了。我平时处理频率异常，基本是“先生成状态快照，再抓 trace，最后顺藤摸瓜”三步走。这套流程对付绝大多数限频/提频问题都有效。

5.1 第一步：三分钟抓齐状态快照

别急着分析代码，先把下面的信息抓到同一个时间点：

# 当前频率、最大最小值、governor 名称 adb shell cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq adb shell cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq adb shell cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq adb shell cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor # 各频点停留时间统计，判断频率大致分布 adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state # 温度与冷却状态 adb shell cat /sys/class/thermal/thermal_zone0/temp adb shell cat /sys/class/thermal/cooling_device*/cur_state # 当前 CPU 占用率和进程线程状态 adb shell dumpsys cpuinfo

我排查时有个习惯：在抓取之前先点一下屏幕或跑 5 秒明显的负载，让目标行为发生一次，同时抓数据。否则频率可能正处在 idle 状态，你拿到一堆低频值，说明不了问题。

5.2 第二步：用 Perfetto 把频率和事件对齐

状态快照只能告诉你“当前是什么样”，没法告诉你“刚才发生了什么”。要还原现场，得上 trace。Perfetto 是目前最顺手的工具，抓取命令大致如下：

# 先写一个 trace 配置，开启 sched 和 power 相关事件 adb shell perfetto \ -c /data/local/tmp/trace_config.pbtx \ -o /data/local/tmp/trace.perfetto-trace # 抓完拉回来 adb pull /data/local/tmp/trace.perfetto-trace

trace 配置里至少要包含：

buffers: { size_kb: 131072 } data_sources: { config { name: "linux.ftrace" ftrace_config { ftrace_events: "power/cpu_frequency" ftrace_events: "sched/sched_switch" ftrace_events: "sched/sched_wakeup" ftrace_events: "thermal/thermal_temperature" ftrace_events: "cpufreq/cpufreq_request_frequency" } } }

拿到 trace 后，我在 Perfetto UI 里会同时看三行轨道：CPU Frequency 轨道、sched 轨道、task 名。问题一般一看就清楚：

• 频率曲线平稳掉下去，同时温度节点在爬升 → thermal 是最可能的限频者，再找 cooling device 状态确认；
• 任务醒了，频率却过了几十毫秒才升 → 基本是 governor 负载信号响应慢或 rate_limit 设置过大；
• 频率猛然升高，但 CPU 占用率并不高 → 疑似 input boost、性能锁等隐式/显式请求，去查 Power HAL 和锁服务日志。

5.3 弄个省事点的归因表

以下是我自己总结的快速归因表，常见现象和主要责任者基本能一一对上：

5.4 一次完整的排查记录

最后分享一个我印象比较深的问题。某跨平台系统 Demo 里有一个 native 线程跑密集计算，测试时发现大核频率只能到中档，比预期低不少。当时第一反应是 governor 参数问题，但抓了状态快照后，scaling_max_freq明显低于cpuinfo_max_freq，说明有人在压上限。继续查cooling_device*的 cur_state，果然不是 0，再一查 thermal zone 温度，两个节点已经逼近阈值。

整个过程从看到现象到定位出 thermal，不到十分钟。后来我们把测试环境从无散热底座换到冰垫上复测，频率立刻跑满，实锤就是温度墙。如果当时直接去调 governor 参数，不仅无用，还会误导后续优化方向。

这类案例特别多，所以我始终强调：查到scaling_cur_freq偏低只是开始，真正要找的是谁改了它的上限，谁控制了它的下限，谁驱动了它的目标。这三个问题对不上号，调参就是瞎调。

我在实际调这类问题时，最大的体会是：别急着把锅扣到 governor 头上，先花三分钟把scaling_max_freq、thermal state 和锁状态拉齐。多数时候“频率不正常”最后都能归到温度墙、电源模式、性能锁和负载算法这四类上游之一。数据摆到面前，“谁在管频率”往往一眼就认出来了。至于少数需要翻源码确认的，再顺着链路往上走，比凭空猜要快得多。