27. 功耗优化案例：某机型预览功耗从500mA降到300mA实战、录像功耗优化案例
各位做相机开发的同行，今天咱们聊点实在的。
功耗优化这活儿，说难不难，说简单也不简单。我见过太多团队，一上来就对着代码瞎改，改完发现功耗没降多少，稳定性倒崩了。今天我就拿两个真实案例，讲讲我是怎么把预览功耗从500mA干到300mA的，以及录像功耗优化的那些坑。
27.1 预览功耗优化：从500mA到300mA的实战
先说说背景。某款中端机型，相机预览功耗一直偏高，平均500mA左右。用户反馈发热严重，尤其是夏天，拍个照手机能煎鸡蛋。我接手后，第一件事不是改代码，而是先抓trace。
核心思路：预览功耗的三大耗电大头——ISP处理、显示刷新、Sensor输出。这三块占了总功耗的80%以上。
27.1.1 第一步：砍掉不必要的ISP处理
我抓了trace一看，好家伙，ISP一直在做全尺寸的YUV转换和降噪处理。但问题是，预览只需要720p的分辨率，Sensor输出却是4K的。
说白了，这就是典型的「杀鸡用牛刀」。我建议的做法是：
- 限制Sensor输出分辨率：预览模式下，强制Sensor输出1280x720，而不是4K。这一步能省下约80mA。
- 关闭不必要的ISP模块：比如HDR合成、多帧降噪，这些在预览时根本用不上。我直接通过Camera HAL层把对应的ISP pipeline关掉。
- 降低帧率：预览不需要60fps，30fps完全够用。帧率降一半，功耗能降15%左右。
我的经验：很多团队不敢动Sensor输出分辨率，怕影响拍照质量。其实预览和拍照走的是两条pipeline，预览用低分辨率，拍照时再切回全尺寸，完全没问题。我在项目中这么干过，用户感知不到任何差异。
27.1.2 第二步：优化显示刷新策略
预览画面最终要显示到屏幕上。我发现在某些场景下，SurfaceFlinger的刷新率被锁在了90Hz，但预览只有30fps。这意味着每帧画面被重复刷新了3次，白白浪费了功耗。
解决方案很简单：
- 通过
Choreographer回调，动态调整显示刷新率，匹配预览帧率。 - 如果屏幕支持LTPO，直接让刷新率降到30Hz。
这一步大概能省下40-50mA。
27.1.3 第三步：Sensor功耗调优
Sensor本身也是耗电大户。我检查了Sensor的驱动配置，发现它一直工作在「高性能模式」，即使预览场景不需要那么高的增益。
我做了两件事：
- 降低Sensor的模拟增益：在光照充足时，用数字增益代替模拟增益，能省电。
- 开启Sensor的skip模式：输出720p时，让Sensor直接跳过部分像素，而不是全尺寸读出后再缩放。这个叫「binning」或「skipping」，不同Sensor叫法不同，但原理一样。
注意：skip模式会影响画质，尤其是边缘细节。我建议只在预览场景用，拍照时切回全尺寸。我曾经因为没处理好切换逻辑，导致拍照时画面出现条纹，排查了两天才找到原因。
27.1.4 最终效果
经过这三步优化，预览功耗从500mA降到了300mA，降幅40%。用户反馈发热明显改善，续航也多了半小时。
| 优化项 | 优化前功耗 | 优化后功耗 | 节省 |
|---|---|---|---|
| ISP处理 | 180mA | 100mA | 80mA |
| 显示刷新 | 120mA | 70mA | 50mA |
| Sensor输出 | 200mA | 130mA | 70mA |
| 总计 | 500mA | 300mA | 200mA |
27.2 录像功耗优化案例
录像比预览更复杂，因为多了编码、音频、存储写入这几个环节。我遇到过一款机型，录像时功耗飙到800mA，机身温度直奔45度。用户录了10分钟就自动退出，体验极差。
27.2.1 编码器参数调优
录像的核心耗电是视频编码。我检查了编码器配置，发现用的是H.264 High Profile，码率设到了20Mbps。对于1080p 30fps的录像，这个码率太高了。
我做了以下调整：
- 降级到Main Profile：High Profile的编码复杂度高，功耗多出15-20%。对于手机录像，Main Profile完全够用。
- 降低码率：从20Mbps降到12Mbps。画质损失几乎不可感知，但编码功耗降了25%。
- 开启编码器的低功耗模式：大部分硬件编码器都有这个模式，代价是编码速度变慢，但录像场景下完全够用。
关键数据：编码器功耗从250mA降到了180mA，省了70mA。
27.2.2 音频处理优化
很多人会忽略音频的功耗。我抓trace发现，音频DSP一直在做48kHz的采样，但录像只需要16kHz。而且音频后处理（降噪、回声消除）全开着，功耗不小。
我的做法：
- 录像时降低采样率到16kHz，省了约20mA。
- 关闭不必要的音频后处理，只保留基础的降噪。
27.2.3 存储写入策略
录像要持续写文件。我发现在某些机型上，文件系统用的是F2FS，但没做任何写入优化。录像时频繁的小写入导致CPU频繁唤醒，功耗飙升。
解决方案：
- 增大写入缓冲区：从4KB调到64KB，减少写入次数。
- 使用异步写入：避免阻塞主线程，降低CPU占用。
避坑指南：我曾经遇到过一个问题，增大缓冲区后，录像停止时最后几秒的数据没刷到磁盘，导致文件损坏。后来我加了fsync调用，在停止录像时强制刷盘，才解决这个问题。
27.2.4 最终效果
录像功耗从800mA降到了550mA，降幅31%。机身温度从45度降到了39度，用户终于能录完一场球赛了。
| 优化项 | 优化前功耗 | 优化后功耗 | 节省 |
|---|---|---|---|
| 视频编码 | 250mA | 180mA | 70mA |
| 音频处理 | 80mA | 60mA | 20mA |
| 存储写入 | 120mA | 70mA | 50mA |
| 其他（ISP、显示等） | 350mA | 240mA | 110mA |
| 总计 | 800mA | 550mA | 250mA |
我的总结：功耗优化没有银弹。预览和录像的优化思路完全不同，但核心都是「找到大头，逐个击破」。我习惯先抓trace，看CPU、GPU、DSP、ISP的占用率，再结合电流曲线，定位问题点。别一上来就改代码，先搞清楚电都耗在哪了。
嗯，这两个案例就讲到这里。其实每个项目都有自己的特殊性，但方法论是通用的。你想想看，是不是这个理？
公众号:蓝海资料掘金营，微信deep3321