📚 课程目录第1章 Camera HAL层概述

1. Camera HAL层概述

大家好，我是你们的讲师。做了十年嵌入式相机开发，调试过的 HAL 层代码少说也有几十万行。今天咱们来聊聊 Camera HAL 层——这个 Android 相机系统中承上启下的关键环节。

说实话，很多刚入行的工程师觉得 HAL 层就是个接口转换层，没什么技术含量。但我在项目中踩过的坑告诉我：不懂 HAL 层，你连相机打不开的问题都定位不了。

1.1 HAL架构演进：从HAL1到HAL3

Android 相机 HAL 层经历了两次重大迭代。我最早接触的是 HAL1，那时候功能简单，但限制也多。

HAL1 时代

HAL1 是 Android 4.0 之前的标准。说白了，它就是个简单的「拍照-返回」模型。应用层下发指令，HAL 层执行，然后返回结果。

HAL1 的核心特点：

单线程模型，一次只能处理一个请求
预览和拍照是串行的
不支持多摄像头同时工作
扩展性差，厂商定制困难

我记得 2012 年做第一款双摄手机时，HAL1 根本没法同时处理两个摄像头的预览流。我们只能通过 hack 方式，在底层做切换。那叫一个痛苦。

HAL3 的诞生

Android 5.0 引入了 HAL3，这是个质的飞跃。它采用了 pipeline 模型，支持并发请求。

HAL3 的核心改进：

多请求队列，支持并发处理
每个请求可以独立配置参数
支持多摄像头同步
引入 metadata 机制，参数传递更灵活

为什么会这样设计？你想想看，现在的手机动辄三摄四摄，如果还用 HAL1 那种串行模型，拍个照得排队等，用户体验能好吗？

HAL1 vs HAL3 对比

特性	HAL1	HAL3
请求模型	单请求串行	多请求并发
参数传递	固定结构体	metadata 灵活传递
多摄像头	不支持	原生支持
厂商扩展	困难	通过自定义 metadata
调试难度	较低	较高

嗯，这里要注意：虽然 HAL3 功能强大，但调试复杂度也上去了。我见过不少团队从 HAL1 迁移到 HAL3 时，光 metadata 的配置就折腾了两个月。

1.2 HAL层在Android相机系统中的位置

咱们先看一张架构图，你就明白 HAL 层到底在哪了。

从这张图你能看到，HAL 层正好卡在 Framework 和内核驱动之间。它是个「翻译官」——把上层抽象的 API 调用，转换成底层硬件能理解的指令。

我个人习惯把 HAL 层比作「变压器」。上层来的 220V 标准电压，经过 HAL 层转换成硬件需要的 5V 或 3.3V。没有这层转换，应用层直接操作硬件？那代码得写成什么样。

1.3 HAL层核心职责与接口定义

HAL 层到底干哪些活？我总结为三大块：

职责一：设备管理与生命周期

打开/关闭摄像头设备
管理摄像头资源分配
处理异常断开和重连

我曾经遇到过一个 bug：手机待机一晚上，第二天相机打不开了。查了两天，最后发现是 HAL 层在系统休眠时没有正确释放设备节点，导致驱动锁死。

职责二：数据流控制

预览流的启动/停止
拍照请求的处理
视频录制的帧数据传递
多路数据流的同步

说白了，所有你看到的画面、拍到的照片，都是经过 HAL 层这条管道流上来的。管道堵了，画面就卡了。

职责三：参数配置与元数据管理

曝光、白平衡、对焦等参数设置
3A 算法（自动曝光、自动对焦、自动白平衡）的协调
metadata 的生成与传递

避坑指南：metadata 是 HAL3 调试中最容易出问题的地方。我曾经因为一个 metadata tag 的 ID 写错，导致预览画面偏绿。查了三天才发现是某个厂商自定义 tag 和标准 tag 冲突了。

核心接口定义

HAL3 的核心接口定义在 hardware/libhardware/include/hardware/camera3.h 中。关键结构体如下：

// HAL3 设备结构体
typedef struct camera3_device {
    hw_device_t common;
    camera3_device_ops_t *ops;
    void *priv;
} camera3_device_t;

// 操作函数集
typedef struct camera3_device_ops {
    int (*initialize)(...);
    int (*configure_streams)(...);
    int (*register_stream_buffers)(...);
    int (*process_capture_request)(...);
    void (*get_metadata_vendor_tag_ops)(...);
    int (*dump)(...);
    int (*flush)(...);
    void (*signal_stream_flush)(...);
    int (*is_reconfiguration_required)(...);
} camera3_device_ops_t;

这里我重点说三个接口：

configure_streams：配置数据流。这是 HAL 层最复杂的接口之一。你要告诉 HAL 层：我要几路流？每路流的分辨率、格式、帧率是多少？
process_capture_request：处理拍照请求。每个请求包含一组 metadata 参数和输出 buffer。HAL 层要保证请求按顺序处理，并且返回结果。
flush：清空请求队列。这个接口在异常处理时特别重要。我见过有的厂商实现 flush 时直接返回 OK，但内部队列根本没清干净，导致后续请求全部超时。

调试小技巧：在调试 HAL 层时，我习惯在 process_capture_request 入口和出口加时间戳。如果某个请求处理时间超过 100ms，基本可以断定有问题。正常预览帧的处理时间应该在 16-33ms 之间。

好了，这一章我们梳理了 HAL 层的架构演进、系统位置和核心职责。从 HAL1 到 HAL3 的变迁，说白了就是 Android 相机系统从「能用」到「好用」的进化史。而 HAL 层作为承上启下的关键节点，它的稳定性直接决定了相机体验的好坏。