Camera HAL稳定性问题从压力测试到故障排查 - 第1节

1.1 Camera HAL 架构概述：HAL3 vs HAL1 架构对比

Camera HAL（硬件抽象层）是 Android 相机系统中连接 Framework 与底层硬件驱动的关键中间层。HAL 的设计直接决定了相机的启动速度、预览延迟、拍照吞吐量以及系统稳定性。本章首先对比 HAL1 与 HAL3 两种架构的核心差异，帮助学员建立架构层面的全局认知。

1.1.1 HAL1 架构：传统同步模型

HAL1 是 Android 早期（API 21 之前）采用的相机 HAL 架构，其核心特征是同步操作与单一 Pipeline。应用层每次发起预览或拍照请求后，HAL 层必须等待硬件完成处理并返回结果，才能继续下一个请求。这种串行模型在低分辨率、低帧率场景下尚可工作，但在高帧率、多路并发场景下极易出现瓶颈。

1.1.2 HAL3 架构：异步 Pipeline 模型

HAL3 引入了一套完整的异步请求-结果模型，允许应用层同时向 HAL 提交多个 capture request，HAL 内部通过多 Pipeline 并行处理，结果可以乱序返回。这种设计大幅提升了相机吞吐量，但也带来了更复杂的同步与资源管理挑战。

HAL3 的核心设计原则包括：

• 请求驱动：每个 capture request 独立描述输出 buffer、3A 参数、物理 camera 等。
• 结果回调：通过 process_capture_result 回调异步返回 metadata 和 buffer。
• Pipeline 深度可配置：通过 android.request.pipelineMaxDepth 控制并发请求数。
• Buffer 所有权转移：HAL 通过 dequeue_buffer/queue_buffer 管理 buffer 生命周期。

1.2 Pipeline 模型详解

Pipeline 是 HAL3 架构中最重要的抽象概念。一个 Pipeline 代表一条从 sensor 到 output buffer 的完整数据处理链路。HAL3 允许同时存在多个 Pipeline，每个 Pipeline 可以独立配置分辨率、帧率、格式等参数。

1.2.1 单 Pipeline vs 多 Pipeline

Pipeline 模型的核心接口包括：

• configure_streams：配置所有 Pipeline 的 stream 集合，包括分辨率、格式、usage flag。
• process_capture_request：向指定 Pipeline 提交一个 capture request。
• flush：清空所有 Pipeline 中待处理的请求，用于快速关闭或切换场景。

1.3 核心接口介绍

HAL3 的核心接口定义在 camera3_device_ops_t 结构体中。以下三个接口是稳定性测试与故障排查的重点关注对象。

1.3.1 open / close

open 接口负责初始化 HAL 设备、分配资源、启动 sensor 和 ISP。稳定性测试中，open 的常见问题包括：

• 资源泄漏：每次 open 后未释放上一次的 DMA buffer。
• 死锁：open 内部等待某个硬件信号量超时。
• 重复 open：未做幂等保护，导致 double open 后状态混乱。

close 接口负责释放所有资源。稳定性测试必须验证：

• 连续 open/close 1000 次后系统内存无增长。
• close 后所有 buffer 已归还给 Gralloc。
• close 过程中被中断（如 kill -9）后再次 open 能正常工作。

// HAL3 open 接口典型实现框架
int camera3_open(const struct hw_module_t* module,
                 const char* id,
                 struct hw_device_t** device) {
    camera3_device_t* dev = (camera3_device_t*)malloc(sizeof(camera3_device_t));
    if (!dev) return -ENOMEM;

    // 初始化 ops 表
    dev->ops = &g_camera3_device_ops;

    // 初始化内部状态
    dev->priv = new CameraDevice(id);
    if (!dev->priv) {
        free(dev);
        return -ENOMEM;
    }

    *device = &dev->common;
    return 0;
}

1.3.2 process_capture_request

这是 HAL3 中最核心、最复杂的接口。每个 capture request 包含：

• frame_number：帧序号，用于结果排序。
• settings：3A 参数、AE/AWB/AF 模式等 metadata。
• output_buffers：目标 buffer 数组，每个 buffer 指定 stream、handle、acquire fence。
• input_buffer：用于 reprocess 场景（如 ZSL）的输入 buffer。

稳定性测试中，process_capture_request 的典型故障模式包括：

1.4 HAL3 核心架构图

下图展示了 HAL3 架构中 Framework、HAL、硬件三层之间的核心交互流程，重点标注了 process_capture_request 的异步路径与 buffer 流转关系。

1.5 本章小结

本章从架构层面对比了 HAL1 与 HAL3 的核心差异，重点剖析了 HAL3 的 Pipeline 模型与三个核心接口。学员需要掌握以下关键知识点：

• HAL1 的同步模型在高帧率场景下存在固有瓶颈，HAL3 的异步模型是当前主流方案。
• Pipeline 是 HAL3 的核心抽象，多 Pipeline 并发是提升吞吐量的关键，但也增加了稳定性风险。
• open/close 接口的稳定性测试必须覆盖资源泄漏、死锁、重复操作等场景。
• process_capture_request 的故障排查需要关注 request 丢失、buffer 未返回、metadata 错误、乱序返回四类问题。