2. 高通Camera HAL架构概览：mm-camera架构、CamX/CHI架构的核心组件与数据流
高通平台的Camera HAL架构经历了从传统的mm-camera到新一代CamX/CHI的演进。理解这两代架构的核心组件与数据流，是进行跨平台移植的基础。本章将深入剖析这两套架构的设计哲学、模块划分以及关键的Buffer与Metadata流转路径。
2.1 传统mm-camera架构
mm-camera（Multimedia Camera）是高通在Android早期到Android 8.x时代广泛使用的HAL架构。它采用 monolithic（单体）设计，所有核心逻辑集中在用户空间的mm-camera进程中。
2.1.1 核心组件
| 组件名称 | 进程/位置 | 核心职责 |
|---|---|---|
| mm-camera | 用户空间守护进程 | 统一管理所有Camera设备，处理ISP配置、Stream on/off、3A控制等核心逻辑。 |
| camera_module | HAL层 (libcamera_client) | 实现camera_module_t接口，负责枚举Camera、打开/关闭设备。 |
| qcamera | HAL层 (libcamera_client) | 实现camera_device_t接口，作为HAL与mm-camera进程的桥梁，通过Socket通信。 |
| ISP (Image Signal Processor) | 内核驱动 / 硬件 | 处理RAW数据，执行Bayer、Demosaic、降噪、色彩校正等硬件加速操作。 |
| Sensor Driver | 内核驱动 | 控制图像传感器（如IMX586、OV64B）的寄存器、帧率、曝光时间等。 |
2.1.2 数据流与架构图
在mm-camera架构中，数据流是典型的“HAL → mm-camera守护进程 → 内核驱动”模式。HAL层通过Socket向mm-camera发送命令，mm-camera解析后通过V4L2或私有IOCTL与内核交互。
关键特征：所有Camera逻辑（包括3A、统计、后处理）都在一个进程中完成，调试方便，但扩展性差，修改一个Sensor可能导致整个进程重启。
2.2 新一代CamX/CHI架构
从Android 9开始，高通力推CamX (Camera eXtension) 和 CHI (Camera Hardware Interface) 架构。这是一套模块化、可配置、跨平台的架构，旨在解决mm-camera的扩展性痛点。
2.2.1 核心组件
| 组件名称 | 类型 | 核心职责 |
|---|---|---|
| CamX HAL | 核心HAL库 | 实现Android Camera HAL3接口，管理Pipeline、Session、Request的生命周期。 |
| CHI (Camera Hardware Interface) | 配置/驱动框架 | 提供统一的硬件抽象接口，通过XML/JSON配置文件描述Sensor、ISP、TFE等硬件特性。 |
| Usecase | 逻辑模块 | 定义特定的拍照/录像场景（如Preview、HDR、Portrait），组合不同的Node。 |
| Node | 处理单元 | 最小的功能单元，如“Bayer处理Node”、“YUV转换Node”、“Face Detection Node”。 |
| Pipeline | 执行链路 | 由多个Node串联或并联组成，负责处理从Sensor到最终输出Buffer的完整链路。 |
| CSL (Camera Services Layer) | 底层服务 | 封装内核驱动接口，提供Buffer管理、Sync、IOCTL等基础服务。 |
2.2.2 数据流与架构图
CamX/CHI的数据流是“Request驱动”的。APP下发Capture Request，CamX解析后创建Pipeline，Pipeline中的Node依次处理，最终将结果Buffer返回给APP。Metadata（如3A结果）通过CHI定义的Pipeline Descriptor在Node间传递。
移植关键点：从mm-camera移植到CamX/CHI，本质上是将硬编码的Sensor/ISP配置，迁移到CHI的XML/JSON配置文件中。Node的算法逻辑可以复用，但接口必须适配CamX的Node API。
2.3 mm-camera 与 CamX/CHI 架构对比
下表总结了两种架构在关键维度上的差异，帮助理解移植工作的本质。
| 对比维度 | mm-camera | CamX / CHI |
|---|---|---|
| 设计哲学 | Monolithic（单体），所有逻辑集中 | Modular（模块化），可插拔Node |
| 配置方式 | 硬编码C代码 / 私有结构体 | XML / JSON 配置文件驱动 |
| 进程模型 | 单一守护进程 (mm-camera) | 多Pipeline、多Session，可并行 |
| 扩展性 | 差，新增Sensor需修改核心逻辑 | 好，新增Sensor只需添加配置文件 |
| 调试难度 | 相对简单，单进程单线程 | 复杂，涉及多Node、多Pipeline交互 |
| 性能开销 | 较低，但瓶颈在单进程 | 较高，但可通过Node并行优化 |
| 高通支持状态 | 已停止更新（Legacy） | 当前主力架构（Active） |
移植陷阱：在mm-camera中，Sensor的初始化序列（如PLL配置、曝光行设置）通常写在
sensor_init()函数里。移植到CamX/CHI时，这些序列必须被拆解成CHI配置中的Register Settings，并关联到对应的Node。如果直接复制粘贴C代码到Node中，会导致架构混乱，无法利用CHI的配置化优势。
2.4 关键数据流：Buffer与Metadata
无论哪种架构，Camera HAL的核心数据流都围绕Buffer（图像数据）和Metadata（控制/状态数据）展开。在CamX/CHI中，这两者的管理更加精细。
2.4.1 Buffer流
- Source: Sensor通过CSI接口输出RAW数据到ISP。
- Processing: ISP处理后的数据进入Pipeline，经过Bayer、Scaler、Crop等Node。
- Destination: 最终YUV/JPEG Buffer通过Gralloc或ION内存传递给HAL，再返回给APP。
2.4.2 Metadata流
- Request Metadata: APP下发的控制参数（AE target、AWB mode、AF region）。
- Result Metadata: 硬件/算法产生的状态信息（AE convergence、AWB gain、AF state）。
- Pipeline Metadata: Node之间传递的中间结果（如统计信息、HDR融合权重）。
移植经验：在MTK平台，Metadata的管理通常使用P1/P2（Pass1/Pass2）机制，与高通的Pipeline Descriptor概念类似。理解高通Metadata的Tag ID与MTK的Feature ID之间的映射关系，是移植Metadata处理逻辑的核心工作。