2、Camera HAL 基础回顾：HAL3 架构、Pipeline、Stream、Buffer、Request 核心概念

在深入多路 Stream 并行捕获配置之前，必须牢固掌握 Camera HAL3 的核心抽象。HAL3 接口（Android 7.0+ 强制）将 Camera 子系统从传统的“黑盒”模式重构为 Pipeline + Request 的显式控制模型。本节将逐一拆解 HAL3 架构、Pipeline、Stream、Buffer 和 Request 这五个基石。

2.1 HAL3 整体架构

HAL3 位于 Android Camera Framework（CameraService / CameraDevice）与底层 Camera 硬件驱动（Kernel / Sensor / ISP）之间。其核心设计哲学是 “一次配置，多次请求”：通过 configure_streams() 建立固定的数据通路（Pipeline），然后通过重复提交 capture() / flush() 请求来驱动数据流动。

2.2 Pipeline：数据通路抽象

Pipeline 是 HAL3 中 从 Sensor 输出到最终输出 Buffer 的完整处理链路。每个 Pipeline 对应一个固定的硬件处理路径（例如：主摄 → ISP → 缩放模块 → JPEG 编码器）。

• 物理 Pipeline： 直接映射到硬件 ISP 通道，每个物理 Camera 设备通常包含 1~3 条物理 Pipeline。
• 逻辑 Pipeline： 在多摄（Multi-Camera）场景下，Framework 可以将多个物理 Pipeline 组合为一个逻辑 Pipeline，实现无缝变焦或 Fusion。
• Pipeline 特征： 分辨率限制、帧率限制、格式支持、处理延迟（Pipeline Latency）。

2.3 Stream：输出数据通道

Stream 是 HAL3 中 描述输出数据格式、分辨率、用途的通道定义。每个 Stream 对应一个 camera3_stream_t 结构体，在 configure_streams() 时一次性配置。

2.4 Buffer：数据载体

Buffer 是 Stream 中实际承载图像数据的 内存块，通过 Gralloc 分配。HAL3 使用 Dequeue / Enqueue 模型管理 Buffer 生命周期。

• Buffer 分配时机： 在 configure_streams() 时，HAL 通过 camera3_stream_t.max_buffers 告知 Framework 需要预分配的 Buffer 数量。
• Buffer 流转路径： Framework 从 Stream 的 BufferQueue 中 Dequeue 空闲 Buffer → 填充到 Request 中 → HAL 填充数据 → Framework 将 Buffer 送给消费者（SurfaceView / MediaCodec / ImageReader）。
• Buffer 复用： 在多路并行场景下，同一个物理 Buffer 可以被多个 Stream 共享吗？不可以。每个 Stream 拥有独立的 Buffer 队列，即使分辨率相同，也必须分配独立的 Buffer 实例。

2.5 Request：捕获命令单元

Request 是 HAL3 中 一次捕获操作的完整描述，对应 camera3_capture_request_t 结构体。它是驱动整个 Pipeline 工作的“触发器”。

2.6 核心概念关系总结

下表总结了五个核心概念在 HAL3 多路并行捕获中的角色与关系：