321.Preview 与 Snapshot 管线的多线程同步机制分析

Preview 与 Snapshot 管线的多线程同步机制分析

关键词：
Camera HAL3、多线程同步、预览拍照共存、Request Pipeline、Frame Number、拍照阻塞、快门帧复用、Capture Session 管理

摘要：
在 Android 相机系统中，Preview 与 Snapshot 是两条相互依赖却又逻辑解耦的图像处理管线。为了保障拍照时延低、预览不断流，系统需在多线程环境下处理请求调度、buffer 分配、3A 状态同步等复杂问题。尤其在 HAL3 架构下，Preview 与 Snapshot 同时活跃且共享传感器输出，如何实现线程安全、顺序可控的管线并发调度，成为工程落地的关键挑战。本文将从实际系统结构与源码路径出发，深入分析两条管线的多线程协同机制、关键同步点与典型瓶颈，帮助开发者优化多模组与复杂 UseCase 下的稳定性表现。

目录

1. Camera 多线程架构回顾：Pipeline × Thread × BufferQueue 角色分布
2. Preview / Snapshot 请求来源与提交流程差异分析
3. Request 队列调度机制：线程互斥 × 顺序保障 × 冲突协调
4. Frame Number 分发与拍照帧精确命中策略
5. AE/AF/Flash 状态同步机制：管线协作的时序依赖点
6. Buffer 分配与释放策略：双流共享下的内存冲突避免机制
7. HAL 层快照实现结构：触发、阻塞与回传流程拆解
8. 实战调优建议：多线程异常处理 × 快门延迟缩减 × Metadata 对齐技巧

一、Camera 多线程架构回顾：Pipeline × Thread × BufferQueue 角色分布

在 Android HAL3 架构下，Camera 图像数据链路由多个线程协同运行完成，核心目标是 提升处理并发性与响应效率。多线程模型主要分为以下几个层级：

1.1 上层请求线程（App/UI 层）

• 角色： 提交预览与拍照请求（CaptureRequest），控制焦点、闪光、变焦等参数。
• 线程特点： 主线程或 CameraX 的工作线程，驱动 API 事件（如 takePicture()）产生快照请求。

1.2 CameraService 调度线程

• 核心模块： Camera3Device、RequestThreadManager
• 线程结构：
  • RequestThread：核心请求下发线程，连接 App 与 HAL。
  • PreparerThread：负责 stream 缓冲区预加载（Warm-up）。
  • FrameProcessorThread：ResultMetadata 回传处理。

1.3 HAL 层多线程模型（以 Qcom 为例）

• ISP 线程池： 图像流入后的 RAW 到 YUV/JPEG 的异步处理。
• 3A 管控线程： AE/AWB/AF 的状态更新与算法决策独立线程处理。
• SnapshotWorker： 专用于 JPEG 编码/保存的线程，避免阻塞 preview。
• Notify Thread： Result metadata 与 shutter 回调上报路径。

1.4 BufferQueue × GraphicBuffer 分发机制

• 预览与快照最终都需写入 ANativeWindow，由 BufferQueue 管理。
• 每条 stream 维护独立 BufferQueueProducer/BufferQueueConsumer 对，确保 buffer 生命周期隔离。

总结架构模型：

App → CameraX / Camera2
 ↓
CaptureSession.setRepeatingRequest (preview)
CaptureSession.capture (snapshot)
 ↓
Camera3Device.RequestThread
 ↓
CameraHAL (ISP × 3A × SnapshotWorker)
 ↓
BufferQueue → Surface / ImageReader

二、Preview / Snapshot 请求来源与提交流程差异分析

Preview 与 Snapshot 在 Android 系统中虽然都通过 CaptureRequest 驱动，但在 请求来源、调度机制、生命周期管理等方面存在本质差异：

2.1 Preview 请求（RepeatingRequest）

• 发起者： CameraCaptureSession.setRepeatingRequest() 持续发起。
• 特性： 周期性提交、低延迟、数据写入 Preview Surface。
• 适用流： 通常是格式为 YUV_420_888 的 preview stream。
• 调度策略： request 被放入队列后自动调度；每帧间隔固定。

cameraCaptureSession.setRepeatingRequest(previewRequest, previewCallback, handler);

2.2 Snapshot 请求（Capture）

• 发起者： CameraCaptureSession.capture()，一次性发起。
• 特性： 拍照前通常等待 3A 收敛（AE/AF/Flash），含 JPEG 编码，延迟较高。
• 适用流： 绑定 ImageReader 的 JPEG 输出流，buffer 数量有限。
• 调度策略：
  • 阻断性： 会阻塞 repeating 请求，进入「拍照优先」模式；
  • 精准性： 需命中「最佳帧」（如 ZSL 快门帧、AF 成功帧）；
  • 回调链路： shutter → buffer ready → JPEG 完成 → result metadata。

cameraCaptureSession.capture(captureRequest, captureCallback, handler);

2.3 请求路径差异对比（逻辑流）

2.4 冲突与协同问题

• 快照请求发出后需抢占 Preview 流：需等当前 ISP 队列 drain。
• 若未处理好同步机制，易出现：
  • 卡帧：preview 帧冻结；
  • 曝光异常：AE 尚未稳定就提交 snapshot；
  • buffer 泄漏：snapshot 未回收导致 queue full。

三、Request 队列调度机制：线程互斥 × 顺序保障 × 冲突协调

在 Camera HAL3 架构中，所有的 CaptureRequest 都需由核心调度线程 RequestThread 统一处理，以确保请求下发的 顺序一致性 与 线程安全性。尤其在 Preview（持续请求）与 Snapshot（抢占式请求）并存的场景下，系统需要一套明确的请求调度机制，以保障数据正确性与拍照成功率。

3.1 核心调度线程结构

模块：Camera3Device::RequestThread

• 内部结构：
  • mRepeatingRequests: 保存 Preview 循环请求组
  • mRequestQueue: 保存 Snapshot、非重复请求（FIFO）
  • mActiveRequest: 当前下发中的 request
  • mRequestLock: 请求队列互斥锁

3.2 请求队列填充策略

• Preview 请求在启动时由 setRepeatingRequest() 注入 mRepeatingRequests
• 拍照请求通过 capture() 方法插入 mRequestQueue
• 每次执行请求发送前，线程按以下优先级提取：

if (!mRequestQueue.empty()) {
    // 优先执行单帧快照等高优先级请求
    nextRequest = mRequestQueue.front();
    mRequestQueue.pop_front();
} else if (!mRepeatingRequests.empty()) {
    // 否则执行 repeating preview 请求
    nextRequest = mRepeatingRequests[repeatingIndex++ % size];
}

3.3 请求互斥与阻塞机制

• 为保证拍照精度，执行 TEMPLATE_STILL_CAPTURE 类型请求时，系统会短暂阻断 repeating request 的下发
• 若 mRequestQueue 中请求未被及时处理，Preview 会暂停，CameraX 层会收到帧率下降或预览卡顿信息。

3.4 异常调度场景

四、Frame Number 分发与拍照帧精确命中策略

为了确保 拍照快门命中理想帧（如对焦完成帧、曝光正常帧、ZSL 缓存帧），Camera 框架通过精确的 FrameNumber 管理机制来绑定 Request 与返回结果。

4.1 FrameNumber 生成规则

每个请求由 Camera3Device 统一编号，递增 frame number：

request->mResultExtras.frameNumber = mNextFrameNumber++;

• Preview 每帧自动编号
• Snapshot 明确绑定 frameNumber，并标记其类型（如 STILL_CAPTURE）

4.2 拍照帧的“命中”逻辑

• 快照请求通常带有延迟提交策略，如等待 AF trigger 完成或 AE 收敛。
• CameraX 层会使用如下机制确保“合适帧”：

cameraControl.triggerAf()
cameraCaptureSession.capture(captureRequest, callback)

• 系统在拍照请求前插入 Trigger 请求 + Capture 请求组：
  • Request[T1]: AF trigger
  • Request[T2]: AE trigger
  • Request[T3]: Still Capture（标记快门帧）

4.3 HAL 层帧捕获流程

• Sensor → ISP 输出图像 → HAL 中帧缓存 → 触发 Shutter Notify → 绑定 Frame Number
• HAL 需返回：
  • ShutterNotify(frameNumber, timestamp)
  • CaptureResultMetadata(frameNumber)
  • ImageBuffer(frameNumber)

这样上层就可通过 Frame Number 找到：

哪一帧是真正被拍下来的快照帧。

4.4 ZSL 下的精确帧挑选（预告）

在启用 ZSL（Zero Shutter Lag）机制后，FrameSelector 会挑选「已经缓存过的帧」中最合适的那一帧回传：

• 帧候选池：ZSL 流中预览帧按时间排序缓存
• 命中规则：
  • 快门时间 ≤ 帧 exposureTime ≤ 超时时间
  • AE/AF 状态满足要求
• 被选中帧的 frameNumber 直接转入 Snapshot 返回路径

小结：

Preview 与 Snapshot 的同步核心不在“是否并发”，而在于：

• 请求调度是否能正确切换优先级；
• 请求编号能否精准命中 shutter 帧；
• HAL 能否在高并发下安全缓存、及时回调。

五、AE / AF / Flash 状态同步机制：管线协作的时序依赖点

在拍照过程中，为了获取最佳成像质量，相机系统必须确保 自动曝光（AE）、自动对焦（AF） 和 闪光灯（Flash）控制 在拍照快门触发前协同完成。这三者在 Camera2/HAL3 架构中各自有状态管理，并通过 CaptureResult + CameraMetadata 回传状态，由上层判定是否可以进行 Capture。

5.1 状态控制流程分层结构

• App 层：
  • 调用 CameraControl.triggerAf(), enableTorch(), capture()
  • 管理拍照节奏：何时等待、何时发起请求
• CameraX / Camera2层：
  • 将 AE/AF/Flash 参数注入 CaptureRequest.Builder
  • 注入 trigger 字段（如 CONTROL_AF_TRIGGER_START）
  • 使用多帧组合（Trigger + Capture）控制拍照节奏
• HAL3 层：
  • AE/AF 状态在 CameraMetadataResult 中上报
  • Shutter 触发与 Flash 驱动联动，精确到帧

5.2 状态依赖图示（典型流程）

[Start AF Trigger] → [AF 状态: Scanning] → [AF 状态: Focused] →  
[Start AE Trigger] → [AE 状态: Converged] →  
[Shutter Trigger] → [Flash 激活（如需）] → [图像输出]

• AE/AF 完成前，不能进行 Still Capture
• Flash 决定于 AE 的 aeState 与 flashMode 参数组合（自动 vs 开启 vs 关闭）

5.3 拍照前的状态阻塞逻辑（以 CameraX 为例）

cameraControl.setCaptureRequestOptions {
    it[CaptureRequest.CONTROL_AE_MODE] = AE_MODE_ON_AUTO_FLASH
    it[CaptureRequest.CONTROL_AF_MODE] = AF_MODE_CONTINUOUS_PICTURE
}

cameraControl.triggerAf()
cameraControl.capture(request) // 会阻塞至 AE + AF ready

CameraX 内部有 CaptureCallbackChecker 判断：

• 如果 AE = CONVERGED
• AF = FOCUSED
• Flash = READY

才允许发送最终拍照请求。

5.4 闪光灯帧同步机制（Torch vs PreFlash）

• Torch Mode：持续开启，不与快门绑定
• PreFlash + MainFlash：
  • PreFlash：用于 AE 测光
  • MainFlash：绑定于 shutter 帧，精确由 HAL 控制 GPIO 驱动时序

错误同步的后果可能包括：

• AE 未完成导致曝光严重偏差
• AF 未锁定导致成像模糊
• Flash 时序不匹配导致画面黑场或过曝

六、Buffer 分配与释放策略：双流共享下的内存冲突避免机制

Preview 与 Snapshot 同时运行时，由于共享同一 Sensor 输出通道、部分 ISP 路径与图像 BufferPool，系统必须精细地管理 buffer 的分配与生命周期，避免冲突与资源耗尽。

6.1 双流结构下的 Buffer 类型分布

两条管线在同一时刻均可能请求图像 buffer，如处理不当会出现：

• BUFFER_TOO_LATE
• BUFFER_IN_USE
• JPEG 编码线程阻塞，导致前后帧跳帧

6.2 Buffer 生命周期示意（Snapshot）

[Allocate] → [Sensor Capture] → [HAL 处理] →  
[Shutter Trigger] → [JPEG 编码] → [Release To Pool]

• 在 Shutter 帧确认前，Snapshot buffer 不可释放
• JPEG 编码完成前，buffer 被 Encoder thread 持有

6.3 实践中常见冲突处理策略

6.4 MTK/Qcom 平台差异点（实际适配注意）

总结：

Preview 与 Snapshot 的同步不是简单线程并发，而是：

• 依赖 AE/AF/Flash 三者状态的正确联动；
• 要求 Request 调度 + Buffer 生命周期配合严谨；
• 平台差异大，需针对 Qcom/MTK/海思做适配优化。

七、HAL 层快照实现结构：触发、阻塞与回传流程拆解

在 HAL3 架构中，Snapshot 是一个精确控制的同步动作，它的实现涉及请求判断、3A 状态确认、buffer 申请、Shutter 触发与 JPEG 编码多个阶段。系统需要确保该流程在最短时间内闭环完成，并避免对 Preview 管线造成冲击。

7.1 快照触发路径：从 CaptureRequest 到 Shutter 回调

典型调用链如下：

App 层 → CameraDevice.capture() →
CameraService::submitCaptureRequest() →
Camera3Device::processCaptureRequest() →
Camera3HAL::process_capture_request() →
HAL 回调 notify (SHUTTER) → capture_result

其中关键处理：

• process_capture_request() 接收 CaptureRequest，识别是否为拍照流（包含 JPEG output）
• 若开启 ZSL，FrameSelector 会选择合适的缓存帧替代实时抓拍
• 传递到 HAL 后，由 HAL 内部同步触发快门并采集图像

7.2 拍照帧的阻塞控制：顺序与时序保障

• HAL 层调用时需等待 sensor + ISP pipeline 就绪；
• 多数平台会在 HAL 内使用锁或信号量屏障，阻塞当前线程，直到：
  • Frame metadata 采集完成（AE/AWB/FACE）
  • JPEG 编码完成（或传给 HW encoder）

典型场景如下（以 Qcom HAL 为例）：

// JPEG encoding block
pthread_mutex_lock(&jpeg_mutex);
wait_for_jpeg_done(); // 编码结束再解锁
pthread_mutex_unlock(&jpeg_mutex);

• 若编码线程阻塞过久，可能造成前后帧跳帧、ANR 或 buffer pool 枯竭

7.3 回传路径与 Timing 回调点

拍照流程中包含 2 个关键回调：

多个平台对 Shutter 的回调行为不同：

• Qcom：精确触发时间绑定 sensor VSync
• MTK：依赖 ISP pipeline 输出完成标志
• 海思：自研快门信号控制，附带 GPIO 驱动控制 Flash timing

八、实战调优建议：多线程异常处理 × 快门延迟缩减 × Metadata 对齐技巧

Snapshot 与 Preview 的并发处理，最容易出现的问题包括：

• 请求调度失控，导致帧号错位
• buffer 泄漏或提前释放，导致图像不一致
• 快门延迟大，体验不佳
• Metadata 对不上帧，AI 后处理失败

8.1 异常处理建议

8.2 快门延迟优化点

8.3 Metadata 对齐技巧

• 使用 android.control.frameNumber 显式比对返回帧
• 遇到输出乱序平台（如异构 ISP）需做排序回调
• 若使用 AI 后处理模块（如美颜、去模糊），强依赖：
  • AF_DISTANCE
  • AE_EXPOSURE_TIME
  • LENS_STATE 等对齐的 metadata

如未对齐，易出现模型行为偏移、去模糊失败等问题。

总结：

Preview × Snapshot 的多线程协同，实质是：
管线同步 + 请求节奏调控 + buffer 生命周期封闭管理 的综合挑战。

原文：https://zhxin.blog.csdn.net/article/details/149726562