移动端功耗与发热
自动关联目录：移动端功耗与发热
1. 定位
移动端有一个桌面没有的维度：时间。发热会导致降频，于是"刚启动很流畅，跑十分钟就卡"——这不是内存泄漏，是功耗问题。
一句话定位：移动端性能必须按"稳态帧率"评估，而不是"启动后 30 秒的帧率"。
2. 功耗的来源
| 来源 | 说明 |
|---|---|
| GPU 带宽 | 移动端第一功耗大户（见 移动端渲染） |
| 全屏 pass | 每个 pass 一次全屏读写 |
| 高分辨率 | 直接线性放大带宽 |
| CPU 高频满载 | 逻辑与动画 |
| 网络与 IO | 加载与流式 |
| 屏幕亮度 | 不由引擎控制，但影响总功耗 |
优化功耗 ≈ 优化带宽，这是移动端最核心的对应关系。
3. 测量方式
| 层级 | 方法 |
|---|---|
| 硬件 | 外接电表测整机功耗（最准） |
| 平台方案 | 厂商/第三方的功耗分析方案 |
| 引擎侧 | 帧率曲线、GPU 计数器、温度相关 API |
| 项目实测 | UE性能优化工具 的功耗章节（含硬件方案与软件方案） |
判断有没有降频：跑一段固定回放，对比第 1 分钟与第 10 分钟的帧率曲线。掉了就是降频。
4. 发热降频的应对
| 手段 | 说明 |
|---|---|
| 降渲染分辨率 | 最有效（见 移动端渲染） |
| 砍全屏 pass | 减少带宽 |
| 关 Mobile HDR | 见移动端渲染篇 |
| Framepacing | 稳定帧节奏，避免忽快忽慢（见 UE性能优化工具） |
| 限制帧率上限 | 不必跑满，留出热预算 |
| 动态分辨率 | 热了自动降 |
| 减少持续高负载 | 例如待机时降低更新频率 |
Framepacing 的价值：即使平均帧率够，帧间隔不均匀也会明显感知为"卡"。
5. 代价与权衡
| 手段 | 收益 | 代价 | 什么时候不该用 |
|---|---|---|---|
| 降分辨率 | 功耗显著下降 | 糊 | 已到画质下限就只能砍 pass |
| 限制帧率上限 | 发热明显改善 | 上限帧率变低 | 竞技类需要高帧率 |
| 动态分辨率 | 自动适应 | 分辨率变化可见 | 变化太频繁会被察觉 |
| Framepacing | 手感更稳 | 需要正确配置 | — |
| 待机降频 | 省电 | 恢复时可能顿一下 | 关键交互期间不要降 |
6. 踩坑与排查
| 坑 | 现象 | 怎么验证 |
|---|---|---|
| 只测启动后几十秒 | 没发现降频 | 跑 10 分钟以上固定回放 |
| 把降频当成泄漏 | 错误归因 | 对比前后帧率曲线即可区分 |
| 只看平均帧率 | 忽略抖动 | 看帧间隔分布 + Framepacing |
| 桌面工具测移动端功耗 | 结论无效 | 用硬件电表或平台方案 |
| 开 Mobile HDR 没评估 | 发热 | 关掉对比（见移动端渲染篇） |
| 全屏后处理太多 | 带宽爆 | 统计 pass 数量 |
| 只在中高端机测 | 低端机崩 | 测最低配机型 |
7. 排查顺序
1. 跑 10 分钟固定回放，对比前后帧率 → 确认是否降频
2. 是 → 降分辨率 / 砍 pass / 关 HDR / 限帧
3. 抖动 → Framepacing
4. 用硬件或平台方案测功耗，定位大户
5. 按移动端渲染篇的带宽优化顺序处理
6. 在最低配机型上验稳态帧率参考
许可协议：CC BY
作者：Davids
本文链接：https://hustjjd.github.io/d02da1dc.html
更新于：2026年10月10日