4、拍照延迟优化：Capture Request流程、JPEG编码优化、后处理管线、内存拷贝与零拷贝技术
拍照延迟，说白了就是按下快门到看到照片之间的那段时间。用户可不管你是HDR还是多帧合成，他只关心——按下去，照片出来没？
我做过一个项目，某款手机在暗光下拍照，按下快门后要等将近两秒才出图。用户反馈说“这手机是不是卡死了”。嗯，那段时间我几乎天天盯着systrace看，一条一条地抠延迟。
今天我们就来聊聊，拍照延迟到底从哪来，又该怎么优化。
4.1 Capture Request流程：请求链路上的每一微秒
先看一张整体流程图，帮你建立全局认知：
Capture Request从App发出，经过Framework、HAL，最终到达Sensor。这条链路上每一步都可能成为瓶颈。
第一个坑：Request排队
App如果连续发送多个Request，底层会按FIFO排队。我见过一个案例，App在拍照前先发了几个预览Request，拍照Request被堵在后面，白白多等了两个帧周期。解决方案很简单——给拍照Request设置高优先级。
关键优化点：
- 使用
CaptureRequest.CONTROL_AE_PRECAPTURE_TRIGGER时，确保预触发流程不阻塞主拍照 - 拍照Request设置
FLUSH标记，清空预览队列 - HAL层实现Request优先级调度，拍照优先于预览
4.2 JPEG编码优化：硬件加速与参数调优
JPEG编码是拍照延迟里的大头。一张1200万像素的照片，软件编码可能要300~500ms。用户等半秒才看到照片，体验能好才怪。
硬件JPEG编码器
现在主流SoC都集成了硬件JPEG编码器。我建议你优先使用硬件编码，延迟能降到30~50ms。怎么用？
// 使用硬件JPEG编码器示例
ImageReader reader = ImageReader.newInstance(width, height,
ImageFormat.JPEG, maxImages);
reader.setOnImageAvailableListener(reader -> {
Image image = reader.acquireLatestImage();
// 这里拿到的就是硬件编码后的JPEG数据
ByteBuffer buffer = image.getPlanes()[0].getBuffer();
byte[] jpegData = new byte[buffer.remaining()];
buffer.get(jpegData);
// 直接保存或显示
image.close();
}, handler);
注意，ImageFormat.JPEG这个格式，底层会走硬件编码。如果你用ImageFormat.NV21再自己转JPEG，那就是走软件编码了。
JPEG质量参数
我做过一个实验：质量从95降到85，文件大小减少40%，编码时间减少30%，但肉眼几乎看不出区别。你想想看，用户是在手机屏幕上看照片，又不是拿去印刷。
我的建议：
日常拍照用85质量，专业模式才开放95以上。这个参数在CaptureRequest.JPEG_QUALITY里设置。
4.3 后处理管线：YUV转RGB、旋转、裁剪
后处理管线里最耗时的操作是什么？YUV转RGB。Sensor出来的原始数据是YUV格式，但很多算法（比如美颜、滤镜）需要RGB格式。
YUV转RGB的优化
我曾经在一个项目里发现，YUV转RGB占了后处理总时间的60%。后来我们用NEON指令集做了优化，速度提升了3倍。
// NEON优化YUV转RGB（伪代码示意）
void yuv420_to_rgb_neon(uint8_t* y, uint8_t* u, uint8_t* v,
uint8_t* rgb, int width, int height) {
// 使用NEON intrinsics并行处理4个像素
for (int i = 0; i < width * height; i += 4) {
uint8x8_t y_vec = vld1_u8(y + i);
uint8x8_t u_vec = vld1_dup_u8(u + i/4);
uint8x8_t v_vec = vld1_dup_u8(v + i/4);
// 计算R、G、B分量
// ... NEON指令计算
vst1_u8(rgb + i*3, r_vec);
}
}
旋转和裁剪
很多App在拍照后还要做旋转（因为Sensor默认是横屏的）。如果是在CPU上做旋转，又是一笔开销。我建议你把旋转参数传给JPEG编码器，让硬件在编码时顺便旋转。
优化策略：
- YUV转RGB用NEON或GPU加速
- 旋转操作交给硬件JPEG编码器
- 裁剪操作尽量在YUV域完成，避免转RGB后再裁剪
4.4 内存拷贝与零拷贝技术
内存拷贝是拍照延迟里最容易被忽视的环节。你想想看，一张1200万像素的照片，YUV数据大概18MB。如果从Sensor到App之间拷贝了5次，那就是90MB的数据搬运。每次拷贝都要占用CPU和内存带宽。
典型的拷贝路径
| 环节 | 数据流向 | 拷贝次数 |
|---|---|---|
| Sensor → ISP | 硬件直接传输 | 0次（DMA） |
| ISP → HAL | HAL申请内存，ISP写入 | 1次 |
| HAL → Framework | 通过Gralloc传递 | 0次（共享内存） |
| Framework → App | 通过ImageReader | 1次（如果使用ImageFormat.YUV_420_888） |
| App内处理 | YUV转RGB、旋转等 | 2~3次 |
你看，从Sensor到App，至少经历了4~5次拷贝。每次拷贝按10ms算，就是40~50ms的延迟。
零拷贝技术
零拷贝的核心思想是：让数据在内存中只保留一份，所有模块都操作同一份数据。
具体怎么做？
- 使用Gralloc Buffer共享：HAL和Framework之间通过Gralloc传递buffer handle，不拷贝数据
- ImageReader直接映射：App通过ImageReader获取的Image对象，底层直接映射到HAL的buffer
- 避免ByteBuffer拷贝：很多开发者习惯把Image转成byte[]，这又是一次拷贝。直接用ByteBuffer操作
注意：
零拷贝虽然好，但有个前提——所有模块必须使用同一套内存管理机制。如果某个模块用了自己malloc的内存，那就没法零拷贝了。我曾经在一个项目里，第三方算法库非要自己申请内存，结果零拷贝方案泡汤，最后只能硬着头皮优化拷贝速度。
4.5 实战：一条完整的优化链路
说了这么多，我们来串一下。假设你现在要优化一款手机的拍照延迟，你会怎么做？
- 先抓systrace，看延迟到底花在哪。是Capture Request排队？还是JPEG编码？还是后处理？
- 优化Request流程：设置拍照优先级，清空预览队列
- 启用硬件JPEG编码：把质量降到85，减少编码时间
- 优化后处理：YUV转RGB用NEON，旋转交给硬件
- 实现零拷贝：检查每个环节的内存传递，去掉不必要的拷贝
我做过一个项目，按这个流程优化后，拍照延迟从1.2秒降到了400ms。用户反馈说“这手机拍照快多了”。嗯，这就是成就感。
避坑指南：
我曾经在优化JPEG编码时，发现硬件编码器在某些分辨率下不支持。比如某款芯片的硬件编码器最大只支持4000x3000，超过这个分辨率就会fallback到软件编码。所以，一定要先查芯片的datasheet。
拍照延迟优化，说白了就是跟每一微秒较劲。从Request到JPEG，从后处理到内存拷贝，每个环节抠一点，加起来就是质的飞跃。
公众号:蓝海资料掘金营，微信deep3321