高通3A框架：从硬件到应用的软件栈
做高通平台3A优化，第一件事不是调参数，而是搞清楚软件怎么把传感器数据变成你看到的画面。说白了，你得知道数据从哪来、经过谁、最后到哪去。这一章我就带你捋一遍高通3A的软件架构——CamX、Chi、UAPI这三层到底在干什么。
整体架构：三层分工
高通平台的相机软件栈，我习惯把它分成三层：
- UAPI层（User API）—— 应用层接口，Framework和App通过它下发请求
- CamX层（Camera eXtension）—— 核心框架层，负责Pipeline管理、Session调度
- Chi层（Camera Hardware Interface）—— 硬件抽象层，直接对接Sensor、ISP、Actuator
这三层的关系，你可以想象成：UAPI是前台接待，CamX是项目经理，Chi是干活的技术工人。我在项目里见过不少同事只盯着Chi层调3A参数，结果上层UAPI配置不对，数据根本传不下来——白忙活。
核心观点： 3A算法的性能瓶颈，往往不在算法本身，而在数据路径上。哪一层丢帧、哪一层延迟超标，都会让3A效果大打折扣。
UAPI接口层：应用与框架的桥梁
UAPI是Android Camera HAL3的官方接口。高通在此基础上做了一些扩展，但核心还是那几个关键结构体：
| 接口/结构体 | 作用 | 我踩过的坑 |
|---|---|---|
camera3_device_t |
设备操作接口，open/close/configure_streams | configure_streams顺序不对，导致3A初始化失败 |
camera3_capture_request_t |
单帧请求，包含settings、output_buffers | settings里没带3A控制tag，算法直接不跑 |
camera3_callback_ops_t |
结果回调，process_capture_result | 回调里metadata没填全，上层App黑屏 |
嗯，这里要注意：UAPI层不直接参与3A计算，它只负责把App的意图翻译成CamX能理解的请求。比如App说“我要自动对焦”，UAPI就在request里塞一个ANDROID_CONTROL_AF_MODE tag。CamX看到这个tag，才知道该启动AF算法。
个人习惯： 调试3A问题时，我第一件事就是抓UAPI层的log，看request里的control tag有没有传对。很多“3A不工作”的问题，其实只是上层没下发正确的控制指令。
CamX框架层：Pipeline与Session管理
CamX是高通相机框架的核心。它把整个拍照流程抽象成一条Pipeline，Pipeline里挂着一堆Node，每个Node负责一件事——比如AE统计、AF计算、AWB校正。
我刚开始接触CamX时，最头疼的就是它的Session概念。简单说：
- Pipeline：一条完整的数据处理链路，从Sensor raw到YUV输出
- Session：一次拍照或预览会话，可以包含多条Pipeline
- Node：Pipeline里的处理单元，3A算法就挂在Node上跑
举个例子：预览时，CamX会创建一条“preview pipeline”，里面包含IFENode（ISP处理）、StatsNode（统计信息）、AENode（自动曝光）等。每次Sensor出帧，数据就沿着这条Pipeline流一遍，每个Node处理完再传给下一个。
避坑指南： 我曾经在调试AE收敛速度时，发现每次改完AE算法参数，效果都没变化。查了两天才发现——我改的是StatsNode里的参数，但实际AE算法跑在AENode里，两个Node的配置是独立的。所以改参数前，先确认Node ID对不对。
Chi层：硬件抽象与算法适配
Chi层是CamX和硬件之间的适配层。它负责：
- 把CamX的通用请求翻译成具体硬件的寄存器配置
- 加载并运行3A算法库（通常是高通提供的闭库，或者OEM自研的算法）
- 把硬件统计信息（AE histogram、AF contrast值等）返回给CamX
Chi层里有一个关键概念叫ChiUsecase，它定义了不同场景下的Pipeline配置。比如：
ChiUsecasePreview：预览场景，通常用较简单的3A策略ChiUsecaseSnapshot：拍照场景，AE/AWB会做更精细的收敛ChiUsecaseVideo：录像场景，AF要平滑，不能来回抽
每个Usecase可以绑定不同的3A算法参数。所以你在调3A时，一定要确认当前跑的是哪个Usecase。我见过有人调了半天预览的AE参数，结果拍照效果还是差——因为他改的是PreviewUsecase的配置，拍照用的是SnapshotUsecase。
数据流全景图
下面这张图，是我自己画的高通3A数据流。每次带新人时，我都会先让他们看这张图——搞清楚数据怎么流，比背API有用得多。
你想想看，数据从App发出来，经过UAPI、CamX、Chi，最后到硬件，再带着统计信息原路返回。任何一个环节出问题，3A效果都会受影响。我排查性能问题时，习惯从下往上查——先看硬件有没有出帧，再看Chi层统计对不对，最后看CamX调度有没有卡住。
关键数据结构：Metadata的流转
3A算法的输入输出，全靠Metadata传递。高通平台里，Metadata主要分两类：
- Request Metadata：App下发的控制参数，比如AE target brightness、AF mode
- Result Metadata：3A算法计算后的结果，比如AE exposure time、AF lens position
Metadata在CamX内部用ChiMetadata结构体管理。每个Node都可以读/写Metadata，实现数据共享。举个例子：
// AE Node写入曝光时间
ChiMetadata_SetUint32(pMetadata, "com.qti.ae.exposureTime", 33333); // 33.33ms
// ISP Node读取曝光时间，配置寄存器
uint32_t expTime;
ChiMetadata_GetUint32(pMetadata, "com.qti.ae.exposureTime", &expTime);
// 然后根据expTime配置sensor寄存器
这里有个容易踩的坑：Metadata的key名字是字符串，拼写错了就读取不到。我遇到过一例，AE算法算好了曝光时间，但ISP Node读到的key名多了一个下划线，结果一直用默认值——画面忽明忽暗，查了三天才发现。
调试技巧： 在CamX的Node里加log，打印所有经过的Metadata key和value。用ChiMetadata_Dump()函数，可以一次性看到所有字段。我每次调3A，第一步就是开这个dump，确认数据链路通不通。
性能分析的关键点
做3A性能优化，你得知道从哪下手。我总结了三个核心指标：
| 指标 | 含义 | 典型问题 |
|---|---|---|
| Pipeline Latency | 一帧数据从Sensor到输出的总延迟 | Node处理太慢，导致帧率下降 |
| 3A Convergence Time | AE/AF/AWB从开始到稳定的帧数 | 算法参数不合适，收敛慢 |
| Metadata Overhead | Metadata在Node间传递的耗时 | key数量太多，序列化/反序列化开销大 |
嗯，这里要特别提一下Metadata Overhead。我优化过一个项目，3A算法本身很快，但整体帧率就是上不去。后来用perf工具一查，发现ChiMetadata的序列化占了30%的CPU时间——因为每个Node都往Metadata里塞了几十个自定义key，每次传递都要全部拷贝一遍。解决办法是精简key，只保留必要的字段。
避坑指南： 我曾经在Chi层加了一个自定义的AE统计key，每次帧处理都写一次。结果这个key的字符串长度有80多个字符，每次序列化都要malloc/free，导致内存碎片严重，跑久了就卡顿。后来改成用整数ID代替字符串key，问题解决。
小结
高通3A框架的核心，就是UAPI-CamX-Chi三层协作。UAPI负责和App沟通，CamX负责调度，Chi负责干活。3A算法挂在Chi层的Node上，通过Metadata和上下层交换数据。性能优化的关键，是搞清楚数据流在哪一层卡住了——是UAPI请求没传对？CamX调度有瓶颈？还是Chi层算法太慢？