Android開發(fā)了一個相機硬件接口，允許OEM為終端用戶提供高質(zhì)量的相機解決方案。

Camera2 Java API與HAL3結(jié)合（Camera2直接接到HAL3上）為Camera應用程序開發(fā)提供了足夠的靈活性，大多數(shù)場景都可以使用Camera2+HAL3來實現(xiàn)，但是，當java層負責控制執(zhí)行流程時，其他引擎(如CPU、GPU或DSP)上的延遲或潛在的低效處理是不可接受的。

QCOM作為平臺廠商會根據(jù)谷歌定義的HAL3接口來實現(xiàn)自己的Camera HAL3，新的QCOM Camera HAL3 架構(gòu)就是CamX了。

文章目錄

• 1?CamX總體結(jié)構(gòu)

• 2?CamX架構(gòu)提出原因

• 3?CamX-CHI基本目錄結(jié)構(gòu)

• 3.1?camx 目錄介紹

• 3.2?chi-cdk 目錄介紹

• 4?CamX 基本組件

• 4.1?Usecase

• 4.2?Feature

• 4.3?Session

• 4.4?Pipeline

• 4.5?Node

• 4.6?Link

• 4.7?Port

• 5?CamX組件之間關(guān)系

一、CamX總體結(jié)構(gòu)

• Camx的架構(gòu)入口為Camx包中的camxhal3entry.cpp，Camx中是高通平臺Camx架構(gòu)的核心跳轉(zhuǎn)及處理業(yè)務的代碼，一般手機廠商不會去更改，代碼目錄在vendor/qcom/proprietary/camx/下,編譯結(jié)果是camera.qcom.so

• Camx通過chxentensionInterface調(diào)用到?chi-cdk?包下的代碼，這里面一般是手機廠商自己定制功能的地方，代碼目錄在vendor/qcom/proprietary/chi-cdk/，編譯結(jié)果是com.qti.chi.override.so

• 從上面這張圖可知，一個request交給CamX處理，但會經(jīng)過chi-cdk進行request定制化重新打包再交給CamX實際去執(zhí)行或和kernel driver層進行交互，CamX部分代碼是核心流程管控的代碼，而chi-cdk正是手機廠商想要實現(xiàn)自己定制化功能的代碼地方。

• Chi對Camx的操作，需要通過?ExtensionModule?進行操作，因此，CamX對外提供的接口擴展需要通過ExtensionModule進行，里面一個重要的變量就是g_chiContextOps。

• Camx對Chi的操作，是通過HAL3Module接口的m_ChiAppCallbacks進行的，因此chi里面釋放的接口，都會在m_ChiAppCallbacks里面體現(xiàn)。

二、CamX架構(gòu)提出原因

為了更精細化控制底層硬件(Sensor/ISP等關(guān)鍵硬件)，同時方便手機廠商自定義一些功能，現(xiàn)在提出了CamX-CHI架構(gòu). 它將一些高度統(tǒng)一的功能性接口抽離出來放到CamX中，將可定制化的部分放在CHI中供不同廠商進行修改，實現(xiàn)各自獨有的特色功能.

這樣設(shè)計的好處顯而易見，那便是即便開發(fā)者對于CamX并不是很了解，但是依然可以很方便的加入自定義的功能，從而降低了開發(fā)者在高通平臺的開發(fā)門檻。

三、CamX-CHI基本目錄結(jié)構(gòu)

接下來我們以最直觀的目錄結(jié)構(gòu)入手對該架構(gòu)做一個簡單的認識，以下便是CamX-CHI基本目錄結(jié)構(gòu)：

該部分代碼主要位于 vendor/qcom/proprietary/ 目錄

• camx 代表了通用功能性接口的代碼實現(xiàn)集合（CamX）

• chi-cdk代表了可定制化需求的代碼實現(xiàn)集合（CHI）

從圖中可以看出Camx部分對上作為HAL3接口的實現(xiàn)，對下通過v4l2框架與Kernel保持通訊，中間通過互相dlopen so庫并獲取對方操作接口的方式保持著與CHI的交互。

3.1 camx 目錄介紹

camx中有如下幾個主要目錄：

• core/ ： 用于存放camx的核心實現(xiàn)模塊，其中還包含了主要用于實現(xiàn)hal3接口的hal/目錄，以及負責與CHI進行交互的chi/目錄

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

• swl/: 用于存放自身并不具有獨立運算能力，必須依靠CPU才能實現(xiàn)的node

• csl/： 用于存放主要負責camx與camera driver的通訊模塊，為camx提供了統(tǒng)一的Camera driver控制接口

3.2 chi-cdk 目錄介紹

chi-cdk/中有如下幾個主要目錄：

• chioverride/: 用于存放CHI實現(xiàn)的核心模塊，負責與camx進行交互并且實現(xiàn)了CHI的總體框架以及具體的業(yè)務處理。

• bin/: 用于存放平臺相關(guān)的配置項

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

• node/: 用于存放用戶自定義功能的node

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

• tuning/: 用于存放不同場景下的效果參數(shù)的配置文件

• sensor/: 用于存放不同sensor的私有信息以及寄存器配置參數(shù)

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

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

• flash/： 存放著閃光燈模塊的配置信息

• eeprom/: 存放著eeprom外部存儲模塊的配置信息

• fd/: 存放了人臉識別模塊的配置信息

四、CamX 基本組件

4.1 Usecase

作為CamX-CHI中最大的抽象概念，其中包含了多條實現(xiàn)特定功能的Pipeline，具體實現(xiàn)是在CHI中通過Usecase類完成的，該類主要負責了其中的業(yè)務處理以及資源的管理。

Usecase類，提供了一系列通用接口，作為現(xiàn)有的所有Usecase的基類，其中，AdvancedCameraUsecase又繼承于CameraUsecaseBase，相機中絕大部分場景會通過實例化AdvancedCameraUsecase來完成，它包括了幾個主要接口：

• Create(): 該方法是靜態(tài)方法，用于創(chuàng)建一個AdvancedCameraUsecase實例，在其構(gòu)造方法中會去獲取XML中的相應的Usecase配置信息。

• ExecuteCaptureRequest(): 該方法用于下發(fā)一次Request請求。

• ProcessResultCb(): 該方法會在創(chuàng)建Session的過程中，作為回調(diào)方法注冊到其中，一旦Session數(shù)據(jù)處理完成的時候便會調(diào)用該方法將結(jié)果發(fā)送到AdvancedCameraUsecase中。

• ProcessDriverPartialCaptureResult(): 該方法會在創(chuàng)建Session的過程中，作為回調(diào)方法注冊到其中，一旦Session中產(chǎn)生了partial meta data的時候，便會調(diào)用該方法將其發(fā)送至AdvancedCameraUsecase中。

• ProcessMessageCb(): 該方法會在創(chuàng)建Session的過程中，作為回調(diào)方法注冊到其中，一旦Session產(chǎn)生任何事件，便會調(diào)用該方法通知到AdvancedCameraUsecase中。

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

• Destroy(): 該方法用于安全銷毀AdvancedCameraUsecase。

Usecase的可定制化部分被抽象出來放在了common_usecase.xml文件中，這里簡單介紹其中的幾個主要的標簽含義：

• UsecaseName: 代表了該Usecase的名字，后期根據(jù)這個名字找到這個Usecase的定義。

• Targets: 用于表示用于輸出的數(shù)據(jù)流的集合，其中包括了數(shù)據(jù)流的格式，輸出Size的范圍等。

• Pipeline: 用于定義該Usecase可以是使用的所有Pipeline，這里必須至少定義一條Pipeline。

4.2 Feature

Feature代表了一個特定的功能，該功能需要多條Pipeline組合起來實現(xiàn)，受Usecase統(tǒng)一管理，在CHI中通過Feature類進行實現(xiàn)，在XML中沒有對應的定義，具體的Feature選取工作是在Usecase中完成的，通過在創(chuàng)建Feature的時候，傳入Usecase的實例的方式，來和Usecase進行相互訪問各自的資源。

以下是現(xiàn)有的Feature，其中Feature作為基類存在，定義了一系列通用方法。

幾個常用的Feature:

• FeatureHDR: 用于實現(xiàn)HDR功能，它負責管理內(nèi)部的一條或者幾條pipeline的資源以及它們的流轉(zhuǎn)，最終輸出具有HDR效果的圖像。

• FeatureMFNR: 用于實現(xiàn)MFNR功能，內(nèi)部分為幾個大的流程，分別包括Prefiltering、Blending、Postfilter以及最終的OfflineNoiseReproces(這一個是可選擇使能的)，每一個小功能中包含了各自的pipeline。

• FeatureASD: 用于AI功能的實現(xiàn)，在預覽的時候，接收每一幀數(shù)據(jù)，并且進行分析當前場景的AI識別輸出結(jié)果，并其通過諸如到metadata方式給到上層，進行后續(xù)的處理。

4.3 Session

用于管理pipeline的抽象控制單元，一個Session中至少擁有一個pipeine，并且控制著所有的硬件資源，管控著每一個內(nèi)部pipeline的request的流轉(zhuǎn)以及數(shù)據(jù)的輸入輸出，它沒有可定制化的部分，所以在CHI中的XML文件中并沒有將Session作為一個獨立的單元進行定義。

Session的實現(xiàn)主要通過CamX中的Session類，其主要接口如下：

• Initialize(): 根據(jù)傳入的參數(shù)SessionCreateData進行Session的初始化工作。

• NotifyResult(): 內(nèi)部的Pipeline通過該接口將結(jié)果發(fā)送到Session中。

• ProcessCaptureRequest(): 該方法用于用戶決定發(fā)送一個Request到Session中的時候調(diào)用。

• StreamOn(): 通過傳入的Pipeline句柄，開始硬件的數(shù)據(jù)傳輸。

• StreamOff(): 通過傳入的Pipeline句柄，停止硬件的數(shù)據(jù)傳輸。

4.4 Pipeline

作為提供單一特定功能的所有資源的集合，維護著所有硬件資源以及數(shù)據(jù)的流轉(zhuǎn)，每一個Pipeline包括了其中的Node/Link，在CamX中通過Pipeline類進行實現(xiàn)，負責整條Pipeline的軟硬件資源的維護以及業(yè)務邏輯的處理，接下來我們簡單看下該類的幾個主要接口：

• Create(): 該方法是一個靜態(tài)方法，根據(jù)傳入的PipelineCreateInputData信息來實例化一個Pipeline對象。

• StreamOn(): 通知Pipeline開始硬件的數(shù)據(jù)傳輸

• StreamOff(): 通知Pipeline停止硬件的數(shù)據(jù)傳輸

• FinalizePipeline(): 用于完成Pipeline的設(shè)置工作

• OpenRequest(): open一個CSL用于流轉(zhuǎn)的Request

• ProcessRequest(): 開始下發(fā)Request

• NotifyNodeMetadataDone(): 該方法是Pipeline提供給Node，當Node內(nèi)部生成了metadata,便會調(diào)用該方法來通知metadata已經(jīng)完成，最后當所有Node都通知Pipeline metadata已經(jīng)完成，Pipeline 便會調(diào)用ProcessMetadataRequestIdDone通知Session。

• NotifyNodePartialMetadataDone(): 該方法是Pipeline提供給Node，當Node內(nèi)部生成了partial metadata,便會調(diào)用該方法來通知metadata已經(jīng)完成，最后當所有Node都通知Pipeline metadata已經(jīng)完成，Pipeline 便會調(diào)用ProcessPartialMetadataRequestIdDone通知Session。

• SinkPortFenceSignaled(): 用來通知Session 某個sink port的fence處于被觸發(fā)的狀態(tài)。

• NonSinkPortFenceSignaled(): 用來通知Session 某個non sink port的fence處于被觸發(fā)的狀態(tài)。

Pipeline中的Node以及連接方式都在XML中被定義，其主要包含了以下幾個標簽定義：

• PipelineName: 用來定義該條Pipeline的名稱

• NodeList: 該標簽中定義了該條Pipeline的所有的Node

• PortLinkages: 該標簽定義了Node上不同端口之間的連接關(guān)系

4.5 Node

作為單個具有獨立處理功能的抽象模塊，可以是硬件單元也可以是軟件單元，關(guān)于Node的具體實現(xiàn)是CamX中的Node類來完成的，其中CamX-CHI中主要分為兩個大類：

• 一個是高通自己實現(xiàn)的Node包括硬件Node

• 一個是CHI中提供給用戶進行實現(xiàn)的Node

其主要方法如下：

• Create(): 該方法是靜態(tài)方法，用于實例化一個Node對象。

• ExecuteProcessRequest(): 該方法用于針對hwl node下發(fā)request的操作。

• ProcessRequestIdDone(): 一旦該Node當前request已經(jīng)處理完成，便會通過調(diào)用該方法通知Pipeline。

• ProcessMetadataDone(): 一旦該Node的當前request的metadata已經(jīng)生成，便會通過調(diào)用該方法通知到Pipeline。

• ProcessPartialMetadataDone(): 一旦該Node的當前request的partial metadata已經(jīng)生成，便會通過調(diào)用該方法通知到Pipeline。

• CreateImageBufferManager(): 創(chuàng)建ImageBufferManager

其可定制化的部分作為標簽在XML中進行定義：

• NodeName： 用來定義該Node的名稱

• NodeId: 用來指定該Node的ID，其中IPE NodeId為65538，IFE NodeId為65536，用戶自定義的NodeId為255。

• NodeInstance: 用于定義該Node的當前實例的名稱。

• NodeInstanceId: 用于指定該Node實例的Id。

4.6 Link

用于定義不同Port的連接，一個Port可以根據(jù)需要建立多條與其它從屬于不同Node的Port的連接,它通過標簽來進行定義，其中包括了作為輸入端口，作為輸出端口。 一個Link中包含了一個SrcPort和一個DstPort，分別代表了輸入端口和輸出端口，然后BufferProperties用于表示兩個端口之間的buffer配置。

4.7 Port

作為Node的輸入輸出的端口，在XML文件中，標簽用來定義一個輸入端口，標簽用來定義輸出端口，每一個Node都可以根據(jù)需要使用一個或者多個輸入輸出端口，使用OutputPort以及InputPort結(jié)構(gòu)體來進行在代碼中定義。

• PortId: 該端口的Id: 該端口的名稱

• NodeName: 該端口從屬的Node名稱

• NodeId: 該端口從屬的Node的Id

• NodeInstance: 該端口從屬的Node的實例名稱

• NodeInstanceId: 該端口從屬的Node的實例的Id

五、CamX組件之間關(guān)系

通過之前的介紹，我們對于幾個基本組件有了一個比較清晰地認識，但是任何一個框架體系并不是僅靠組件胡亂堆砌而成的，相反，它們都必須基于各自的定位，按照各自所獨有的行為模式，同時按照約定俗稱的一系列規(guī)則組合起來，共同完成整個框架某一特定的功能。所以這里不得不產(chǎn)生一個疑問，在該框架中它們到底是如何組織起來的呢？它們之間的關(guān)系又是如何的呢？ 接下來我們以下圖入手開始進行分析：

由上圖可以看到，幾者是通過包含關(guān)系組合起來的,Usecase 包含F(xiàn)eature，而Feature包含了Session，Session又維護了內(nèi)部的Pipeline的流轉(zhuǎn)，而每一條pipeline中又通過Link將所有Node都連接了起來，接下我們就這幾種關(guān)系詳細講解下：

• 首先，一個Usecase代表了某個特定的圖像采集場景，比如人像場景，后置拍照場景等等，在初始化的時候通過根據(jù)上層傳入的一些具體信息來進行創(chuàng)建，這個過程中，一方面實例化了特定的Usecase，這個實例是用來管理整個場景的所有資源，同時也負責了其中的業(yè)務處理邏輯，另一方面，獲取了定義在XML中的特定Usecase，獲取了用于實現(xiàn)某些特定功能的pipeline。

• 其次，在Usecase中，F(xiàn)eature是一個可選項，如果當前用戶選擇了HDR模式或者需要在Zoom下進行拍照等特殊功能的話，在Usecase創(chuàng)建過程中，便會根據(jù)需要創(chuàng)建一個或者多個Feature，一般一個Feature對應著一個特定的功能，如果場景中并不需要任何特定的功能，則也完全可以不使用也不創(chuàng)建任何Feature。

• 然后，每一個Usecase或者Feature都可以包含一個或者多個Session，每一個Session都是直接管理并負責了內(nèi)部的Pipeline的數(shù)據(jù)流轉(zhuǎn)，其中每一次的Request都是Usecase或者Featuret通過Session下發(fā)到內(nèi)部的Pipeline進行處理，數(shù)據(jù)處理完成之后也是通過Session的方法將結(jié)果給到CHI中，之后是直接給到上層還是將數(shù)據(jù)封裝下再次下發(fā)到另一個Session中進行后處理，這都交由CHI來決定。

• 其中，Session和Pipeline是一對多的關(guān)系，通常一個Session只包含了一條Pipeline，用于某個特定圖像處理功能的實現(xiàn)，但是也不絕對，比如FeatureMFNR中包含的Session就包括了三條pipeline，又比如后置人像預覽，也是用一個Session包含了兩條分別用于主副雙攝預覽的Pipeline，主要是要看當前功能需要的pipeline數(shù)量以及它們之間是否存在一定關(guān)聯(lián)。

• 同時，根據(jù)上面關(guān)于Pipeline的定義，它內(nèi)部包含了一定數(shù)量的Node，并且實現(xiàn)的功能越復雜，所包含的Node也就越多，同時Node之間的連接也就越錯綜復雜，比如后置人像預覽虛化效果的實現(xiàn)就是將拿到的主副雙攝的圖像通過RTBOfflinePreview這一條Pipeline將兩幀圖像合成一幀具有虛化效果的圖像，從而完成了虛化功能。

• 最后Pipeline中的Node的連接方式是通過XML文件中的Link來進行描述的，每一個Link定義了一個輸入端和輸出端分別對應著不同Node上面的輸入輸出端口，通過這種方式就將其中的一個Node的輸出端與另外一個Node的輸入端，一個一個串聯(lián)起來，等到圖像數(shù)據(jù)從Pipeline的起始端開始輸入的時候，便可以按照這種定義好的軌跡在一個一個Node之間進行流轉(zhuǎn)，而在流轉(zhuǎn)的過程中每經(jīng)過一個Node都會在內(nèi)部對數(shù)據(jù)進行處理，這樣等到數(shù)據(jù)從起始端一直流轉(zhuǎn)到最后一個Node的輸出端的時候，數(shù)據(jù)就經(jīng)過了很多次處理，這些處理效果最后疊加在一起便是該Pipeline所要實現(xiàn)的功能，比如降噪、虛化等等。

轉(zhuǎn)載來源：deepinout.com/qcom-camx-c…

*本人從事Android Camera相關(guān)開發(fā)已有5年，

*目前在深圳上班，

*歡迎關(guān)注我的微信公眾號: 小馳筆記

*希望和更多的小伙伴一起交流學習~

----2021.05.01 深圳 16：33