预览延迟的定义与测量
大家好，我是你们的Camera HAL讲师。今天我们来聊聊预览延迟——这个让无数工程师头疼的问题。
先问大家一个问题：你按下手机相机，到画面出现在屏幕上，中间到底发生了什么？这个时间差，就是预览延迟。说白了，它就是「从光子进入镜头，到像素点亮屏幕」的总耗时。
什么是预览延迟
预览延迟，专业点说，是Camera从捕获第一帧图像到该帧显示在屏幕上的时间差。我习惯把它拆成三个字：慢、卡、顿。
- 慢：从按下到出图，整体耗时太长
- 卡：帧率不稳定，画面一抖一抖
- 顿：偶尔跳帧，像PPT翻页
嗯，这里要注意：预览延迟和拍照延迟是两码事。预览延迟影响的是取景体验，拍照延迟影响的是抓拍成功率。我在项目中遇到过不少团队把这两个混为一谈，结果优化方向全错了。
核心指标：预览延迟通常要求 < 100ms，高端机型甚至追求 < 50ms。超过150ms，用户就能明显感觉到「粘手」。
延迟的三大组成
预览延迟不是单一环节的问题。我习惯把它拆成三段：Sensor → ISP → Display。每一段都有自己的瓶颈。
1. Sensor延迟
Sensor延迟，就是感光元件从曝光到输出原始数据的时间。它主要由三部分决定：
- 曝光时间：光线越暗，曝光越长。比如暗光下30ms，白天可能只有5ms
- 读出时间：像素数据从Sensor传输到ISP的时间。分辨率越高，读出越慢
- 帧同步开销：VSYNC信号间隔，通常是16.67ms（60fps）或33.33ms（30fps）
我记得有一次，客户反馈暗光下预览卡顿。查了半天，发现Sensor在暗光下自动把曝光时间拉到了50ms，帧率直接掉到20fps。解决方案？限制最大曝光时间，配合增益补偿。
我的经验：Sensor延迟是硬瓶颈，很难通过软件优化。选型时就要关注「读出速度」这个参数。我一般要求Sensor的读出时间 < 10ms（1080p@30fps）。
2. ISP延迟
ISP延迟，是图像信号处理的时间。包括去噪、锐化、色彩校正、HDR合成等。这部分延迟最容易被忽视。
ISP延迟的典型构成：
| 处理阶段 | 典型耗时 | 说明 |
|---|---|---|
| RAW域处理 | 3-8ms | 黑电平校正、去噪、镜头校正 |
| RGB域处理 | 2-5ms | 白平衡、色彩矩阵、Gamma |
| YUV域处理 | 1-3ms | 缩放、旋转、裁剪 |
| 编码/格式转换 | 1-2ms | NV12转RGB、JPEG编码 |
你想想看，如果ISP处理一帧要15ms，那60fps的预览就只剩1ms的余量了。我曾经在一个项目里发现ISP的HDR合成占了12ms，直接导致预览帧率从30fps掉到20fps。后来我们改成了「预览用轻量HDR，拍照用全功能HDR」，问题就解决了。
避坑指南：我曾经见过有人把ISP的「画质模式」开到最高来跑预览，结果延迟飙到200ms。记住：预览追求的是低延迟，不是高画质。该降采样就降采样，该关特效就关特效。
3. Display延迟
Display延迟，是图像从GPU/DPU到屏幕显示的时间。这部分往往被Camera工程师忽略，但它可能是最大的瓶颈。
Display延迟的组成：
- Buffer排队：SurfaceFlinger的BufferQueue深度，通常2-3帧
- 合成时间：GPU合成图层的时间，特别是多层叠加时
- 刷新等待：等待VSYNC信号，最长16.67ms
- 屏幕响应：LCD/OLED的像素响应时间，OLED通常更快
嗯，这里有个坑：很多人以为Camera输出30fps，显示就是30fps。其实不是。如果Display的刷新率是60Hz，而Camera输出30fps，那每一帧都要等两个VSYNC才能显示。这就白白多了16.67ms的延迟。
优化思路：我建议Camera输出帧率与Display刷新率对齐。比如60Hz屏幕，Camera就输出60fps。如果做不到，至少保证帧率是刷新率的整数倍。
使用adb测量延迟
理论说完了，来点实战。怎么测延迟？最简单的方法是用adb。
我常用的方法是「打时间戳法」：
# 1. 开启Camera的帧时间戳日志
adb shell setprop persist.vendor.camera.frame_timestamps 1
# 2. 抓取log
adb logcat -c
adb logcat -v time | grep "FrameTimestamp" > frame_log.txt
# 3. 分析log
# 输出示例：
# 12:34:56.789 FrameTimestamp: sensor_start=1234567890, isp_done=1234567910, display_done=1234567950
# 延迟计算：
# Sensor延迟 = isp_done - sensor_start = 20ms
# ISP延迟 = display_done - isp_done = 40ms
# 总延迟 = display_done - sensor_start = 60ms这个方法虽然粗糙，但胜在简单。我经常用它做快速排查。不过要注意，这个时间戳的精度取决于驱动层的实现，有些厂商的驱动压根没打这些点。
我的习惯：如果驱动不支持时间戳，我会用「秒表法」——用高速相机同时拍摄手机屏幕和真实场景，然后逐帧对比。虽然土，但最可靠。
使用systrace测量延迟
adb方法只能看个大概。要精确定位瓶颈，还得上systrace。
systrace能抓取系统各模块的耗时，包括Camera HAL、ISP、SurfaceFlinger、HWC等。我一般这么用：
# 1. 开启systrace，抓取Camera相关标签
python systrace.py -t 10 -o trace.html \
--app=com.android.camera2 \
camera hal input video gfx view sched
# 2. 在trace中搜索关键事件
# Camera HAL: "HAL_processCaptureRequest"
# ISP: "ISP_ProcessFrame"
# Display: "onFrameAvailable", "queueBuffer", "onFrameCommitted"
# 3. 分析延迟分布
# 在trace timeline上，每个事件都有开始和结束时间
# 计算各阶段的耗时，找出最长的那个systrace的界面很直观。你会看到一条条彩色的时间轴，每个模块的耗时一目了然。我习惯先看「总延迟」，再看「各阶段占比」。如果ISP占了60%，那就去优化ISP；如果Display占了50%，那就去调SurfaceFlinger。
举个例子，我曾经用systrace发现一个奇怪现象：Camera输出明明是30fps，但Display只显示了20fps。仔细一看，SurfaceFlinger的BufferQueue深度是3，但Consumer端处理太慢，导致Buffer被占满，Producer端被阻塞。解决方案？把BufferQueue深度改成2，同时优化Consumer的处理速度。
注意：systrace抓取本身会引入一定的性能开销。我建议在「接近真实场景」下抓取，比如不要开太多trace标签，抓取时间控制在10秒以内。
总结一下
预览延迟的测量，说白了就是「分段计时」。Sensor、ISP、Display三段，每一段都有各自的坑。adb适合快速排查，systrace适合精确定位。
我个人习惯的排查流程：
- 先用adb看总延迟，判断是否超标
- 再用systrace看各阶段占比，找到瓶颈
- 针对瓶颈做优化，比如降低ISP处理负载、对齐帧率
- 优化后重新测量，验证效果
嗯，下一章我会讲具体的优化技巧，包括如何调HAL参数、如何优化ISP pipeline、如何减少Display排队。到时候咱们再细聊。
一句话记住：预览延迟 = Sensor延迟 + ISP延迟 + Display延迟。哪个环节慢，就优化哪个环节。别一上来就改HAL，先测清楚再说。