4、Buffer管理优化：Gralloc Buffer分配策略、Buffer复用与回滚机制、减少内存拷贝
好，咱们进入第四个核心话题——Buffer管理。说实话，在相机HAL的优化里，Buffer这块是最容易出性能瓶颈的地方，也是最容易被忽视的。我见过太多项目，CPU占用不高，GPU也不忙，但帧率就是上不去。一查，好家伙，Buffer分配和拷贝占了大量时间。
今天咱们就把Gralloc Buffer的分配策略、复用与回滚机制，还有怎么减少内存拷贝，一次性讲透。
4.1 Gralloc Buffer分配策略：别每次都找系统要
先问个问题：你每次拍照或预览，都去申请一块新的Buffer，合理吗？
当然不合理。每次分配Buffer都要经过Gralloc HAL，涉及到ION内存分配、Cache刷新、甚至可能触发内存回收。这个过程少说几百微秒，多则几毫秒。你想想看，如果每帧都这么干，帧率直接腰斩。
我个人习惯的做法是：预分配+池化管理。
什么意思？就是在Stream配置阶段，一次性把需要的Buffer都申请好，放到一个Buffer池里。运行时直接从池里取，用完再还回去。
核心原则：分配次数越少，性能越好。尽量在配置阶段完成所有Buffer分配。
具体来说，分配策略要考虑几个维度：
- Buffer数量：一般建议是“生产者+消费者+1~2个备用”。比如预览场景，Producer是Camera HAL，Consumer是Display或Encoder，那至少需要3~4个Buffer轮转。
- Buffer大小：按最大分辨率分配。别偷懒，否则切到高分辨率时还得重新分配。
- Buffer格式：尽量使用平台原生格式，比如NV12或NV21。YUV420 planar虽然通用，但Gralloc处理起来效率低。
我在项目中遇到过一件事：某款手机预览时偶尔卡顿，查了半天发现是Buffer池太小，只有2个Buffer。当Display和Encoder同时消费时，生产者就得等，帧率直接掉到15fps。后来把池子扩大到4个，问题解决。
小技巧：Buffer池的大小可以用一个简单的公式：pool_size = producer_count + consumer_count + 1。其中producer_count和consumer_count是并发的生产者和消费者数量。
4.2 Buffer复用与回滚机制：别浪费每一帧
Buffer复用，说白了就是同一块Buffer，在不同场景下重复使用。比如预览和拍照，能不能共用Buffer？
能，但有条件。
我建议的做法是：建立Buffer状态机。每个Buffer都有状态：空闲、使用中、待回滚、已提交。只有空闲状态的Buffer才能被分配出去。
回滚机制是什么呢？举个例子：你拍了张照片，但图像质量不达标，或者算法处理失败。这时候，Buffer不能直接丢给消费者，而是应该回滚到池里，让生产者重新填充。
注意：回滚不是简单的“放回去”。你需要确保Buffer里的数据没有被污染。如果之前填了YUV数据，回滚前最好清空或者标记为无效。
我曾经踩过一个坑：某次实现回滚时，只是把Buffer放回了空闲队列，但没有重置它的metadata。结果下一帧拿到这个Buffer时，还带着上一帧的曝光参数，导致图像亮度异常。嗯，从那以后我就在回滚逻辑里加了个“metadata重置”步骤。
Buffer复用的另一个场景是：多路复用。比如同时预览和录像，能不能共用同一块Buffer？
答案是：可以，但需要小心。如果预览和录像的分辨率、格式一致，那完全可以用同一块Buffer。只需要在Consumer端做一次引用计数，确保所有消费者都处理完了，Buffer才能回池。
// 伪代码：Buffer引用计数管理
class BufferPool {
int acquire(Buffer* buf) {
buf->ref_count++;
return buf->fd;
}
void release(Buffer* buf) {
buf->ref_count--;
if (buf->ref_count == 0) {
// 所有消费者都释放了，回池
returnToPool(buf);
}
}
}4.3 减少内存拷贝：零拷贝才是终极目标
内存拷贝，是性能杀手。你想想看，一帧4K的YUV图像，大小约12MB。如果每帧拷贝一次，30fps就是360MB/s的数据量。这还没算上格式转换、缩放等操作。
减少拷贝的核心思路：让数据在硬件流水线里流动，别经过CPU。
具体怎么做？我总结了几个实战方法：
- 使用Gralloc的硬件Buffer共享：通过dma-buf fd传递，而不是memcpy。Camera HAL把Buffer填好后，直接把fd传给Display或Encoder。它们通过ION直接访问，CPU不参与。
- 避免格式转换：如果可能，让ISP直接输出目标格式。比如Encoder需要NV12，那就让ISP输出NV12，别输出YUV420再转一次。
- 使用GPU或DSP做后处理：比如旋转、缩放，交给GPU或DSP。它们可以直接操作dma-buf，不需要CPU介入。
零拷贝的典型路径：Sensor → ISP → dma-buf → Encoder/Display。全程CPU不碰数据，只传递fd和metadata。
我在项目中遇到过最典型的反面教材：某团队在Camera HAL里把YUV数据从ION Buffer拷贝到CPU内存，做完旋转后再拷贝回ION Buffer。结果CPU占用率直接飙到80%，帧率只有10fps。后来改成用GPU做旋转，CPU占用降到5%，帧率回到30fps。
嗯，这里要注意：不是所有场景都能零拷贝。比如人脸检测、HDR合成这些需要CPU计算的场景，数据还是得进CPU。但即便如此，也要尽量减少拷贝次数。比如只拷贝ROI区域，而不是整帧。
| 场景 | 推荐做法 | 拷贝次数 |
|---|---|---|
| 预览 | 直接传递dma-buf fd | 0 |
| 录像 | Encoder直接消费dma-buf | 0 |
| 拍照（JPEG） | ISP输出NV12，GPU做JPEG编码 | 1次（NV12→JPEG） |
| 人脸检测 | 只拷贝ROI区域到CPU | 1次（部分数据） |
避坑指南：我曾经在某个平台上发现，dma-buf跨进程传递时，如果Consumer和Producer不在同一个进程，需要做一次“Buffer导入”。这个导入操作本身也有开销，别忽略。建议在配置阶段就完成导入，运行时只传递fd。
最后总结一下：Buffer管理优化的核心就三句话——少分配、多复用、零拷贝。做到这三点，你的相机HAL性能至少能提升30%以上。当然，具体实现时还要结合平台特性，比如高通平台有自己的一套Buffer管理API，MTK平台又是另一套。但思路是通用的。
好，这一章就到这里。下一章咱们聊聊同步机制，那是另一个容易出坑的地方。