11. Camera HAL层优化：HAL3 vs HAL1功耗对比、Stream配置优化、Request队列管理
各位好，今天我们来聊聊Camera HAL层的功耗优化。说实话，HAL层是相机功耗的“深水区”——上层应用再怎么优化，如果HAL层不配合，功耗照样下不来。我个人习惯把HAL层比作相机的“变速箱”，它决定了数据怎么流转、怎么处理、怎么输出。调好了，功耗能降一大截；调不好，CPU和ISP都在空转。
11.1 HAL3 vs HAL1：功耗差异到底在哪？
先说说HAL1和HAL3。很多同学问我：“是不是HAL3就一定比HAL1省电？”嗯，这个问题不能一概而论。
| 对比项 | HAL1 | HAL3 |
|---|---|---|
| 架构模式 | 固定Pipeline，一次只能处理一个Stream | 灵活Pipeline，支持多Stream并行 |
| Buffer管理 | 内部管理，应用层无法干预 | 应用层可配置Buffer数量和格式 |
| 功耗特点 | 低负载场景下功耗更低（因为流程固定） | 高负载场景下功耗更低（因为可裁剪） |
| 典型场景 | 单路预览、拍照 | 多路预览、HDR、高帧率 |
我在项目中遇到过这样一个案例：某款手机在预览场景下，HAL3的功耗反而比HAL1高了15%。为什么？因为HAL3默认开启了多路Stream，即使应用只请求了一路预览，底层ISP仍然在为其他Stream做预处理。说白了，HAL3的灵活性是有代价的——配置不当，反而更耗电。
核心结论：
- 单路预览+低帧率场景：HAL1更省电（流程固定，无额外开销）
- 多路预览+高帧率场景：HAL3更省电（可裁剪无用Stream）
- 混合场景：建议动态切换HAL版本（但实现难度较大）
我的建议：如果你的产品主要做拍照和普通预览，HAL1就够了。但如果要做多路视频、AI场景识别，还是得上HAL3，然后精细配置Stream。
11.2 Stream配置优化：少即是多
Stream配置是HAL层功耗优化的核心。你想想看，每多一路Stream，ISP就要多处理一路数据，DDR带宽就要多占一份。我曾经见过一个项目，应用层同时配置了预览Stream、拍照Stream、视频Stream、回调Stream——结果手机烫得能煎鸡蛋。
优化Stream配置，我总结了三个原则：
- 能不配就不配：只配置当前需要的Stream，不要提前预留
- 能复用就复用：多个Consumer共享同一个Stream，减少重复处理
- 能降级就降级：降低非关键Stream的分辨率和帧率
举个例子，假设应用需要预览和拍照：
// 错误配置：两路独立Stream
stream1: PREVIEW, 1920x1080, YUV
stream2: STILL_CAPTURE, 4032x3024, JPEG
// 正确配置：复用预览Stream，拍照时切换分辨率
stream1: PREVIEW, 1920x1080, YUV
// 拍照时：将stream1分辨率临时切换到4032x3024
// 拍照完成后：恢复1920x1080这样做的好处是：ISP只需要处理一路Stream，功耗直接降了30%以上。我在项目中用这个方案，把某款中端机的拍照功耗从2.8W降到了1.9W。
注意：复用Stream时，要处理好分辨率切换的时序。我曾经因为切换时机不对，导致拍照时出现黑屏——嗯，那是一个加班的夜晚。
11.3 Request队列管理：别让ISP空转
Request队列管理，说白了就是控制“什么时候发Request、发多少Request”。HAL3的Request机制很灵活，但也很容易踩坑。
我见过最典型的问题：应用层一次性提交了10个Request到队列里，结果ISP忙不过来，Buffer溢出，功耗飙升。为什么会这样？因为ISP处理每个Request都需要时间，队列太长会导致Pipeline阻塞，ISP一直在空转等待。
优化Request队列，我推荐以下策略：
- 控制队列深度：建议不超过3个Request（预览场景）
- 动态调整帧率：根据场景自动降低Request提交频率
- 使用Burst模式：高帧率场景下，批量提交Request减少IPC开销
来看一个实际案例：
// 优化前：固定30fps，队列深度5
for (int i = 0; i < 5; i++) {
submitRequest(30fps);
}
// 优化后：动态帧率，队列深度2
if (isLowLight) {
submitRequest(15fps); // 暗光场景降帧
} else {
submitRequest(30fps);
}
// 队列深度控制在2，避免ISP过载关键指标：
- 队列深度：2-3个Request最佳
- 帧率：暗光场景建议15fps，正常场景30fps，高帧率场景60fps
- Buffer复用率：目标90%以上
11.4 知识体系总览
下面这张图总结了HAL层优化的核心逻辑，我建议你保存下来，做优化时对照着看：
11.5 避坑指南
最后，分享几个我踩过的坑：
- 坑1：HAL3下忘记关闭无用Stream——我曾经在调试时发现预览功耗异常，查了半天发现是之前测试留下的一个1080p视频Stream没关。嗯，这个Stream一直在后台跑，白白耗电。
- 坑2：Request队列深度设置过大——有次我把队列深度设成了10，结果ISP处理不过来，Buffer溢出，功耗反而比正常高了20%。后来改成3，问题解决。
- 坑3：Stream复用时机不对——拍照时切换分辨率，如果没等当前帧处理完就切换，会导致ISP pipeline卡死。我的经验是：先停止Request提交，等所有Buffer回收到再切换。
一个小技巧：在调试HAL层功耗时，可以用perf工具抓取ISP的占用率。如果ISP占用率超过80%，说明Stream配置或Request队列有问题，需要优化。
好了，HAL层的优化就聊到这里。记住一句话：HAL层优化的本质是“减少不必要的数据处理”。把这句话刻在脑子里，你做优化时就不会跑偏。
公众号:蓝海资料掘金营，微信deep3321