高通CamX架构解析（一）—— Camera HAL3接口与CamX-CHI框架设计-CSDN博客

1. 从HAL3接口到CamX-CHI：一次跨越边界的旅程

大家好，我是老张，在手机影像系统这块摸爬滚打了十几年，从最早的V4L2驱动调校，到后来深度参与高通平台的相机框架开发，算是见证了Android相机架构的整个演进过程。今天想和大家聊聊高通CamX架构，特别是它的入口——HAL3接口与CamX-CHI框架的设计。如果你正在为Camera HAL的复杂性头疼，或者想了解一个现代手机相机系统到底是如何运作的，那这篇文章应该能给你一些启发。

我记得最早接触Android相机时，HAL层还是个“黑盒子”，各家厂商的实现五花八门，调试起来简直是一场噩梦。后来谷歌推出了HAL3标准，情况好了不少，但平台厂商（比如高通）的具体实现依然复杂。高通从旧的MM-Camera架构切换到CamX-CHI，核心目标就是解耦和可扩展。简单来说，CamX负责所有通用、稳定的底层操作（比如和内核驱动V4L2打交道），而CHI（Camera Hardware Interface）则留给手机厂商去定制自己的图像处理流水线和算法。这种设计有点像把相机系统分成了“基础底盘”和“上层车身”，底盘高通做好，车身你自己来设计。

那么，这一切的起点在哪里？就在Camera HAL3接口。当你在相机App里按下快门，这个动作会经过Android Framework、Camera Service，最终通过一个叫Camera Provider的独立进程，调用到HAL3的标准接口上。而CamX-CHI，就是高通对这些标准接口的具体实现。理解这两者如何对接，是读懂整个CamX架构的关键。

2. HAL3接口：谷歌制定的“交通规则”

要理解CamX，必须先搞懂HAL3。你可以把HAL3想象成谷歌为所有Android手机相机硬件制定的一套“交通规则”。无论你是高通、联发科还是其他芯片平台，只要想在Android上跑相机，就必须遵守这套规则。这套规则的核心，是一系列定义好的结构体和函数指针。

2.1 核心结构体：模块与设备的抽象

HAL3定义了两个最基础的结构体：hw_module_t 和 hw_device_t。这其实是Android HAL层的通用设计，不只是相机，音频、传感器等硬件模块也这么玩。

// 硬件模块的通用描述
typedef struct hw_module_t {
    uint32_t tag; // 必须为'HW_M_TAG'
    uint16_t module_api_version;
    const char *id; // 模块ID，例如 "camera"
    const char *name;
    const char *author;
    struct hw_module_methods_t* methods; // 关键：打开设备的方法
    void* dso;
    // ... 其他保留字段
} hw_module_t;

// 硬件设备的通用描述
typedef struct hw_device_t {
    uint32_t tag; // 必须为'HW_D_TAG'
    struct hw_module_t* module;
    uint32_t version;
    int (*close)(struct hw_device_t* device); // 关闭设备的函数
    // ... 其他字段由具体硬件扩展
} hw_device_t;

对于相机，谷歌在这两个通用结构体基础上，扩展出了 camera_module_t 和 camera3_device_t。camera_module_t 代表整个相机硬件模块，它内部包含了一个 hw_module_t，并增加了相机特有的方法，比如 get_number_of_cameras（获取摄像头数量）、set_callbacks（设置回调）。当系统启动Camera Provider进程时，就会通过标准的 hw_get_module 函数，根据ID（"camera"）找到并加载这个模块。

而 camera3_device_t 则代表一个具体的摄像头设备（比如后置主摄、前置摄像头）。它内部包含一个 hw_device_t，并扩展了一个极其重要的成员：camera3_device_ops_t *ops。这个 ops 是一个函数指针表，里面包含了所有控制相机、处理图像请求的核心方法，比如 initialize、configure_streams、process_capture_request。CamX-CHI框架最核心的任务，就是实现这个 ops 表里的每一个函数。