写高通的温控几乎每个做整机方案的人都绕不开thermal-engine.conf。产品发烫降频、跑分掉链子、充电被限流、玩游戏掉大核最后定位来定位去八成都是这份配置和产品散热结构不匹配。它是高通 thermal-engine 守护进程的策略文件一行行定义着“SoC 温度到了多少度、系统该做什么”从虚拟传感器怎么换算温度到 CPU 频率怎么一级级往下压全都在这里。这篇文章不打算复刻官方文档而是把我这些年调高通平台的实操经验直接摊开先讲清楚配置文件整体架构再重点拆解虚拟传感器和 CPU 频率控制这两块硬骨头最后附上部署、验证和排障的完整流程。无论你是做手机、平板、随身 Wi-Fi 还是各种盒子类产品只要底层是高通平台这份指南都能帮你少踩几个坑。1. 初识高通 thermal-engine温控配置文件到底是做什么的1.1 从“降频”说起thermal-engine 服务的工作链路先明确一个基本概念thermal-engine.conf不是内核里那些 device tree 节点也不是上层 App 的 JSON它是高通 thermal-engine 守护进程专用的一份文本配置。这个 daemon 早期叫thermal-engine在部分平台上还能看到thermald相关的历史和兼容层整体思路是一样的读取 SoC 上的温度传感器按照配置里定义的阈值表和动作表去操作系统里的各类冷却设备最常见的就是限制 CPU 最高频率。用生活里的例子类比它就是一台中央空调的温控器。温度传感器像是贴在房间各处的温度计thermal-engine.conf则是你写在控制器里的逻辑室温到 28 度开低风量到 32 度开中档超过 36 度直接强力制冷。等高通 SoC 跑到 70 摄氏度、80 摄氏度、90 摄氏度这条链路就会依次把大核从 2.84GHz 拉到 2.4GHz、再拉到 1.7GHz从而把温度控制在设定范围内。这里有个很多人没搞清楚的历史背景早期 Linux 内核里有msm-thermal驱动温控策略在内核态实现后来高通则把它逐渐迁移到用户态目的就是让策略变得“可配置、可动态调整”。厂家不需要为了改一个降温阈值就重新编译内核直接改配置然后重启服务即可。这也是thermal-engine.conf如此重要的原因——它实际上成了温控策略的“可编程中枢”。1.2 配置文件的结构段落、键值对与动作表打开一份典型的高通thermal-engine.conf你看到的不是 XML也不是 JSON而是一种类似 C 语言风格的文本结构。大括号用来划分逻辑块每行都是“参数名 值;”的形式分号不能丢。整体上你会反复见到下面几个段落sampling控制采样周期sensor定义传感器和阈值动作virtual-sensor定义虚拟传感器algorithm定义温度补偿算法monitor则把传感器、算法和动作绑定起来。一个简化但结构完整的示例大致长这样sensor { name tsens_tz_sensor0; type tsens; tsens-id 0; thresholds 75000 85000 95000; actions { action { type cpu; id 4; value 1728000; level 1; } action { type cpu; id 4; value 1400000; level 2; } } } sampling { period 1000; }这个片段的意思是监控名为tsens_tz_sensor0的 TSENS 温度点当温度超过 75 摄氏度时把 CPU 4 号核最高频率限制到 1.728GHz超过 85 摄氏度时限制到 1.4GHz超过 95 摄氏度时再执行 level 3 对应的动作。这里的温度单位是毫摄氏度也就是75000代表 75.000 摄氏度。频率单位是赫兹1728000就是 1.728GHz。新手最容易在这里摔跟头把 75 当成 75 摄氏度填进去结果从开机起系统就拼命降频。1.3 为什么做整机方案必须动这份配置也许你会问原厂自带配置不是能用吗对不同产品来说真不一定“能用得好”。手机、平板、随身 Wi-Fi、智能音箱、车载盒子它们的结构散热能力天差地别。原厂配置往往基于公版参考设计调校而你的产品可能主板面积更小、没有 VC 均热板、外壳是塑料而不是金属这些都会导致同样功耗下温度更高或反过来热阻很小但 CPU 撞温度墙的时机更早。举个实际例子某款基于骁龙平台的便携随身 Wi-Fi参考设计里配置的 CPU 降频阈值是 85 摄氏度但产品塞进密闭外壳后无风扇环境下跑业务负载温度很容易冲到 90 摄氏度以上。如果不改配置设备就会在“高温降频-网速骤降-温度回落-恢复高频”之间反复横跳用户感知就是网络极不稳定。这种情况下调整温控阈值、增加虚拟传感器来综合判断整机温度往往比更换散热硬件更直接、更省钱。2. 虚拟传感器Virtual Sensor从物理读点到算法补点2.1 为什么需要虚拟传感器物理传感器不够用先记住一个结论虚拟传感器不是真实存在的硬件读点而是通过一个或多个物理传感器读点按特定算法计算出来的“合成温度”。你可能会疑惑SoC 上不是已经有那么多 TSENS 点了吗为什么还要再去算一个虚拟温度这就要回到实际硬件设计上。第一物理传感器位置有限。电池包内部、外壳表面、Wi-Fi/蓝牙 PA 附近、摄像头模组区域这些地方通常没有温度传感器或者只有一颗离得比较近的间接传感器。我们要控制这些区域的温度就必须用现有读点去估算。第二单点读数噪声大、容易误触发。某个 TSENS 点可能因为瞬时负载出现尖峰如果直接用这个点做 CPU 降频依据频率会跟着抖动用户体验非常差。用一个虚拟传感器把附近多个读点取平均值或最大值可以平滑噪声。第三有些产品需要在同一个读点上叠加不同算法比如既想用它做 CPU 控温又想用它估算电池温度这也可以靠多个虚拟传感器来实现。所以虚拟传感器的本质是用算法去“补”硬件上测不到、测不准的温度。你可以把它理解成通过几个房间的温度计推测洗手间地板温度是多少——虽然没有直接测量但基于经验和相关性这个推断值足够用来做控制。2.2 virtual-sensor 字段逐项拆解语法与选型在配置里虚拟传感器用virtual-sensor段落来定义。它的基本语法结构如下virtual-sensor { name vts_board_temp; sensor-list tsens_tz_sensor0 tsens_tz_sensor1 tsens_tz_sensor2; math-type max; coefficient 1 1 1; offset 0; share-sensor 1; }逐项来解释name虚拟传感器名称必须全局唯一。后面各种sensor段落或monitor段落引用它的时候就是靠这个名字。sensor-list列出参与计算的传感器读点名称。这些读点必须是配置里已定义的传感器也可以是另一个虚拟传感器也就是说虚拟传感器可以“套娃”。math-type计算方式常见的有average、max、min、diff、sum。average是取平均值适合做平滑max是取最大值适合判断热点min取最小值一般用于安全性判断sum用得少适合做总功耗相关的估算。coefficient每个输入读点的权重系数。数字个数必须和sensor-list里的传感器数量一致。比如三路都填 1就是等权平均填1 2 1中间那路权重更高。offset最终结果加上的固定偏移量单位同样是毫摄氏度。有些场景下知道 A 点比 B 点高 10 度就可以直接加10000。share-sensor一个标记位表示这个虚拟传感器可以被多个监控线程共享读取。如果多个monitor同时引用同一个虚拟传感器这个字段能避免重复采样节省开销。需要留意的是不同高通平台的配置字段名可能略有差异。老平台可能用sensor-list新平台可能是sensorsmath-type的取值范围也会增加。所以我的习惯是拿到一个新平台的配置先把原厂自带配置里已有的virtual-sensor段全部读一遍照着它的写法扩展这比硬套旧版语法安全得多。2.3 虚拟传感器实战案例多读点取最大值上报光讲字段还是有点干我分享一个实际调过的案例。当时是一款采用骁龙平台的便携游戏设备主板上除了 SoC还有一颗电源管理芯片 PMIC以及一个靠近后盖天线的温敏电阻。原厂配置里只针对 SoC 的 TSENS 做控温但用户反馈“打游戏时后盖左上角烫手但系统还没降频”。排查后发现后盖温度主要来自两个热源SoC 高负载带来的整机热积蓄以及 Wi-Fi/PA 区域的局部发热。单纯看 TSENS 并不能很好覆盖 PA 区域。于是我用三颗读点构造了一个虚拟传感器virtual-sensor { name vts_back_cover_est; sensor-list tsens_tz_sensor0 pmic_tsens thermistor_back; math-type max; coefficient 1 1 1; offset 5000; }思路是取 SoC、PMIC 和后盖热敏电阻三者的最大值再加 5 摄氏度的偏移量用来近似“用户摸到的表面温度”。然后把这个虚拟传感器挂在 CPU 控温的monitor上这样只要任意一个热源接近阈值系统就会提前介入。这里关键的一个决策是为什么用max而不是average因为用户感知最强烈的永远是“最热点”。如果取平均值局部高温往往被其他低温读点稀释等到平均值触发阈值时局部早就烫得没法摸了。反过来如果你是想做系统整体负荷管理、不希望某一颗传感器尖峰误导策略那average或带权重的average更合适。选型没有绝对对错关键是你先想清楚这个虚拟温度代表什么物理量。3. CPU 频率控制从温区阈值到调频动作的完整链路3.1 sensor 动作表thresholds 与 actions 的对应关系CPU 频率控制的核心其实全部浓缩在sensor段落里的thresholds和actions中。thresholds定义一组温度阈值actions定义一组动作两者通过level字段关联起来。温度超过第几个阈值就执行对应level的动作。我用一个稍微完整一点的示例来说明sensor { name cpu_temp; type tsens; tsens-id 0; thresholds 70000 80000 90000 100000; actions { action { type cpu; id 0; value 2016000; level 1; } action { type cpu; id 0; value 1740000; level 2; } action { type cpu; id 0; value 1400000; level 3; } action { type cpu; id 0; value 902000; level 4; } } }这段配置的逻辑非常直白温度超过 70 摄氏度时把 CPU0 最高频率限制到 2.016GHz超过 80 摄氏度限制到 1.74GHz超过 90 摄氏度限制到 1.4GHz超过 100 摄氏度限制到 902MHz。这就是常说的“逐级降频”。action里的type还可以有很多变化。除了cpu还有cluster、gpu、devfreq、battery、cpr等。cpu一般是针对单独 CPU 核心cluster是针对整个 CPU 簇gpu则控制 GPU 最高频率。id字段要填目标对象的编号但不同平台编号规则不一样有些平台从 0 开始有些分大小核可能需要按 cluster 区分写错直接不生效。我在实际项目里踩过一个大坑某平台上大小核的 CPU 编号不是连续的大核是 4-7小核是 0-3配置里如果只写了id 0结果就是大核温度飙到 100 摄氏度了小核被限制但大核纹丝不动。所以拿到新平台第一件事就是把/sys/devices/system/cpu/下的 possible 和 online 节点看一遍确认好枚举顺序再写id。3.2 algorithm 算法线性补偿与 PID 控温如果配置里只有thresholds和actions那这个温控就是纯离散的“阶梯开关”。温度一超过阈值频率直接跳变用户体验往往就是“一下卡一下不卡”。为了改善这个问题高通引入了algorithm段落用算法去动态计算目标频率而不是简单查表。最常见的两种算法是线性算法和 PID 算法。线性算法的思路是在某个温度区间内温度的提升对应频率的线性下降同时通过margin参数设置余量避免贴着阈值反复横跳。一个例子algorithm { name linear_algo; linear { margin 5000; limit { temp 115000; value 1550000; } } }margin 5000表示保留 5 摄氏度的余量也就是当温度接近 115 摄氏度但还没到的时候就开始线性降低频率最终频率被限制在 1.55GHz 以下。这样整个降频过程是平滑过渡的而不是突然从 2.8GHz 掉到 1.5GHz。PID 算法则更“聪明”一点它把当前温度、温度变化趋势、累计误差都纳入计算能够更提前地抑制温度爬升。配置大致长这样algorithm { name pid_algo; pid { kp 10; ki 2; kd 0; output-limit 800000; } }其中kp是比例系数决定“温度高了立刻压多少频率”ki是积分系数决定“长期偏热时持续压多少”kd是微分系数决定“温度上升太快时提前压多少”。实际调起来kd往往从 0 起步先调kp再慢慢加ki。参数太激进会导致频率震荡参数太保守又会让温度持续爬升。我的建议是如果没有足够的时间和测试设备先从linear入手稳定性好、行为可预测等整套温控跑顺了再针对特定场景引入 PID。不要一上来就追求“智能控温”离散阈值表已经能解决 80% 的问题。3.3 调频策略选型逐级降频、直接限频与优先关核在actions的具体设计上常见的策略有三种。第一种就是上面例子里的逐级降频温度越高频率越低阶梯比较多用户基本无感知适合大多数日常产品。第二种是直接限频温度一旦越过某个阈值就一步到位限制到很低频率适合对表面温度有严格要求的场景比如手持设备宁可性能大幅下降也要保证不烫手。第三种是关核配置里可以写type cpu加特殊 value或者使用其他冷却手段温度极高时直接 offlining 掉一部分核心这是最后的保护手段一般只用于临近硬件极限时。三种策略怎么选核心看两点一是产品的用户场景二是散热设计的余量。像游戏手机散热堆料比较足逐级降频可以多留一些性能像轻薄本、随身 Wi-Fi 这种无风扇设备散热余量小可能需要在较低温度就采取更果断的限频动作。还要注意monitor段和sampling段的配合。monitor决定哪个算法去监控哪个传感器sampling决定多长时间采样一次。周期太短会让系统频繁读数、耗电增加周期太长又会让温控反应迟钝。一般平台原厂给 1000ms 甚至更短具体还是根据你的产品热时间常数来定。热质量大的产品周期可以放宽热质量小的则要缩短。3.4 与系统其他温控机制的配合别以为改完thermal-engine.conf就万事大吉了。系统里还同时跑着内核 thermal framework、cpufreq governor、GPU 的 devfreq 调频以及高通部分平台上的自适应策略模块比如高通的 AIS、各种 AI 调频思路在不同平台上有不同实现。这些机制和 thermal-engine 之间的关系说白了就是“多个管理员同时管一个房间的空调”策略之间可能打架。最常见的冲突是 cpufreq 的scaling_max_freq被其他模块改了。比如某个省电策略或 Game 模式的调度框架直接把最高频率限制到了 1.5GHz那即使thermal-engine.conf里把阈值设得很宽松CPU 也冲不上去。反过来如果你的温控配置把频率压到很低但内核 thermal framework 又在另一个温度点调整冷却设备两者叠加可能造成降频幅度过大。另外高通新平台上已经开始加入更多“自适应”的思路。比如系统会学习用户的使用模式动态调整温控策略这时候thermal-engine.conf更多是一个底层的兜底策略而不是唯一策略源。我遇到很多工程师查了半天配置最后发现是另一个策略模块抢先改了scaling_max_freq。所以排查温控问题时第一步先看当前实际频率被谁改了再看配置文件顺序不要反。4. 实操从零配置一套可落地的温控策略4.1 第一步确认平台传感器与 sysfs 节点拿到一个不熟悉的高通平台不要急着改配置先花一小时把硬件读点摸清楚。通过 ADB 或串口进入系统查看/sys/class/thermal/目录下所有热区命令大致是这样ls /sys/class/thermal/ cat /sys/class/thermal/thermal_zone*/type cat /sys/class/thermal/thermal_zone*/temptype会告诉我们这个热区是什么传感器比如tsens_tz_sensor0、pmic-die、battery等。temp返回的是当前温度注意多数平台单位是毫摄氏度需要除以 1000 才是摄氏度。用这个方法可以快速确认thermal-engine.conf里引用的传感器名称是否和 sysfs 节点对得上。还有一个很实用的路径是/sys/kernel/debug/thermal/这个目录下能看到传感器更详细信息比如精度和报警状态但需要 root 权限。我自己在开发阶段一般会先跑一遍重负载同时用脚本循环打印所有热区的温度变化这样能直观看出哪些传感器对负载敏感、哪些基本上是摆设后面写虚拟传感器时心里才有底。4.2 第二步编写配置文件与部署传感器名称确认后就可以开始编写配置了。我建议不要直接改原厂文件而是先复制一份做备份再在副本上改。以/vendor/etc/thermal-engine.conf为例先把它导出到电脑上用支持语法高亮的编辑器打开注意关闭自动格式化和 Unicode 智能引号避免引入不可见字符。一个最小可用的配置至少要有sampling、sensor和monitor几块。从最简单开始验证不要一上来就堆一堆虚拟传感器和 PID 算法。比如先做这样一件事把某个传感器挂到一个 CPU 核心上设一个远低于实际温度的阈值比如 40 摄氏度看系统会不会正确降频。如果这个链路调通了再逐步把阈值改成真实值把虚拟传感器加进来。部署方式上多数平台的 thermal-engine 服务由 init 启动配置文件路径是写死的。你可以把修改后的文件 push 到原位置然后重启 thermal-engine 服务或者干脆重启整机。如果服务支持自定义路径启动也可以用调试方式先加载临时配置验证但不同平台差异较大最稳妥的做法还是“备份原文件、替换新文件、重启验证、随时回滚”。4.3 第三步验证降频曲线与稳定性配置部署之后一定要做完整验证不能只看一两个瞬间的频率值。我会一边跑压力测试一边采样 CPU 温度、各核频率、GPU 频率和整机电流画成曲线看整体趋势。采样命令比较简单while true; do cat /sys/class/thermal/thermal_zone0/temp cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq sleep 1 done重点关注三件事第一温度是否被控制在预期目标内第二降频动作是否平稳有没有频繁跳变第三降温后的恢复是否合理会不会因为频繁恢复导致温度来回震荡。如果发现降频过于突兀优先调margin和algorithm如果发现温度压不住先确认是不是还漏掉了某个发热大户比如 GPU 或 modem 也要纳入配置。另一个很容易被忽略的点是低温场景。我见过有人把阈值调得非常高结果冬天户外使用时结构件强度没问题但电池低温下内阻增大充电电流受限用户误以为是温控配置引起的。所以验证时要把高低温环境都覆盖到有条件就上恒温箱至少也要在室温和空调房之外找个相对热的环境跑一遍。5. 常见问题与排查实录5.1 配置不生效从日志到权限逐层定位配置不生效是大家问得最多的问题。如果你修改了配置文件重启后观察频率完全没有变化先把下面这几件事逐个排查。一是配置文件路径不对。高通平台版本不同配置文件可能放在/system/etc/、/vendor/etc/、/vendor/etc/thermal/等位置有些平台还会按 SKU 加载不同文件。你先让系统打印出 thermal-engine 启动时加载的路径再看自己改的是不是那份。二是 SELinux 权限问题。即便你通过 root 把文件 push 进去了文件的安全上下文如果不匹配daemon 也可能无法读取或直接忽略。修改后执行一下restorecon让文件恢复到这个分区应有的上下文常常能解决问题。三是服务根本没重启或者改完配置后 daemon 解析失败崩溃了。通过logcat或dmesg查看 thermal-engine 的日志如果有语法解析错误会直接告诉你哪一行有问题。最常见的就是少了分号、多了括号或者sensor-list引用了不存在的传感器名称。我个人的排查习惯是改完配置后先手动在命令行尝试解析一遍如果平台提供了解析工具或命令的话没有工具就通过日志确认 daemon 是否正常加载确认加载成功后再去验证行为。不要每次改完配置都盲目重启整机那样一轮测试就要好几分钟。5.2 温控过激或过钝参数调整方向配置能生效但实际表现不理想这类问题更考验调参功力。遇到“没怎么玩游戏就疯狂降频”通常是阈值太低、margin太保守或者虚拟传感器选取的读点太敏感。可以先看日志里触发降频时温度是多少再对照配置看是哪个传感器先越界。如果是一个局部热点引发的误判可以考虑改用average类型虚拟传感器而不是直接堆高阈值。遇到“已经烫手了还不降频”问题可能出在几个方向。一是传感器选错了监控的温度点和用户感知的热点不是同一个物理位置二是采样周期太长温度冲到很高之后才反应过来三是被其他模块抢先限制了散热能力比如风扇策略、充电策略或者 GPU 调频机制。记住一个朴素原则温度只是结果功率才是原因。温控做得粗糙通常是对“谁在发热、从哪里扩散”理解不够。调整参数时一次只改一个变量。比如我先只调阈值观察曲线再决定要不要动margin先把 CPU 控温调稳再引入虚拟传感器先把离散阈值表调到能接受再考虑 PID。科研式地同时改五个参数出了问题根本不知道是哪个改坏的。5.3 踩坑经验与独家建议这些年的实战里有一些经验是文档里不会写的我挑几个最实用的分享给有同样困扰的朋友。第一备份永远是第一位的。thermal-engine.conf这种配置文件一个符号错了就可能让 daemon 崩溃而崩溃后的系统往往不会自动加载默认策略甚至可能出现“完全不控温”的危险状态。所以我每次动手前都会把原文件复制到/data/local/tmp/或者电脑上确认无误后再覆盖。第二不同平台之间的配置文件不能直接互拷。高通的平台版本迭代很快新老平台对字段的支持不一样。老平台里能用的thresholds写法新平台可能已经改名新平台引入的algorithm字段老平台直接忽略。入职新项目或者接手新平台时先用原厂配置跑一遍全流程摸清语法再定制别赌自己的记忆。第三虚拟传感器和algorithm配合时注意引用方向不能循环。配置里sensor引用虚拟传感器虚拟传感器又引用了另一个虚拟传感器如果形成 A 引用 B、B 引用 A 的环daemon 解析时可能直接报错或死循环。检查方法是顺着每个sensor-list往下追一遍确认没有闭环。第四接近硬件极限的高阈值要慎重。把 CPU 阈值从 85 摄氏度调到 100 摄氏度看起来只是数字变化但芯片长期高温下寿命、漏电流、稳定性都会受影响。我做温控策略时有一条铁律接近原厂硬件规格上限的动作必须经过可靠性和寿命测试而不是拍脑袋。最后再提一个小技巧配置里每个virtual-sensor和sensor都用有业务语义的名字比如vts_battery_surface、tsens_cpu_max不要用vts_0、vts_1这种没有信息量的命名。你一个人调试时怎么命名都行但项目换人维护、或者你自己半年后再回来看这份配置时一个好名字能省下大量反推注释的时间。温控策略这种“改起来一时爽、排起查火葬场”的模块可读性就是生产力。
高通 thermal-engine.conf 温控配置实战：虚拟传感器与CPU频率控制
写高通的温控几乎每个做整机方案的人都绕不开thermal-engine.conf。产品发烫降频、跑分掉链子、充电被限流、玩游戏掉大核最后定位来定位去八成都是这份配置和产品散热结构不匹配。它是高通 thermal-engine 守护进程的策略文件一行行定义着“SoC 温度到了多少度、系统该做什么”从虚拟传感器怎么换算温度到 CPU 频率怎么一级级往下压全都在这里。这篇文章不打算复刻官方文档而是把我这些年调高通平台的实操经验直接摊开先讲清楚配置文件整体架构再重点拆解虚拟传感器和 CPU 频率控制这两块硬骨头最后附上部署、验证和排障的完整流程。无论你是做手机、平板、随身 Wi-Fi 还是各种盒子类产品只要底层是高通平台这份指南都能帮你少踩几个坑。1. 初识高通 thermal-engine温控配置文件到底是做什么的1.1 从“降频”说起thermal-engine 服务的工作链路先明确一个基本概念thermal-engine.conf不是内核里那些 device tree 节点也不是上层 App 的 JSON它是高通 thermal-engine 守护进程专用的一份文本配置。这个 daemon 早期叫thermal-engine在部分平台上还能看到thermald相关的历史和兼容层整体思路是一样的读取 SoC 上的温度传感器按照配置里定义的阈值表和动作表去操作系统里的各类冷却设备最常见的就是限制 CPU 最高频率。用生活里的例子类比它就是一台中央空调的温控器。温度传感器像是贴在房间各处的温度计thermal-engine.conf则是你写在控制器里的逻辑室温到 28 度开低风量到 32 度开中档超过 36 度直接强力制冷。等高通 SoC 跑到 70 摄氏度、80 摄氏度、90 摄氏度这条链路就会依次把大核从 2.84GHz 拉到 2.4GHz、再拉到 1.7GHz从而把温度控制在设定范围内。这里有个很多人没搞清楚的历史背景早期 Linux 内核里有msm-thermal驱动温控策略在内核态实现后来高通则把它逐渐迁移到用户态目的就是让策略变得“可配置、可动态调整”。厂家不需要为了改一个降温阈值就重新编译内核直接改配置然后重启服务即可。这也是thermal-engine.conf如此重要的原因——它实际上成了温控策略的“可编程中枢”。1.2 配置文件的结构段落、键值对与动作表打开一份典型的高通thermal-engine.conf你看到的不是 XML也不是 JSON而是一种类似 C 语言风格的文本结构。大括号用来划分逻辑块每行都是“参数名 值;”的形式分号不能丢。整体上你会反复见到下面几个段落sampling控制采样周期sensor定义传感器和阈值动作virtual-sensor定义虚拟传感器algorithm定义温度补偿算法monitor则把传感器、算法和动作绑定起来。一个简化但结构完整的示例大致长这样sensor { name tsens_tz_sensor0; type tsens; tsens-id 0; thresholds 75000 85000 95000; actions { action { type cpu; id 4; value 1728000; level 1; } action { type cpu; id 4; value 1400000; level 2; } } } sampling { period 1000; }这个片段的意思是监控名为tsens_tz_sensor0的 TSENS 温度点当温度超过 75 摄氏度时把 CPU 4 号核最高频率限制到 1.728GHz超过 85 摄氏度时限制到 1.4GHz超过 95 摄氏度时再执行 level 3 对应的动作。这里的温度单位是毫摄氏度也就是75000代表 75.000 摄氏度。频率单位是赫兹1728000就是 1.728GHz。新手最容易在这里摔跟头把 75 当成 75 摄氏度填进去结果从开机起系统就拼命降频。1.3 为什么做整机方案必须动这份配置也许你会问原厂自带配置不是能用吗对不同产品来说真不一定“能用得好”。手机、平板、随身 Wi-Fi、智能音箱、车载盒子它们的结构散热能力天差地别。原厂配置往往基于公版参考设计调校而你的产品可能主板面积更小、没有 VC 均热板、外壳是塑料而不是金属这些都会导致同样功耗下温度更高或反过来热阻很小但 CPU 撞温度墙的时机更早。举个实际例子某款基于骁龙平台的便携随身 Wi-Fi参考设计里配置的 CPU 降频阈值是 85 摄氏度但产品塞进密闭外壳后无风扇环境下跑业务负载温度很容易冲到 90 摄氏度以上。如果不改配置设备就会在“高温降频-网速骤降-温度回落-恢复高频”之间反复横跳用户感知就是网络极不稳定。这种情况下调整温控阈值、增加虚拟传感器来综合判断整机温度往往比更换散热硬件更直接、更省钱。2. 虚拟传感器Virtual Sensor从物理读点到算法补点2.1 为什么需要虚拟传感器物理传感器不够用先记住一个结论虚拟传感器不是真实存在的硬件读点而是通过一个或多个物理传感器读点按特定算法计算出来的“合成温度”。你可能会疑惑SoC 上不是已经有那么多 TSENS 点了吗为什么还要再去算一个虚拟温度这就要回到实际硬件设计上。第一物理传感器位置有限。电池包内部、外壳表面、Wi-Fi/蓝牙 PA 附近、摄像头模组区域这些地方通常没有温度传感器或者只有一颗离得比较近的间接传感器。我们要控制这些区域的温度就必须用现有读点去估算。第二单点读数噪声大、容易误触发。某个 TSENS 点可能因为瞬时负载出现尖峰如果直接用这个点做 CPU 降频依据频率会跟着抖动用户体验非常差。用一个虚拟传感器把附近多个读点取平均值或最大值可以平滑噪声。第三有些产品需要在同一个读点上叠加不同算法比如既想用它做 CPU 控温又想用它估算电池温度这也可以靠多个虚拟传感器来实现。所以虚拟传感器的本质是用算法去“补”硬件上测不到、测不准的温度。你可以把它理解成通过几个房间的温度计推测洗手间地板温度是多少——虽然没有直接测量但基于经验和相关性这个推断值足够用来做控制。2.2 virtual-sensor 字段逐项拆解语法与选型在配置里虚拟传感器用virtual-sensor段落来定义。它的基本语法结构如下virtual-sensor { name vts_board_temp; sensor-list tsens_tz_sensor0 tsens_tz_sensor1 tsens_tz_sensor2; math-type max; coefficient 1 1 1; offset 0; share-sensor 1; }逐项来解释name虚拟传感器名称必须全局唯一。后面各种sensor段落或monitor段落引用它的时候就是靠这个名字。sensor-list列出参与计算的传感器读点名称。这些读点必须是配置里已定义的传感器也可以是另一个虚拟传感器也就是说虚拟传感器可以“套娃”。math-type计算方式常见的有average、max、min、diff、sum。average是取平均值适合做平滑max是取最大值适合判断热点min取最小值一般用于安全性判断sum用得少适合做总功耗相关的估算。coefficient每个输入读点的权重系数。数字个数必须和sensor-list里的传感器数量一致。比如三路都填 1就是等权平均填1 2 1中间那路权重更高。offset最终结果加上的固定偏移量单位同样是毫摄氏度。有些场景下知道 A 点比 B 点高 10 度就可以直接加10000。share-sensor一个标记位表示这个虚拟传感器可以被多个监控线程共享读取。如果多个monitor同时引用同一个虚拟传感器这个字段能避免重复采样节省开销。需要留意的是不同高通平台的配置字段名可能略有差异。老平台可能用sensor-list新平台可能是sensorsmath-type的取值范围也会增加。所以我的习惯是拿到一个新平台的配置先把原厂自带配置里已有的virtual-sensor段全部读一遍照着它的写法扩展这比硬套旧版语法安全得多。2.3 虚拟传感器实战案例多读点取最大值上报光讲字段还是有点干我分享一个实际调过的案例。当时是一款采用骁龙平台的便携游戏设备主板上除了 SoC还有一颗电源管理芯片 PMIC以及一个靠近后盖天线的温敏电阻。原厂配置里只针对 SoC 的 TSENS 做控温但用户反馈“打游戏时后盖左上角烫手但系统还没降频”。排查后发现后盖温度主要来自两个热源SoC 高负载带来的整机热积蓄以及 Wi-Fi/PA 区域的局部发热。单纯看 TSENS 并不能很好覆盖 PA 区域。于是我用三颗读点构造了一个虚拟传感器virtual-sensor { name vts_back_cover_est; sensor-list tsens_tz_sensor0 pmic_tsens thermistor_back; math-type max; coefficient 1 1 1; offset 5000; }思路是取 SoC、PMIC 和后盖热敏电阻三者的最大值再加 5 摄氏度的偏移量用来近似“用户摸到的表面温度”。然后把这个虚拟传感器挂在 CPU 控温的monitor上这样只要任意一个热源接近阈值系统就会提前介入。这里关键的一个决策是为什么用max而不是average因为用户感知最强烈的永远是“最热点”。如果取平均值局部高温往往被其他低温读点稀释等到平均值触发阈值时局部早就烫得没法摸了。反过来如果你是想做系统整体负荷管理、不希望某一颗传感器尖峰误导策略那average或带权重的average更合适。选型没有绝对对错关键是你先想清楚这个虚拟温度代表什么物理量。3. CPU 频率控制从温区阈值到调频动作的完整链路3.1 sensor 动作表thresholds 与 actions 的对应关系CPU 频率控制的核心其实全部浓缩在sensor段落里的thresholds和actions中。thresholds定义一组温度阈值actions定义一组动作两者通过level字段关联起来。温度超过第几个阈值就执行对应level的动作。我用一个稍微完整一点的示例来说明sensor { name cpu_temp; type tsens; tsens-id 0; thresholds 70000 80000 90000 100000; actions { action { type cpu; id 0; value 2016000; level 1; } action { type cpu; id 0; value 1740000; level 2; } action { type cpu; id 0; value 1400000; level 3; } action { type cpu; id 0; value 902000; level 4; } } }这段配置的逻辑非常直白温度超过 70 摄氏度时把 CPU0 最高频率限制到 2.016GHz超过 80 摄氏度限制到 1.74GHz超过 90 摄氏度限制到 1.4GHz超过 100 摄氏度限制到 902MHz。这就是常说的“逐级降频”。action里的type还可以有很多变化。除了cpu还有cluster、gpu、devfreq、battery、cpr等。cpu一般是针对单独 CPU 核心cluster是针对整个 CPU 簇gpu则控制 GPU 最高频率。id字段要填目标对象的编号但不同平台编号规则不一样有些平台从 0 开始有些分大小核可能需要按 cluster 区分写错直接不生效。我在实际项目里踩过一个大坑某平台上大小核的 CPU 编号不是连续的大核是 4-7小核是 0-3配置里如果只写了id 0结果就是大核温度飙到 100 摄氏度了小核被限制但大核纹丝不动。所以拿到新平台第一件事就是把/sys/devices/system/cpu/下的 possible 和 online 节点看一遍确认好枚举顺序再写id。3.2 algorithm 算法线性补偿与 PID 控温如果配置里只有thresholds和actions那这个温控就是纯离散的“阶梯开关”。温度一超过阈值频率直接跳变用户体验往往就是“一下卡一下不卡”。为了改善这个问题高通引入了algorithm段落用算法去动态计算目标频率而不是简单查表。最常见的两种算法是线性算法和 PID 算法。线性算法的思路是在某个温度区间内温度的提升对应频率的线性下降同时通过margin参数设置余量避免贴着阈值反复横跳。一个例子algorithm { name linear_algo; linear { margin 5000; limit { temp 115000; value 1550000; } } }margin 5000表示保留 5 摄氏度的余量也就是当温度接近 115 摄氏度但还没到的时候就开始线性降低频率最终频率被限制在 1.55GHz 以下。这样整个降频过程是平滑过渡的而不是突然从 2.8GHz 掉到 1.5GHz。PID 算法则更“聪明”一点它把当前温度、温度变化趋势、累计误差都纳入计算能够更提前地抑制温度爬升。配置大致长这样algorithm { name pid_algo; pid { kp 10; ki 2; kd 0; output-limit 800000; } }其中kp是比例系数决定“温度高了立刻压多少频率”ki是积分系数决定“长期偏热时持续压多少”kd是微分系数决定“温度上升太快时提前压多少”。实际调起来kd往往从 0 起步先调kp再慢慢加ki。参数太激进会导致频率震荡参数太保守又会让温度持续爬升。我的建议是如果没有足够的时间和测试设备先从linear入手稳定性好、行为可预测等整套温控跑顺了再针对特定场景引入 PID。不要一上来就追求“智能控温”离散阈值表已经能解决 80% 的问题。3.3 调频策略选型逐级降频、直接限频与优先关核在actions的具体设计上常见的策略有三种。第一种就是上面例子里的逐级降频温度越高频率越低阶梯比较多用户基本无感知适合大多数日常产品。第二种是直接限频温度一旦越过某个阈值就一步到位限制到很低频率适合对表面温度有严格要求的场景比如手持设备宁可性能大幅下降也要保证不烫手。第三种是关核配置里可以写type cpu加特殊 value或者使用其他冷却手段温度极高时直接 offlining 掉一部分核心这是最后的保护手段一般只用于临近硬件极限时。三种策略怎么选核心看两点一是产品的用户场景二是散热设计的余量。像游戏手机散热堆料比较足逐级降频可以多留一些性能像轻薄本、随身 Wi-Fi 这种无风扇设备散热余量小可能需要在较低温度就采取更果断的限频动作。还要注意monitor段和sampling段的配合。monitor决定哪个算法去监控哪个传感器sampling决定多长时间采样一次。周期太短会让系统频繁读数、耗电增加周期太长又会让温控反应迟钝。一般平台原厂给 1000ms 甚至更短具体还是根据你的产品热时间常数来定。热质量大的产品周期可以放宽热质量小的则要缩短。3.4 与系统其他温控机制的配合别以为改完thermal-engine.conf就万事大吉了。系统里还同时跑着内核 thermal framework、cpufreq governor、GPU 的 devfreq 调频以及高通部分平台上的自适应策略模块比如高通的 AIS、各种 AI 调频思路在不同平台上有不同实现。这些机制和 thermal-engine 之间的关系说白了就是“多个管理员同时管一个房间的空调”策略之间可能打架。最常见的冲突是 cpufreq 的scaling_max_freq被其他模块改了。比如某个省电策略或 Game 模式的调度框架直接把最高频率限制到了 1.5GHz那即使thermal-engine.conf里把阈值设得很宽松CPU 也冲不上去。反过来如果你的温控配置把频率压到很低但内核 thermal framework 又在另一个温度点调整冷却设备两者叠加可能造成降频幅度过大。另外高通新平台上已经开始加入更多“自适应”的思路。比如系统会学习用户的使用模式动态调整温控策略这时候thermal-engine.conf更多是一个底层的兜底策略而不是唯一策略源。我遇到很多工程师查了半天配置最后发现是另一个策略模块抢先改了scaling_max_freq。所以排查温控问题时第一步先看当前实际频率被谁改了再看配置文件顺序不要反。4. 实操从零配置一套可落地的温控策略4.1 第一步确认平台传感器与 sysfs 节点拿到一个不熟悉的高通平台不要急着改配置先花一小时把硬件读点摸清楚。通过 ADB 或串口进入系统查看/sys/class/thermal/目录下所有热区命令大致是这样ls /sys/class/thermal/ cat /sys/class/thermal/thermal_zone*/type cat /sys/class/thermal/thermal_zone*/temptype会告诉我们这个热区是什么传感器比如tsens_tz_sensor0、pmic-die、battery等。temp返回的是当前温度注意多数平台单位是毫摄氏度需要除以 1000 才是摄氏度。用这个方法可以快速确认thermal-engine.conf里引用的传感器名称是否和 sysfs 节点对得上。还有一个很实用的路径是/sys/kernel/debug/thermal/这个目录下能看到传感器更详细信息比如精度和报警状态但需要 root 权限。我自己在开发阶段一般会先跑一遍重负载同时用脚本循环打印所有热区的温度变化这样能直观看出哪些传感器对负载敏感、哪些基本上是摆设后面写虚拟传感器时心里才有底。4.2 第二步编写配置文件与部署传感器名称确认后就可以开始编写配置了。我建议不要直接改原厂文件而是先复制一份做备份再在副本上改。以/vendor/etc/thermal-engine.conf为例先把它导出到电脑上用支持语法高亮的编辑器打开注意关闭自动格式化和 Unicode 智能引号避免引入不可见字符。一个最小可用的配置至少要有sampling、sensor和monitor几块。从最简单开始验证不要一上来就堆一堆虚拟传感器和 PID 算法。比如先做这样一件事把某个传感器挂到一个 CPU 核心上设一个远低于实际温度的阈值比如 40 摄氏度看系统会不会正确降频。如果这个链路调通了再逐步把阈值改成真实值把虚拟传感器加进来。部署方式上多数平台的 thermal-engine 服务由 init 启动配置文件路径是写死的。你可以把修改后的文件 push 到原位置然后重启 thermal-engine 服务或者干脆重启整机。如果服务支持自定义路径启动也可以用调试方式先加载临时配置验证但不同平台差异较大最稳妥的做法还是“备份原文件、替换新文件、重启验证、随时回滚”。4.3 第三步验证降频曲线与稳定性配置部署之后一定要做完整验证不能只看一两个瞬间的频率值。我会一边跑压力测试一边采样 CPU 温度、各核频率、GPU 频率和整机电流画成曲线看整体趋势。采样命令比较简单while true; do cat /sys/class/thermal/thermal_zone0/temp cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq sleep 1 done重点关注三件事第一温度是否被控制在预期目标内第二降频动作是否平稳有没有频繁跳变第三降温后的恢复是否合理会不会因为频繁恢复导致温度来回震荡。如果发现降频过于突兀优先调margin和algorithm如果发现温度压不住先确认是不是还漏掉了某个发热大户比如 GPU 或 modem 也要纳入配置。另一个很容易被忽略的点是低温场景。我见过有人把阈值调得非常高结果冬天户外使用时结构件强度没问题但电池低温下内阻增大充电电流受限用户误以为是温控配置引起的。所以验证时要把高低温环境都覆盖到有条件就上恒温箱至少也要在室温和空调房之外找个相对热的环境跑一遍。5. 常见问题与排查实录5.1 配置不生效从日志到权限逐层定位配置不生效是大家问得最多的问题。如果你修改了配置文件重启后观察频率完全没有变化先把下面这几件事逐个排查。一是配置文件路径不对。高通平台版本不同配置文件可能放在/system/etc/、/vendor/etc/、/vendor/etc/thermal/等位置有些平台还会按 SKU 加载不同文件。你先让系统打印出 thermal-engine 启动时加载的路径再看自己改的是不是那份。二是 SELinux 权限问题。即便你通过 root 把文件 push 进去了文件的安全上下文如果不匹配daemon 也可能无法读取或直接忽略。修改后执行一下restorecon让文件恢复到这个分区应有的上下文常常能解决问题。三是服务根本没重启或者改完配置后 daemon 解析失败崩溃了。通过logcat或dmesg查看 thermal-engine 的日志如果有语法解析错误会直接告诉你哪一行有问题。最常见的就是少了分号、多了括号或者sensor-list引用了不存在的传感器名称。我个人的排查习惯是改完配置后先手动在命令行尝试解析一遍如果平台提供了解析工具或命令的话没有工具就通过日志确认 daemon 是否正常加载确认加载成功后再去验证行为。不要每次改完配置都盲目重启整机那样一轮测试就要好几分钟。5.2 温控过激或过钝参数调整方向配置能生效但实际表现不理想这类问题更考验调参功力。遇到“没怎么玩游戏就疯狂降频”通常是阈值太低、margin太保守或者虚拟传感器选取的读点太敏感。可以先看日志里触发降频时温度是多少再对照配置看是哪个传感器先越界。如果是一个局部热点引发的误判可以考虑改用average类型虚拟传感器而不是直接堆高阈值。遇到“已经烫手了还不降频”问题可能出在几个方向。一是传感器选错了监控的温度点和用户感知的热点不是同一个物理位置二是采样周期太长温度冲到很高之后才反应过来三是被其他模块抢先限制了散热能力比如风扇策略、充电策略或者 GPU 调频机制。记住一个朴素原则温度只是结果功率才是原因。温控做得粗糙通常是对“谁在发热、从哪里扩散”理解不够。调整参数时一次只改一个变量。比如我先只调阈值观察曲线再决定要不要动margin先把 CPU 控温调稳再引入虚拟传感器先把离散阈值表调到能接受再考虑 PID。科研式地同时改五个参数出了问题根本不知道是哪个改坏的。5.3 踩坑经验与独家建议这些年的实战里有一些经验是文档里不会写的我挑几个最实用的分享给有同样困扰的朋友。第一备份永远是第一位的。thermal-engine.conf这种配置文件一个符号错了就可能让 daemon 崩溃而崩溃后的系统往往不会自动加载默认策略甚至可能出现“完全不控温”的危险状态。所以我每次动手前都会把原文件复制到/data/local/tmp/或者电脑上确认无误后再覆盖。第二不同平台之间的配置文件不能直接互拷。高通的平台版本迭代很快新老平台对字段的支持不一样。老平台里能用的thresholds写法新平台可能已经改名新平台引入的algorithm字段老平台直接忽略。入职新项目或者接手新平台时先用原厂配置跑一遍全流程摸清语法再定制别赌自己的记忆。第三虚拟传感器和algorithm配合时注意引用方向不能循环。配置里sensor引用虚拟传感器虚拟传感器又引用了另一个虚拟传感器如果形成 A 引用 B、B 引用 A 的环daemon 解析时可能直接报错或死循环。检查方法是顺着每个sensor-list往下追一遍确认没有闭环。第四接近硬件极限的高阈值要慎重。把 CPU 阈值从 85 摄氏度调到 100 摄氏度看起来只是数字变化但芯片长期高温下寿命、漏电流、稳定性都会受影响。我做温控策略时有一条铁律接近原厂硬件规格上限的动作必须经过可靠性和寿命测试而不是拍脑袋。最后再提一个小技巧配置里每个virtual-sensor和sensor都用有业务语义的名字比如vts_battery_surface、tsens_cpu_max不要用vts_0、vts_1这种没有信息量的命名。你一个人调试时怎么命名都行但项目换人维护、或者你自己半年后再回来看这份配置时一个好名字能省下大量反推注释的时间。温控策略这种“改起来一时爽、排起查火葬场”的模块可读性就是生产力。
