5、Capture性能优化：单帧拍照延迟分析、Burst模式优化、ZSL（零快门延迟）实现原理、RAW vs YUV vs JPEG编码性能对比
拍照性能，说白了就是用户按下快门到看到照片的时间。这个时间越短，体验越好。我这些年调过的摄像头模组少说也有几十款，每一款在Capture路径上都有各自的脾气。今天咱们就把这块硬骨头啃下来。
5.1 单帧拍照延迟分析
单帧拍照的延迟，我习惯把它拆成三段来看：
- Sensor曝光时间：取决于环境亮度和ISO设定。暗光下动不动就100ms+。
- ISP管线处理时间：从RAW数据到YUV/JPEG的转换，这里最容易出瓶颈。
- 应用层回传时间：数据从HAL到Framework再到App，中间跨进程通信的损耗。
我在项目中遇到过一个问题：某款手机在暗光下拍照要等将近1秒。后来一查，发现Sensor曝光设了200ms，ISP又用了300ms做多帧降噪，再加上App层处理，可不就慢了嘛。
核心结论：单帧延迟的优化，优先砍ISP处理时间，其次是曝光时间。应用层回传通常不是大头。
5.2 Burst模式优化
Burst模式，就是连拍。用户按住快门不松手，系统要一帧接一帧地拍。这里有个坑——帧率掉得很快。
为什么会这样？因为第一帧拍完后，ISP还在处理上一帧的数据，下一帧的RAW数据就已经来了。缓冲区满了，就开始丢帧。
我建议的优化思路：
- 增大Ring Buffer：把HAL层的buffer队列从3个增加到8个，给ISP留足处理时间。
- 降低单帧处理精度：连拍时把降噪强度调低一档，或者跳过部分算法模块。
- 使用Partial Metadata：不要等所有metadata都准备好再送帧，先送一部分，让App先看到预览。
避坑指南：我曾经在Burst模式下把buffer开得太大，结果内存爆了。嗯，这里要注意——Ring Buffer不是越大越好，要根据可用内存和ISP吞吐量来算。
5.3 ZSL（零快门延迟）实现原理
ZSL，零快门延迟。说白了就是用户按下快门的那一刻，拿到的其实是按下之前的某一帧。
实现原理其实不复杂：
- 预览阶段，HAL层一直在循环采集帧，放到一个循环缓冲区里。
- 用户按下快门时，HAL从缓冲区里取出最新的一帧，作为拍照帧。
- 这一帧的曝光时间是在按下快门之前就已经完成的，所以延迟几乎为零。
但这里有个问题——预览帧的分辨率通常比拍照帧低。如果直接用预览帧做拍照，画质会下降。所以很多方案的做法是：预览阶段同时采集全分辨率帧，但只做简单的预览处理，等用户按下快门再去做完整的ISP管线。
注意：ZSL模式下，功耗会明显增加。因为Sensor一直在全分辨率输出，ISP也要持续处理。我见过有些厂商为了省电，只在用户半按快门时才启动ZSL模式，这也是个折中方案。
5.4 RAW vs YUV vs JPEG编码性能对比
这三种格式，在Capture路径上的性能差异非常大。我直接给数据：
| 格式 | 数据量（12MP） | 编码耗时 | 适用场景 |
|---|---|---|---|
| RAW | ~24MB | 几乎为0 | 专业模式、后期处理 |
| YUV | ~12MB | ~5ms | 预览、视频、算法中间态 |
| JPEG | ~3MB | ~50ms | 最终输出、分享 |
你想想看，RAW几乎不需要编码，直接存盘就行。但JPEG要经过颜色空间转换、离散余弦变换、霍夫曼编码，一套下来50ms就没了。
我个人习惯的做法是：
- Burst模式：用RAW采集，拍完再异步转JPEG。这样连拍帧率能翻倍。
- 普通拍照：用YUV做中间处理，最后转JPEG。YUV比RAW小一半，内存压力小。
- ZSL模式：缓冲区里存YUV，按下快门直接取。如果存RAW，缓冲区会很快撑爆。
一句话总结：追求速度用RAW，追求兼容用YUV，追求存储用JPEG。但实际产品中，往往是三者的组合使用。
知识体系总览
下面这张图，把Capture性能优化的核心逻辑串起来了。你可以看到，从单帧延迟到Burst模式，再到ZSL和编码选择，其实都是在跟时间和内存做博弈。
这张图里，四个分支最终都指向同一个核心——在有限的时间和内存里，拿到最好的画质。单帧延迟是基础，Burst模式是压力测试，ZSL是体验升级，编码选择是最后一公里的取舍。
我的建议：做Capture优化时，先拿单帧延迟做基准，再测Burst模式下的帧率稳定性。ZSL和编码选择，根据产品定位来定。拍照旗舰机，ZSL是标配；主打视频的机型，YUV管线更重要。