2. Camera HAL架构深度解析：HAL3 vs HAL1核心差异、Pipeline模型、关键接口函数

在调试预览卡顿之前，必须深入理解Camera HAL的架构演变。HAL（硬件抽象层）是Android相机框架中连接Framework与硬件驱动的关键桥梁。本章将系统剖析HAL1与HAL3的核心差异、Pipeline模型以及关键接口函数，为后续的卡顿定位与优化打下坚实基础。

2.1 HAL1 vs HAL3：核心差异对比

Android从API Level 21（Android 5.0）开始引入HAL3接口，旨在解决HAL1在性能、灵活性和多帧处理上的局限性。两者在设计哲学上存在根本差异：HAL1是“命令式”的，而HAL3是“请求-结果式”的。

2.2 Pipeline模型：从Request到Result的旅程

HAL3的核心是Pipeline模型。每一帧的捕获都遵循一个清晰的流程：Framework下发Capture Request → HAL解析并配置硬件 → ISP处理 → 生成Capture Result返回。理解这个Pipeline是定位卡顿的关键。

2.3 关键接口函数详解

HAL3的核心接口定义在camera3_device_ops_t结构体中。以下三个函数是调试预览卡顿的“必争之地”：

2.3.1 open() 与 close()

• open()：初始化硬件设备，分配资源（如Sensor、ISP、内存池）。如果此函数耗时过长，会导致应用启动预览时出现“黑屏”或“卡死”。
• close()：释放资源，关闭设备。如果未正确同步，可能导致后续打开失败或内存泄漏。

// HAL3 open 函数原型
int (*open)(const struct hw_module_t* module, const char* id,
            struct hw_device_t** device);

// 典型实现中需要完成：
// 1. 初始化 Sensor 驱动
// 2. 分配 Stream 缓冲区池
// 3. 创建 3A 线程
// 4. 设置默认的 capture settings

2.3.2 process_capture_request() —— 卡顿调试的核心

这是每一帧的入口函数。Framework将camera3_capture_request_t传入HAL，HAL需要解析其中的metadata和buffer，并启动硬件捕获。此函数的性能直接决定预览帧率。

// HAL3 process_capture_request 函数原型
int (*process_capture_request)(const struct camera3_device *device,
                               camera3_capture_request_t *request);

// request 结构体关键字段：
// - settings: 包含 3A、AE/AWB/AF 等控制参数的 metadata
// - input_buffers: 输入 buffer（如 reprocessing 场景）
// - output_buffers: 输出 buffer 数组（预览流、拍照流等）
// - num_output_buffers: 输出 buffer 数量

2.3.3 process_capture_result() 与 notify()

• process_capture_result()：HAL通过此回调将处理完成的帧（包含metadata和填充好的buffer）返回给Framework。此回调必须尽快调用，否则会阻塞Pipeline。
• notify()：用于发送异步事件，如快门事件（SHUTTER）、错误事件（ERROR_REQUEST）等。错误事件是定位硬件故障的关键线索。

2.4 HAL1 vs HAL3 接口对比表

2.5 从HAL1迁移到HAL3的常见陷阱

1. Buffer管理差异： HAL1中HAL自己管理buffer，HAL3中Framework通过dequeue_buffer提供buffer。如果HAL3实现中错误地持有了buffer超过一帧时间，会导致Framework端buffer饥饿，引发卡顿。
2. 3A状态机同步： HAL3允许逐帧修改3A参数，但硬件3A状态机可能无法快速响应。如果连续下发冲突的AE/AWB参数，可能导致ISP内部重配置，造成帧率抖动。
3. 多流并发： HAL3支持同时输出预览流和拍照流。如果HAL内部没有为每个流分配独立的ISP处理通道，会导致资源争抢，表现为预览帧率下降。