功耗优化：解码功耗模型、帧率自适应、分辨率降级、温控策略
做视频解码优化这么多年，我越来越觉得功耗是个绕不开的坎。你想想看，画面再流畅、清晰度再高，手机发烫到能煎鸡蛋，用户照样会骂娘。今天我们就来聊聊硬解码场景下，怎么把功耗这件事管好。
解码功耗模型：先搞清楚电都去哪了
要优化功耗，首先得知道功耗从哪来。我个人习惯把解码功耗拆成三块：
- 核心解码功耗：GPU/VPU 干活时消耗的电，这是大头
- 内存带宽功耗：数据在 DDR 和缓存之间来回搬运的代价
- 显示链路功耗：从解码器输出到屏幕显示的整条链路
我在项目中遇到过一种情况：明明解码器负载不高，整机功耗却居高不下。后来一查，是 SurfaceFlinger 那边频繁做图层合成，把 GPU 给拖累了。说白了，解码功耗不只是解码器的事，整个 pipeline 都得看。
经验公式：P_total = P_decode + P_mem + P_display + P_thermal_throttle
其中 P_thermal_throttle 是温控降频带来的额外开销，这个后面会细说。
帧率自适应：别让解码器做无用功
帧率自适应，说白了就是让解码器根据场景动态调整输出帧率。为什么要这么做？因为很多时候你根本不需要 60fps。
举个例子：用户在看静态 PPT 或者聊天界面，30fps 甚至 15fps 就完全够用。强行跑 60fps，解码器每秒钟多处理一倍的数据，功耗直接翻倍。
我的做法：在解码器输出端加一个帧率检测器，统计最近 1 秒内的画面变化量。如果变化量低于阈值，就主动降低解码帧率。
具体实现上，我建议用 MediaCodec.Callback 配合自定义的帧率控制器。核心逻辑是这样的：
// 帧率自适应控制器核心逻辑
class AdaptiveFrameRateController {
private var targetFps = 60
private var lastFrameTime = 0L
private var frameInterval = 1000 / 60 // 毫秒
fun onFrameDecoded(currentTime: Long, sceneChange: Float) {
// 场景变化量低于 0.1，说明画面基本静止
if (sceneChange < 0.1f) {
targetFps = 15
} else if (sceneChange < 0.3f) {
targetFps = 30
} else {
targetFps = 60
}
frameInterval = 1000 / targetFps
// 控制输出节奏
if (currentTime - lastFrameTime < frameInterval) {
// 跳过当前帧，不送显示
return
}
lastFrameTime = currentTime
// 正常送显
}
}注意：帧率自适应不能做得太激进。我曾经试过把阈值设得太低，结果用户在滑动列表时画面出现明显卡顿。建议给场景变化检测加一个 200ms 的滞回区间，避免频繁切换。
分辨率降级：该降就降，别硬撑
分辨率降级，听起来有点「自废武功」的意思。但你想啊，手机屏幕就那么大，4K 和 1080p 肉眼根本分不出来。强行解码 4K 视频，解码器负载翻倍，功耗飙升，何必呢？
我一般会在以下场景触发分辨率降级：
- 电池电量低于 20%：直接降到 720p，优先保续航
- 解码器负载超过 80%：说明当前分辨率已经跑不动了，降一级
- 画面窗口化显示：如果视频只占屏幕一半，降分辨率几乎不影响观感
实现上，我习惯在 MediaCodec 的 onInputBufferAvailable 回调里做分辨率检测。如果检测到需要降级，就重新配置解码器：
// 分辨率降级触发逻辑
fun checkResolutionDowngrade(): Boolean {
val batteryLevel = getBatteryLevel()
val decoderLoad = getDecoderLoad()
val videoWindowSize = getVideoWindowSize()
// 电池低于 20% 且解码器负载高，触发降级
if (batteryLevel < 20 && decoderLoad > 0.8) {
return true
}
// 视频窗口小于屏幕 60%，降级不影响体验
if (videoWindowSize < screenSize * 0.6) {
return true
}
return false
}关键点：分辨率降级不是简单的缩放，而是重新配置解码器到更低的分辨率。这样解码器内部的处理单元可以工作在更低的频率上，功耗下降非常明显。
温控策略：别让手机变成暖手宝
温控这块，我踩过的坑最多。早期做项目时，我天真地以为只要检测到温度过高就降频就行。结果呢？温度是降下来了，但视频卡成幻灯片，用户投诉直接爆了。
后来我总结了一套分级的温控策略：
| 温度区间 | 策略 | 预期效果 |
|---|---|---|
| 35°C ~ 40°C | 正常解码，不做干预 | 无感知 |
| 40°C ~ 45°C | 启动帧率自适应，降低到 30fps | 轻微感知，但不影响观看 |
| 45°C ~ 50°C | 触发分辨率降级，降到 720p | 画质略有下降，但流畅度保持 |
| 50°C 以上 | 暂停解码，提示用户设备过热 | 保护硬件，避免损坏 |
嗯，这里要注意一点：温度检测不能太频繁。我见过有人每 100ms 读一次温度传感器，结果传感器本身的功耗反而成了负担。建议 2~3 秒采样一次就够了。
避坑指南：我曾经在某个项目里直接用 ThermalManager 的 addThermalStatusListener 来做温控。结果发现不同厂商的温控回调频率差异巨大，有的手机 5 秒才回调一次，根本来不及响应。后来我改成自己轮询 + 硬件回调双保险，才把这个问题解决。
最后说一句，功耗优化这件事，没有银弹。帧率自适应、分辨率降级、温控策略，这三者要配合着用。我个人习惯是先做帧率自适应，如果温度还压不住，再启动分辨率降级。温控策略作为最后一道防线，只在极端情况下触发。
这样一套组合拳打下来，解码功耗能降 30%~50%，而且用户几乎感知不到。这才是我们做优化的最终目的——让用户感觉不到优化的存在。