深入理解高通Camx实现

和你一起终身学习，这里是程序员Android

经典好文推荐，通过阅读本文，您将收获以下知识点:

一、概览
二、基本组件概念
三、组件结构关系
四、关键流程详解

相机硬件抽象层实现

一、概览

回顾高通平台Camera HAL历史，之前高通采用的是QCamera & MM-Camera架构，但是为了更精细化控制底层硬件(Sensor/ISP等关键硬件)，同时方便手机厂商自定义一些功能，现在提出了CamX-CHI架构，由于在CamX-CHI中完全看不到之前老架构的影子，所以它完全是一个全新的架构，它将一些高度统一的功能性接口抽离出来放到CamX中，将可定制化的部分放在CHI中供不同厂商进行修改，实现各自独有的特色功能，这样设计的好处显而易见，那便是即便开发者对于CamX并不是很了解，但是依然可以很方便的加入自定义的功能，从而降低了开发者在高通平台的开发门槛。

接下来我们以最直观的目录结构入手对该架构做一个简单的认识，以下便是CamX-CHI基本目录结构：

程序员Android转于网络

该部分代码主要位于 vendor/qcom/proprietary/ 目录下：

其中 camx 代表了通用功能性接口的代码实现集合（CamX），chi-cdk代表了可定制化需求的代码实现集合（CHI），从图中可以看出Camx部分对上作为HAL3接口的实现，对下

通过v4l2框架与Kernel保持通讯，中间通过互相dlopen so库并获取对方操作接口的方式保持着与CHI的交互。

camx/中有如下几个主要目录：

• core/ ：用于存放camx的核心实现模块，其中还包含了主要用于实现hal3接口的hal/目录，以及负责与CHI进行交互的chi/目录

• csl/：用于存放主要负责camx与camera driver的通讯模块，为camx提供了统一的Camera driver控制接口

• hwl/: 用于存放自身具有独立运算能力的硬件node，该部分node受csl管理

• swl/: 用于存放自身并不具有独立运算能力，必须依靠CPU才能实现的node

chi-cdk/中有如下几个主要目录：

• chioverride/: 用于存放CHI实现的核心模块，负责与camx进行交互并且实现了CHI的总体框架以及具体的业务处理。

• bin/: 用于存放平台相关的配置项

• topology/: 用于存放用户自定的Usecase xml配置文件

• node/: 用于存放用户自定义功能的node

• module/: 用于存放不同sensor的配置文件，该部分在初始化sensor的时候需要用到

• tuning/: 用于存放不同场景下的效果参数的配置文件

• sensor/: 用于存放不同sensor的私有信息以及寄存器配置参数

• actuator/: 用于存放不同对焦模块的配置信息

• ois/：用于存放防抖模块的配置信息

• flash/：存放着闪光灯模块的配置信息

• eeprom/: 存放着eeprom外部存储模块的配置信息

• fd/: 存放了人脸识别模块的配置信息

二、基本组件概念

1. Usecase

作为CamX-CHI中最大的抽象概念，其中包含了多条实现特定功能的Pipeline，具体实现是在CHI中通过Usecase类完成的，该类主要负责了其中的业务处理以及资源的管理。

Usecase类，提供了一系列通用接口，作为现有的所有Usecase的基类，其中，AdvancedCameraUsecase又继承于CameraUsecaseBase，相机中绝大部分场景会通过实例化AdvancedCameraUsecase来完成，它包括了几个主要接口：

• Create(): 该方法是静态方法，用于创建一个AdvancedCameraUsecase实例，在其构造方法中会去获取XML中的相应的Usecase配置信息。

• ExecuteCaptureRequest(): 该方法用于下发一次Request请求。

• ProcessResultCb(): 该方法会在创建Session的过程中，作为回调方法注册到其中，一旦Session数据处理完成的时候便会调用该方法将结果发送到AdvancedCameraUsecase中。

• ProcessDriverPartialCaptureResult(): 该方法会在创建Session的过程中，作为回调方法注册到其中，一旦Session中产生了partial meta data的时候，便会调用该方法将其发送至AdvancedCameraUsecase中。

• ProcessMessageCb(): 该方法会在创建Session的过程中，作为回调方法注册到其中，一旦Session产生任何事件，便会调用该方法通知到AdvancedCameraUsecase中。

• ExecuteFlush(): 该方法用于刷新AdvancedCameraUsecase。

• Destroy(): 该方法用于安全销毁AdvancedCameraUsecase。

Usecase的可定制化部分被抽象出来放在了common_usecase.xml文件中，这里简单介绍其中的几个主要的标签含义：
Usecase

• UsecaseName: 代表了该Usecase的名字，后期根据这个名字找到这个Usecase的定义。

• Targets: 用于表示用于输出的数据流的集合，其中包括了数据流的格式，输出Size的范围等。

• Pipeline: 用于定义该Usecase可以是使用的所有Pipeline，这里必须至少定义一条Pipeline。

2. Feature

代表了一个特定的功能，该功能需要多条Pipeline组合起来实现，受Usecase统一管理，在CHI中通过Feature类进行实现，在XML中没有对应的定义，具体的Feature选取工作是在Usecase中完成的，通过在创建Feature的时候，传入Usecase的实例的方式，来和Usecase进行相互访问各自的资源。

以下是现有的Feature，其中Feature作为基类存在，定义了一系列通用方法。

程序员Android转于网络

几个常用的Feature:

• FeatureHDR: 用于实现HDR功能，它负责管理内部的一条或者几条pipeline的资源以及它们的流转，最终输出具有HDR效果的图像。

• FeatureMFNR: 用于实现MFNR功能，内部分为几个大的流程，分别包括Prefiltering、Blending、Postfilter以及最终的OfflineNoiseReproces(这一个是可选择使能的)，每一个小功能中包含了各自的pipeline。

• FeatureASD: 用于AI功能的实现，在预览的时候，接收每一帧数据，并且进行分析当前场景的AI识别输出结果，并其通过诸如到metadata方式给到上层，进行后续的处理。

3. Session

用于管理pipeline的抽象控制单元，一个Session中至少拥有一个pipeine，并且控制着所有的硬件资源，管控着每一个内部pipeline的request的流转以及数据的输入输出，它没有可定制化的部分，所以在CHI中的XML文件中并没有将Session作为一个独立的单元进行定义。

Session的实现主要通过CamX中的Session类，其主要接口如下：

• Initialize(): 根据传入的参数SessionCreateData进行Session的初始化工作。

• NotifyResult(): 内部的Pipeline通过该接口将结果发送到Session中。

• ProcessCaptureRequest(): 该方法用于用户决定发送一个Request到Session中的时候调用。

• StreamOn(): 通过传入的Pipeline句柄，开始硬件的数据传输。

• StreamOff(): 通过传入的Pipeline句柄，停止硬件的数据传输。

4. Pipeline

作为提供单一特定功能的所有资源的集合，维护着所有硬件资源以及数据的流转，每一个Pipeline包括了其中的Node/Link，在CamX中通过Pipeline类进行实现，负责整条Pipeline的软硬件资源的维护以及业务逻辑的处理，接下来我们简单看下该类的几个主要接口：

• Create(): 该方法是一个静态方法，根据传入的PipelineCreateInputData信息来实例化一个Pipeline对象。

• StreamOn(): 通知Pipeline开始硬件的数据传输

• StreamOff(): 通知Pipeline停止硬件的数据传输

• FinalizePipeline(): 用于完成Pipeline的设置工作

• OpenRequest(): open一个CSL用于流转的Request

• ProcessRequest(): 开始下发Request

• NotifyNodeMetadataDone(): 该方法是Pipeline提供给Node，当Node内部生成了metadata,便会调用该方法来通知metadata已经完成，最后当所有Node都通知Pipeline metadata已经完成，Pipeline 便会调用ProcessMetadataRequestIdDone通知Session。<