98.Camera2 API 与 Legacy HAL 的兼容性方案：架构演进中的桥接实践

Camera2 API 与 Legacy HAL 的兼容性方案：架构演进中的桥接实践

关键词 ：
Camera2 API、Legacy HAL、兼容性、CameraService、HAL1 Adapter、架构演进、适配策略、性能瓶颈

摘要 ：
尽管 Android Camera2 API 自 Android 5.0 起已成为标准接口，但在实际设备中，仍存在大量使用 Legacy HAL（即 HAL1）的硬件平台。为确保新旧平台间的平滑过渡，Android CameraService 引入了 HAL1 Adapter 模式，使 Camera2 API 能兼容旧版 HAL 接口，避免因驱动更新成本高昂而阻碍 Camera Framework 升级。本文从系统架构、接口转换、适配策略、性能差异与工程实践等维度出发，详细解析 Camera2 API 与 Legacy HAL 的兼容性实现路径与调试技巧。

目录：

一、架构背景：为何需要兼容 Legacy HAL
二、CameraService 中的 HAL 类型判定与接口绑定流程
三、HAL1 Adapter 模块结构与请求映射机制
四、CameraMetadata 的双向转换逻辑与参数映射
五、拍照流程中的关键路径适配策略（open → request → result）
六、预览与流配置的限制与优化点
七、性能瓶颈分析与优化路径（延迟、帧率、对焦）
八、实战调试建议与开发中常见问题汇总

一、架构背景：为何需要兼容 Legacy HAL

Android Camera 架构自 Android 5.0（Lollipop）引入 Camera2 API 起，逐步实现了从原有 Camera API（即“Legacy API”）向现代、模块化、可扩展的图像处理系统的过渡。Camera2 API 带来了诸如全面的帧控制（request/result）、管线分离、同步元数据、多摄支持等关键特性，极大增强了 Android 平台的图像处理能力。然而，在 Camera2 推出初期及之后相当长时间内，大量硬件平台仍然基于旧版 Camera HAL（HAL1）构建，难以快速完成 HAL 升级。这也就催生了一个现实且重要的工程挑战：

如何在系统框架层使用 Camera2 的新能力，同时保持对 Legacy HAL 的兼容支持？

为解决这一问题，Android Camera 架构引入了 HAL1 Adapter 模式 ，允许 CameraService 自动判断 HAL 类型并加载对应的转换模块，将 Camera2 请求与 HAL1 能力之间做桥接。这个机制使得厂商无需立即升级 HAL 驱动，也能逐步享受 Camera2 带来的部分架构收益，兼顾系统一致性与开发成本控制。

1. HAL1 与 HAL3（即现代 HAL）的核心差异

2. 为什么不能立即淘汰 Legacy HAL

尽管 HAL3 在架构上全面优于 HAL1，但在 Android 实际部署中，以下因素制约了 HAL 全面升级：

• 驱动耦合问题 ：旧平台 HAL1 紧耦合 Sensor 驱动与 ISP 模块，升级成本高；
• 芯片厂商支持断档 ：如 MTK、高通在早期部分 SoC 上未开放 HAL3 支持；
• 认证成本高 ：HAL 升级需重新通过 CTS/VTS/HWTS 等测试；
• 产品发布周期压力 ：设备生命周期短，升级 HAL 成本难以在一代产品内回收。

因此，在系统软件层兼容旧 HAL，成为实际工程中更具性价比的选择。

3. CameraService 的 HAL 判定机制

CameraService 会在启动阶段加载 CameraProvider ，并查询当前平台支持的 Camera HAL 类型。核心判断逻辑如下：

if (deviceVersion == CAMERA_DEVICE_API_VERSION_1_0) {
    use HAL1 path
} else if (deviceVersion >= CAMERA_DEVICE_API_VERSION_3_2) {
    use HAL3 path
}

对于 HAL1 的设备，系统将通过 Camera2Client → Camera2ClientBase → Camera2ClientBase::CameraClient 中的 HAL1 Adapter 进行协议桥接。

4. HAL1 Adapter 的作用与意义

HAL1 Adapter 并非简单的接口包装，其核心职责包括：

• 转换参数模型 ：将 Camera2 的 CaptureRequest 映射为 HAL1 的参数结构体；
• 同步结果映射 ：将 HAL1 的输出结果回填到 CaptureResult 中；
• 构建 HAL1 风格的 Preview、Recording、Still 等流控制模块 ；
• 兼容 CameraDeviceClient 的连接流程、状态回调、错误处理等机制 。

这个桥接结构使得 Camera2 客户端代码几乎不需感知底层是 HAL1 还是 HAL3，屏蔽了绝大部分差异逻辑。

5. 应用层的视角：Camera2 API 是否“真的支持” Legacy？

在 App 开发者角度，只要系统支持 Camera2 接口（即 CameraManager , CameraDevice , CaptureSession 可被调用），就认为设备兼容 Camera2。但实际使用中会发现如下情况：

• 某些 request 参数设置无效（如自定义对焦、曝光锁定）；
• 不支持 RAW 格式输出；
• Preview 不支持高分辨率切换；
• metadata 中字段缺失或恒为默认值。

这正是由于底层 HAL1 的能力限制，导致 Camera2 接口在逻辑上可用、但物理上能力不全。

总而言之，Camera2 API 与 Legacy HAL 的兼容性机制体现了 Android 架构设计中的工程弹性与成本控制智慧。在多 SoC、多设备形态并存的现实环境下，建立这样一套可桥接、高可用、向前兼容的方案，是推进新架构落地的必要过渡。

二、CameraService 中的 HAL 类型判定与接口绑定流程

Android CameraService 是连接 App Framework 与 HAL 层的核心服务，其职责之一是根据设备实际所支持的 HAL 类型（HAL1 或 HAL3），在系统初始化时自动完成接口适配与功能绑定。尤其是在同时支持多类设备（如部分新机为 HAL3，部分旧机为 HAL1）的平台上，CameraService 必须对每个摄像头实例进行精确判定，并动态决定使用哪一套 HAL 适配逻辑。

本章将从 CameraService 初始化过程入手，详细拆解 HAL 类型判定的机制、版本适配策略以及接口选择流程，帮助开发者理解系统如何实现 Camera2 API 与 Legacy HAL 的无感桥接。

1. CameraService 启动与设备信息加载流程

CameraService 通常在 Android 的 SystemServer 阶段由 media.camera service 启动，核心流程如下：

CameraService::onFirstRef() {
    // 初始化 CameraProviderManager
    mCameraProviderManager.initialize(this);

    // 枚举所有摄像头
    mCameraProviderManager.getCameraDeviceIds(&mCameraIds);
    
    // 为每个 cameraId 查询其 HAL 版本
    for (const auto& id : mCameraIds) {
        auto status = mCameraProviderManager.getCameraDeviceVersion(id, &deviceVersion);
        if (deviceVersion == CAMERA_DEVICE_API_VERSION_1_0) {
            // Legacy HAL1，使用 CameraClient
        } else {
            // Modern HAL3+，使用 CameraDeviceClient
        }
    }
}

关键是： CameraProviderManager::getCameraDeviceVersion() 会从 CameraProvider 层返回每个设备对应的 API 版本，系统据此区分 HAL 类型。

2. HAL 版本的来源：Provider 报告机制

CameraProvider（无论是 AIDL 还是 HIDL）在初始化阶段需向 CameraService 报告其支持的 HAL 类型，通常通过接口：

getCameraDeviceInterface(const std::string& cameraId)
    → 返回 deviceVersion 和 metadata

这里的 deviceVersion 由 HAL 库（如 camera.qcom.so ）在注册时决定。例如：

camera_device_t::common.version = CAMERA_DEVICE_API_VERSION_1_0;

如果是 HAL1，则为 0x100 ；HAL3 则为 0x300 起跳。这个值最终通过 binder 或 hwservice 传递给 CameraService。

3. 类型判定逻辑：HAL1 vs HAL3 分支路径

在 CameraService 中，每当客户端请求连接摄像头时，如：

cameraManager.openCamera("0", callback, handler);

会被传递到服务端：

CameraService::connect(...cameraId...)

服务端根据该 cameraId 的 HAL 类型，进行如下处理：

if (deviceVersion == CAMERA_DEVICE_API_VERSION_1_0) {
    sp<CameraClient> client = new CameraClient(...);  // HAL1 path
} else {
    sp<CameraDeviceClient> client = new CameraDeviceClient(...);  // HAL3 path
}

即：HAL1 使用 CameraClient （封装了 legacy HAL 的同步 API），HAL3 使用 CameraDeviceClient （支持 request/result 流式异步模型）。

4. HAL1 Adapter 接入的具体位置

虽然 CameraDeviceClient 是标准 Camera2 的服务端实现，但在 HAL1 路径下，还会套接一层 HAL1 Adapter 模块：

Camera2ClientBase<CameraClientBase> → CameraClient
Camera2ClientBase<CameraDeviceClient> → CameraDeviceClient

该泛型模板类会根据实际 HAL 类型构造不同的控制路径：

• 对于 HAL1，会模拟 request/stream 接口，映射为同步调用；
• 对于 HAL3，则直接调用 native ICameraDeviceSession 接口。

HAL1 Adapter 主要位于 frameworks/av/services/camera/libcameraservice/api1/client2/ 目录下，是 Google 为实现 Camera2 API 兼容旧 HAL 所设计的桥接逻辑。

5. 多摄像头平台下的混合适配策略

实际平台中可能存在如下混合场景：

• cameraId=0 使用 HAL1；
• cameraId=1 使用 HAL3；
• 虚拟摄像头使用 Emulated HAL（AIDL 方式）；

此时，CameraService 会基于 每个 cameraId 单独判断版本号与能力范围 ，并构建一个 CameraState 映射表：

std::map<std::string, CameraDeviceInfo> mCameraStates;

开发者可以通过 dumpsys media.camera 查看系统所维护的每个摄像头对应 HAL 类型和加载状态。

6. 兼容性保障策略：不同 HAL 的行为约束

Android 定义了如下行为保障：

• HAL1 设备 只能提供 LIMITED 级别支持 ，即无法宣称为 FULL 或 LEVEL_3；
• HAL1 不支持并发流配置，因此 Preview + Reprocessing 的组合能力有限；
• CameraCharacteristics 中必须标注 android.info.supportedHardwareLevel = LEGACY ；
• 应用若强制请求 HAL1 不支持的控制参数，会被系统层拦截并降级处理。

这些策略保证了即便 HAL 类型不同，Camera2 API 使用体验仍具备一致性。

通过对 HAL 类型判定与接口绑定流程的动态管理，CameraService 成功实现了在同一套 Framework 架构下，对 HAL1 与 HAL3 的透明适配能力。这使 Android 能在持续演进的硬件环境中平稳过渡，同时保障系统稳定性与工程可维护性。

三、HAL1 Adapter 模块结构与请求映射机制

在 Android Camera 架构中， HAL1 Adapter 是连接现代 Camera2 API 与旧版 Camera HAL（HAL1）的桥接核心，它承担着将 Camera2 中的异步 request/result 流程，转换为 HAL1 所支持的同步调用结构。这个适配模块是 Android 为解决历史兼容性问题而精心设计的工程组件，主要集中于 Camera2ClientBase 及其子类体系中，实际运行路径位于 frameworks/av/services/camera/libcameraservice/api1/client2/ 。

本章将结合源码与实战分析，深入解析 HAL1 Adapter 的模块结构、工作职责与请求映射逻辑，揭示其在多层异构架构之间如何实现无缝调用与状态同步。

1. 结构总览：Client 模块的继承体系

Android CameraService 中 Camera2 架构下的 Client 类，采取了典型的 CRTP 模板继承模式：

template <typename TClientBase>
class Camera2ClientBase : public TClientBase {
    // 实现 HAL1/3 共用逻辑
};

针对 HAL1 与 HAL3，系统分别实例化了不同的 Client：

• HAL1 路径：

  Camera2ClientBase<CameraClientBase> → CameraClient
  
  

• HAL3 路径：

  Camera2ClientBase<CameraDeviceBase> → CameraDeviceClient
  
  

这使得两类 Client 在共享大部分 Camera2 控制逻辑的同时，具备独立的适配接口。

2. HAL1 Adapter 的主要组件

在 HAL1 模式下，Camera2ClientBase 中封装了如下核心成员：

• sp<CameraHardwareInterface> ：与 HAL1 驱动对接的接口封装（即 camera_device_t 映射）；
• RequestThread ：专门用于将 Camera2 的请求转换为 HAL1 拍照指令；
• FrameProcessorBase ：处理从 HAL1 返回的数据帧与元数据；
• StreamingProcessor ：控制 Preview 与 Video 流的组合与生命周期；
• CallbackProcessor ：实现状态回调与结果回传封装。

这些模块共同组成了 HAL1 的逻辑管线，每个模块对应 Camera2 架构中的一段控制路径。

3. 请求映射机制：从 CaptureRequest 到 HAL1 API

在 Camera2 模型下，每次拍照调用都封装为一个 CaptureRequest ，其中包含：

• 目标 Surface（预览/拍照/录像）；
• 传感器参数（如曝光时间、ISO、对焦模式）；
• 请求 ID、同步标签等。

而 HAL1 的接口是：

int (*startPreview)(struct camera_device *);
int (*takePicture)(struct camera_device *);
int (*setParameters)(struct camera_device *, const char *params);

因此，HAL1 Adapter 需要做：

1. 参数提取与转换 ：解析 CaptureRequest → 填充 CameraParameters ；
2. 同步调用控制 ：将请求压入 RequestThread ，按顺序调用 setParameters + takePicture ；
3. 状态监控与事件注册 ：通过 notifyCallback() 、 dataCallback() 接收回调；
4. 组装结果返回 ：构造 CaptureResult → 回传给 CameraDeviceClient。

举例：

// 从 CaptureRequest 提取参数
CameraMetadata metadata = request->getSettings();
CameraParameters params;
params.set(KEY_FOCUS_MODE, metadata[FOCUS_MODE]);
...

// 同步调用
hardwareInterface->setParameters(params.flatten().string());
hardwareInterface->takePicture();

4. 流控制封装：StreamingProcessor 的作用

由于 HAL1 不支持灵活的多 stream 并发（如 preview + video），系统必须通过 StreamingProcessor 模块封装对不同场景的控制策略：

• startPreview() 控制 Preview；
• startRecording() 切换到 Video 模式；
• stopPreview() , stopRecording() 控制资源释放；
• 使用 BufferQueue 管理 Surface 缓冲区，模拟 HAL3 风格的流；

该模块也负责回调 preview frame 到 SurfaceTexture ，保持图像同步。

5. 元数据构造与结果映射逻辑

HAL1 无 CaptureResult 或 CameraMetadata 返回机制，系统通过如下策略生成仿真结果：

• 预定义静态 metadata ：系统通过 XML 或代码硬编码 HAL1 能力（如 max resolution、fps）；
• 帧数据回调 hook ：在 dataCallback() 中模拟 onCaptureCompleted() ；
• 构建 CameraMetadata ：通过软解方式构造最基本的 EXIF、曝光、尺寸等信息；
• 使用 Camera3MetadataChannel 提供近似 HAL3 结构的输出接口。

这种设计虽然不能完全还原 HAL3 的精度与实时性，但对 App 层而言表现一致。

6. 生命周期管理与同步机制

HAL1 是单线程模型，Camera2 则为多线程异步，因此 Adapter 必须：

• 所有请求入队 → 串行执行；
• 状态回调封装为消息投递 → 主线程分发；
• 所有设备状态变更（如 disconnect）使用 Mutex + Condition 机制实现同步；
• 所有 RequestThread 停止需确保 HAL 状态安全、驱动已 idle。

HAL1 Adapter 模块是一种具备工程现实意义的桥接机制，确保 Camera2 在旧硬件平台上的平滑运行。它的设计理念并非“复刻 HAL3”，而是 对 HAL1 能力的上层包容性封装 ，体现了 Android 在硬件多样性下的架构弹性与向后兼容能力。

四、CameraMetadata 的双向转换逻辑与参数映射

在 Android 相机架构中， CameraMetadata 是 Camera2 API 实现请求（ CaptureRequest ）与结果（ CaptureResult ）通信的核心数据结构。而在 Legacy HAL（HAL1）中，控制与状态信息则通过 CameraParameters 字符串进行交互，参数多为 key=value; 拼接的形式。因此，为了实现 Camera2 API 与 HAL1 的兼容运行， HAL1 Adapter 必须提供一套稳定可靠的 双向参数映射机制 ，在 CameraMetadata 与 CameraParameters 之间完成序列化、反序列化与兼容性控制。

本章将深入剖析 CameraMetadata 的双向映射逻辑，包括参数提取、标准字段映射、值域控制、非对称能力补偿等，解析如何在底层能力受限的情况下，通过工程手段实现高层接口的语义一致性。

1. HAL1 与 HAL3 的参数结构差异

因此，HAL1 Adapter 的核心任务就是 在这两个语义和格式完全不同的系统之间搭建桥梁 。

2. 请求方向映射：CaptureRequest → CameraParameters

HAL1 不理解 CaptureRequest ，所以在 Adapter 中，系统需将每帧请求的 Metadata 翻译为字符串格式的 CameraParameters 。

映射流程：

status_t RequestThread::mapRequestToParameters(const CaptureRequest& request) {
    CameraParameters params;

    // 1. 曝光控制
    if (metadata.exists(ANDROID_SENSOR_EXPOSURE_TIME)) {
        int64_t exposure = metadata[ANDROID_SENSOR_EXPOSURE_TIME][0];
        params.set("exposure-time", String8::format("%lld", exposure));
    }

    // 2. 对焦模式
    if (metadata.exists(ANDROID_CONTROL_AF_MODE)) {
        int afMode = metadata[ANDROID_CONTROL_AF_MODE][0];
        params.set("focus-mode", convertAfModeToLegacyString(afMode));
    }

    // 3. 闪光灯控制
    if (metadata.exists(ANDROID_FLASH_MODE)) {
        ...
    }

    // 4. 分辨率 / 画幅裁剪
    if (metadata.exists(ANDROID_SCALER_CROP_REGION)) {
        ...
    }

    // 5. 设置完整参数
    mHardwareInterface->setParameters(params.flatten());
}

映射特点：

• 基于已有 Metadata 的 Key → Value 逐项提取；
• 使用厂商适配函数将枚举值转换为 HAL1 识别的字符串；
• 对 HAL1 不支持的字段，需选择默认值或静默忽略。

3. 结果方向映射：CameraParameters → CaptureResult

HAL1 不支持每帧结果，因此 HAL1 Adapter 通常在以下场景生成 CaptureResult ：

• 调用完成后从 CameraParameters 获取状态快照；
• 从回调数据中补充生成部分关键字段（如尺寸、时间戳）；
• 构造 CaptureResultExtras 用于通知帧号、序列 ID 等。

status_t FrameProcessor::generateCaptureResult(...) {
    CameraMetadata result;

    // 1. 曝光时间、帧率等
    const char* exposure = mHardwareInterface->getParameters().get("exposure-time");
    result.update(ANDROID_SENSOR_EXPOSURE_TIME, &parsedValue, 1);

    // 2. 对焦状态（模拟）
    result.update(ANDROID_CONTROL_AF_STATE, &afState, 1);

    // 3. 填充 result 回调结构体
    notifyCaptureResult(result, frameNumber);
}

注意事项：

• HAL1 中部分字段无法获取（如 ISP Gain、OIS 信息）；
• 需要在回调线程中同步构造结果，避免拍照完成无反馈；
• 对于定时拍照、连拍等需手动生成帧号与拍照时间戳。

4. 非对称参数映射与能力补偿策略

由于 HAL1 的能力有限，Adapter 必须执行一套“语义补偿”机制，来模拟 HAL3 体验：

这套映射策略保证了上层 Camera2 客户端在使用时，尽可能不需要感知底层能力差异。

5. 如何识别当前设备是否为 HAL1 + LEGACY

应用层可以通过如下方式检查设备兼容性：

CameraCharacteristics characteristics = cameraManager.getCameraCharacteristics("0");
Integer level = characteristics.get(CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL);

if (level == CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL_LEGACY) {
    // 当前设备使用 HAL1
}

此外，开发者也可通过 adb shell dumpsys media.camera 查看 HAL 类型字段。

通过系统化的参数映射与逻辑桥接，CameraMetadata 与 CameraParameters 的转换机制保障了 Camera2 API 与 HAL1 的基础兼容能力。尽管能力受限，但 HAL1 Adapter 的设计仍允许在不升级驱动的前提下，实现较为现代的拍照体验。

五、拍照流程中的关键路径适配策略（open → request → result）

在 Android Camera2 架构中，拍照操作是一系列高度解耦的异步控制链路，从 App 层调用 openCamera() 、配置 CaptureRequest ，到 HAL 返回 CaptureResult ，形成了完整的请求控制链（Control Flow）与图像数据链（Data Flow）。然而，在 Legacy HAL（HAL1）中，这一链路是同步、不可配置的，缺乏灵活的请求建模能力。因此，在 HAL1 Adapter 框架下，为了模拟 Camera2 风格的拍照流程，系统采用了诸多策略来桥接关键路径中的能力差异与接口隔离。

本章将从三个核心阶段入手，详细解析 HAL1 路径下的拍照流程适配策略： open 阶段的设备初始化、request 阶段的参数构造与调度、result 阶段的数据同步与回调构造 ，帮助开发者理解系统在兼容模式下是如何“仿真”现代拍照体验的。

1. openCamera：设备连接与状态初始化

在 Camera2 API 中，App 发起拍照前，需通过 CameraManager.openCamera() 建立设备连接。系统对应流程如下：

cameraManager.openCamera("0", stateCallback, handler);

服务端处理流程：

CameraService::connectHelper(...)
 → 判断设备类型（HAL1 / HAL3）
 → 创建 CameraClient / CameraDeviceClient
 → 初始化 CameraHardwareInterface
 → open camera_device via hw_get_module()

HAL1 路径下：

• 使用 camera_device_ops_t 的 open 函数打开设备；
• 通过 CameraHardwareInterface 封装 HAL1 设备指针；
• 初始化状态机，标记设备可用；
• 注册 notifyCallback , dataCallback 等函数指针，供后续拍照流程使用；
• 准备 RequestThread , StreamingProcessor ，构造图像流程框架。

此阶段还会创建 HAL1 Adapter 的上下文环境，并根据 HAL 返回的 CameraParameters 构建静态 metadata（如支持分辨率、对焦模式、闪光灯能力等）。

2. request 阶段：构建 CaptureRequest 与同步封装

Camera2 客户端通过如下方式配置拍照参数：

CameraCaptureSession.capture(CaptureRequest, callback, handler);

每个 CaptureRequest 封装一个独立的参数集合，HAL3 能每帧动态调度。而在 HAL1 中不支持 per-frame 控制，因此系统采用了如下策略：

HAL1 拍照请求构建流程：

1. 参数转换 ：使用 HAL1 Adapter 提供的映射逻辑（详见前章）将 CaptureRequest 翻译为 CameraParameters 字符串格式；

2. 线程分发 ：将请求压入 RequestThread 线程队列，该线程按顺序依次拉取 request 并同步执行 HAL1 的 setParameters 和 takePicture 函数；

3. 预览停止/切换 ：HAL1 不支持拍照与预览同时进行，系统需在 StreamingProcessor 中调用 stopPreview() ，释放流；

4. 拍照控制 ：

   mHardwareInterface->takePicture();
   
   

5. 状态通知 ：手动构造 onCaptureStarted() 回调，通过 notifyCallback() 发回 app。

6. 延时管理 ：系统需判断拍照延迟、驱动是否 busy、preview 停止是否成功，否则需重试。

3. result 阶段：帧数据接收与结果封装

在 HAL1 中，拍照完成后的数据返回依赖 HAL 注册的回调接口：

void CameraHardwareInterface::setCallbacks(
    camera_notify_callback notify_cb,
    camera_data_callback data_cb,
    camera_data_timestamp_callback data_cb_time,
    void *user
);

HAL 完成拍照后，依次调用：

• notify_cb(CAMERA_MSG_SHUTTER) → 表示快门触发；
• data_cb(CAMERA_MSG_COMPRESSED_IMAGE, data) → 返回 JPEG 数据；
• 可选调用 data_cb(CAMERA_MSG_RAW_IMAGE, data) 返回 YUV/RAW 数据。

HAL1 Adapter 封装流程：

1. 捕捉回调信号 ：Adapter 监听 notify 类型和数据内容，提取拍照帧信息；

2. 同步构造 result ：构建 CaptureResult ，填入关键字段：

   • jpegOrientation
   • jpegQuality
   • sensorTimestamp
   • image size
   • requestId, frameNumber

3. 发送结果至 App ：调用 CameraDeviceCallback.onCaptureCompleted() 回传拍照完成事件，JPEG 图像通过目标 ImageReader 或 Surface 输出。

4. 恢复预览 ：调用 StreamingProcessor.startPreview() 重启预览流（如果 App 仍保持 Session）。

4. 请求 → 执行 → 结果：关键控制链路总结

HAL1 Adapter 下的拍照流程适配策略，是一个典型的“伪异步封装”方案：在上层维持 Camera2 的 API 调用规范，在底层模拟 HAL3 的数据语义。虽然不能实现真实的 per-frame pipeline，并发流支持也有限，但这种兼容路径确保了在 Legacy 硬件环境中，Camera2 应用能够以较小代价完成迁移与运行。

六、预览与流配置的限制与优化点

在 Android Camera2 架构中， 流（Stream）配置 是图像处理流程的基础。系统允许开发者通过创建多个 OutputConfiguration 绑定到不同的输出目标（Surface/ImageReader），以实现预览、录像、拍照、实时分析等多种并行场景。然而，在 Legacy HAL（HAL1）架构下，这种灵活的多流并发结构并不被底层硬件所支持，导致 CameraService 必须引入 HAL1 Adapter 的流适配机制 ，对流的配置、启动、释放过程进行严格约束。

本章聚焦于 HAL1 模式下预览与流配置的实际限制、系统层的封装策略以及性能优化的实践建议，帮助开发者理解 Camera2 API 在 Legacy 硬件上的兼容边界与调优路径。

1. HAL1 的流模型限制

HAL1 最初设计于 Android Camera API 1.x 时代，其流模型具备以下限制：

这些限制决定了 HAL1 无法承载复杂的 Camera2 流并发模型，必须进行降级封装。

2. HAL1 Adapter 中的 StreamingProcessor 模块

Android 为 HAL1 封装了专用模块 StreamingProcessor （位于 frameworks/av/），用于统一管理预览流配置、流切换、Surface 缓冲控制。其主要职责包括：

• 管理当前活跃的 Surface 输出目标；
• 实现 setPreviewWindow() / setRecordingProxy() 封装；
• 控制 startPreview() / startRecording() 流切换；
• 对帧率做粗粒度调控；
• 暂停与恢复流（如拍照暂停 preview）；
• 配合 CallbackProcessor 实现帧回调；

示例逻辑：

status_t StreamingProcessor::updatePreviewStream(Surface* surface) {
    if (surface == mActivePreviewSurface) return OK;

    mHardwareInterface->stopPreview();
    mHardwareInterface->setPreviewWindow(surface->getNativeWindow());
    mHardwareInterface->startPreview();

    mActivePreviewSurface = surface;
}

3. 流配置的兼容策略

在 HAL1 模式下，CameraDeviceSession 会被限制为最多支持一组 Surface，系统通常采用如下兼容方案：

此外，系统还会拒绝非法流组合配置请求，并通过以下返回码提示：

CameraAccessException(CAMERA_ERROR_STREAM_CONFIG)

4. HAL1 下常见流配置异常及处理方案

5. 实战中的性能优化建议

虽然 HAL1 不支持并发流，但开发者仍可通过合理的参数配置与流管理方式，优化其运行性能与用户体验：

• 保持流稳定 ：减少频繁的 stopPreview() / startPreview() 重启行为；
• 控制帧率 ：使用 setPreviewFpsRange() 限定帧率范围，避免处理器负担过高；
• 共享 Surface ：在 Preview 和 分析模块（如 MLKit）之间复用 Surface，降低冗余数据处理；
• 预分配 Buffer ：减少 GC 压力；
• 合理使用拍照模式 ：避免录像中调用 takePicture() ，在 HAL1 中将被忽略或导致异常；
• 优先使用固定参数组合 ：如 1920x1080 + JPEG，能兼容更多旧设备；

6. HAL1 向 HAL3 的流模型演进对比

这种差异反映出 HAL1 模式下系统必须通过“流降级”机制兼容运行，并牺牲部分性能与功能。

HAL1 的流配置机制虽然天然受限，但通过 HAL1 Adapter 和 StreamingProcessor 的封装，Android 系统依然为 Camera2 应用提供了统一的使用体验。理解其约束条件与适配策略，有助于开发者在复杂机型兼容中做出正确的架构决策。

七、性能瓶颈分析与优化路径（延迟、帧率、对焦）

在基于 Legacy HAL（HAL1）实现的 Camera2 兼容模式中，由于硬件能力受限与架构设计滞后，系统层面存在明显的性能瓶颈，特别表现在拍照延迟、帧率波动、对焦失效等关键路径。这些瓶颈在多种设备（尤其是中低端 SoC 或定制硬件）中被广泛报告，直接影响用户体验。

本章将围绕 HAL1 的性能限制进行系统性分析，并提出可落地的调优策略，包括代码侧、参数侧与设备能力识别策略，为开发者提供工程实战中的优化路径。

1. 拍照延迟（Shutter Lag）的结构性瓶颈

HAL1 的拍照路径为同步、串行流程，流程包括：停止预览 → 写入参数 → 调用 takePicture() → 等待 JPEG 回调。

性能瓶颈点：

• stopPreview() → 硬件停止预览 DMA，需要几十毫秒；
• 参数更新 → setParameters() 会清除缓存，重启 Sensor 流；
• JPEG 编码同步完成后再通知上层（无异步管线）。

优化建议：

• 减少预览停止次数 ：App 层若仅需采图而非 UI 显示，建议跳过 stopPreview() 。
• 预设 JPEG 参数 ：如 jpeg-thumbnail-size 、 jpeg-quality 、 rotation ，避免每帧变更。
• 利用 ZSL（Zero Shutter Lag）模拟 ：在 App 层缓存预览帧，延迟发送拍照请求。
• 合并设置操作 ：通过 setParameters() 一次性写入所有参数，避免多次调用。

2. 预览与录像帧率不稳定

在 HAL1 中，帧率控制能力极弱，部分平台只能配置 preview-fps-range 参数，而实际输出仍受限于 Sensor 模块与 ISP 的处理能力。

常见问题：

• 设置 30fps 实际仅 18~25fps ；
• 在光线变化或对焦过程中帧率瞬时掉帧；
• 部分平台 fps-range 设置后被 HAL 忽略。

优化建议：

• 设置合适的 preview-fps-range （例如 15,30 而非 30,30 ），提升容错性；
• 使用固定分辨率（如 1280x720） ，部分平台高分辨率下处理能力不足；
• 关闭自动对焦与测光波动源 ：可将 focus-mode 设置为 infinity ， auto-exposure-lock=true ；
• 监控 FPS 实时状态 ：App 层结合 SurfaceTexture.OnFrameAvailableListener 计算帧率，辅助优化流配置。

3. 对焦失败与自动对焦策略不稳定

对焦问题在 Legacy HAL 中尤为突出，主要表现在：

• 对焦速度慢，AF 模式频繁失败；
• auto 模式不生效，尤其在低光或运动场景；
• 连续对焦（ continuous-picture ）模式失灵。

分析根因：

• HAL1 对焦依赖平台提供的驱动函数（如 startAutoFocus() ），但部分驱动未实现回调或永远返回成功；
• 没有帧级别的对焦状态反馈， onAutoFocus() 只是一次性回调；
• 多数 HAL1 只支持 auto , infinity , macro 三种模式。

优化建议：

• 避免使用 continuous-picture 模式 ，在 HAL1 上往往无效；
• 强制拉焦 ：如拍照前主动调用一次 cancelAutoFocus() → autoFocus() ；
• 对焦模式降级 ：低端平台建议统一使用 infinity ；
• 前台聚焦提示模拟 ：App 层使用定时器控制对焦框显示与反馈，不依赖 HAL 回调。

4. 关键路径优化实践参考

以下为实战中可验证的优化组合：

5. 判断平台能力：动态策略适配的必要性

每一台设备的 HAL1 表现差异极大，建议 App 在运行时动态识别平台能力，并做如下适配：

CameraCharacteristics chars = manager.getCameraCharacteristics(cameraId);
int level = chars.get(CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL);
if (level == CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL_LEGACY) {
    // 启用 HAL1 专用路径，禁用多流、多帧控制
}

搭配 getSupportedPreviewSizes() , getSupportedFocusModes() 等能力检测函数，在 Camera 初始化阶段完成降级策略决策。

Legacy HAL 的性能瓶颈是由底层设计限制与硬件能力决定的，CameraService 与 HAL1 Adapter 尽管已做了大量优化，但在体验要求越来越高的场景下，开发者仍需理解这些结构性瓶颈，并通过预配置、路径优化与动态适配等手段，尽可能提供稳定、低延迟的相机体验。

八、实战调试建议与开发中常见问题汇总

在基于 Camera2 API 调用 Legacy HAL（HAL1）路径的实际开发中，开发者会遇到一系列“系统正常但拍照失败”“流无法配置”“部分功能无效”“对焦随机失败”等问题。由于 HAL1 不具备现代 Camera HAL 的标准接口、异步控制链和元数据反馈机制，排查这类问题往往难度大、时间长。

本章将围绕 实战调试建议 与 开发中高频问题汇总 两部分内容展开，结合典型机型（如高通 625、MTK Helio 系列）中的真实案例，帮助开发者建立一套适用于 HAL1 模式的高效问题定位与处理框架。

一、实战调试建议

1. 启用 CameraService 日志

CameraService 日志对于分析系统内 CameraClient、Adapter、StreamingProcessor 的运行状态非常关键：

adb shell setprop log.tag.CameraService VERBOSE
adb logcat -s CameraService

• 观察 connectHelper() 是否成功；
• 检查是否走入 HAL1 Adapter 路径；
• 捕捉 HAL 初始化、流配置、拍照流程中的关键日志。

2. 使用 dumpsys media.camera 检查服务状态

adb shell dumpsys media.camera

重点查看输出项：

• 当前连接的 Camera ID、Client 名称；
• HAL 类型（LEGACY 表示 HAL1）；
• 当前请求配置参数（例如 JPEG size、fps、focus mode）；
• 是否存在“Device is busy”或“Disconnecting due to error”。

3. 使用 lshal 或 aidl_interface 工具确认 HAL 实现

adb shell lshal | grep camera
# 或
adb shell dumpsys hardware | grep -i camera

确认加载的 HAL 库版本、接口类型（是否 HIDL），以及绑定路径（vendor 分区是否匹配）。

4. 检查进程状态与资源占用

adb shell ps -A | grep camera

确认 CameraProvider、cameraserver、vendor.camera-hal 服务是否都在运行，是否因崩溃重启导致无法连接。

5. 日志结合 takePicture / setParameters 监控调用链

adb logcat | grep CameraHardwareInterface

• 检查 setPreviewWindow() 是否被正确调用；
• 分析 takePicture() 执行是否超时或中断；
• 查看 HAL 回调是否未触发（Jpeg callback 未触发是常见问题）。

二、开发中常见问题汇总与处理方案

三、HAL1 模式调试的通用建议

• 不要假设 API 可用性 ：即使 Camera2 中提供了丰富的 request 参数，HAL1 中很多字段如对焦区域、曝光锁定、白平衡模式等只是“形式支持”，调用后可能被忽略。

• 结合机型动态适配 ：建议在应用启动时读取 CameraCharacteristics.INFO_SUPPORTED_HARDWARE_LEVEL ，当检测为 LEGACY 时自动启用 HAL1 兼容模式（关闭高级功能、缩减参数范围）。

• 构建分离的 HAL1 路径 ：可在架构中区分 HAL1 与 HAL3 的参数管理模块与 Session 创建逻辑，提升整体可维护性。

• 优先使用 CameraX 封装（在新设备上） ：虽然 CameraX 最终仍依赖 Camera2，但它对 HAL1 做了更多降级适配，适合快速实现跨设备兼容拍摄功能。

HAL1 与 Camera2 架构的兼容路径在 Android 系统中仍有大量存量设备依赖，开发者需具备扎实的底层理解与调试手段，才能保障相机体验在复杂设备环境下的稳定性。至此，Camera2 × Legacy HAL 兼容性专章内容收束，

本文转自 https://jc-performance.cn//online/2741_148669201.html，如有侵权，请联系删除。