简介：本资源是一份面向Android相机驱动开发工程师与高通平台Camera模块深度学习者的专业技术解析文档，聚焦Chi-CDK Feature2框架的架构设计与运行机制，解决FeatureGraph调度、跨Node数据流协同及实时YUV处理等核心开发难点。文档为单文件PDF（1000KB），内容涵盖FeatureNode与Stage配置逻辑、CHITargetBufferManager缓冲区管理策略、Request/Execute/Result三阶段处理流程、RealTime/RTBay2YUV/RTMFSRYUV实时组件协作关系，以及FeatureInternalLink连接机制与Link状态机实现细节，并附FeatureGraph简易模型图解与CamX XML pipeline映射说明。预览内容显示其通过典型用例（如RTBayer2YUV流程）逐层展开依赖获取、buffer提交与结果回调的完整执行链路，具备强实践指导性。目前已有8061人学习下载，适合中高级Camera开发者快速掌握Feature2框架底层原理与调试切入点。

1. Feature2 不是“另一个 pipeline 封装器”：它用图状依赖调度取代了 CamX 的线性 DRQ 队列，这才是 RealTime 场景下低延迟、高吞吐的底层根因

你写完一个 Bayer2YUV 的 FeatureNode，把它塞进 XML 里，CamX 能跑；但当你把 RealTimeDisplay + RTBayer2YUV + MFSR 三者串成一条链，再叠加 ZSL 元数据流和多帧 buffer 复用——CamX 原生 DRQ 立刻卡住：ready/deferred 队列反复震荡，dependency 满足判断只看 port 是否就绪，不看哪个 request 的哪个 output port正在被哪条 downstream path 消费。结果就是：一帧里 MFSR 等 RTBayer2YUV 的 YUV 输出，RTBayer2YUV 又等 RealTimeDisplay 的 RDI 输出，RealTimeDisplay 却在等 sensor 的 raw buffer —— 四层 dependency 形成环状等待假象，实际是 DRQ 缺乏跨 Node 的 request 粒度追踪能力。Feature2 的破局点，不是加更多 pipeline 节点，而是把整个处理逻辑重构成一张有向无环图（DAG）：FeatureGraph 是图结构本身，FeatureNode 是顶点，Link 是带状态、带 request ID、带 port 映射的有向边。m_linkData 不是辅助表，它是图的邻接表实现；WalkAllExtSinkLinks 不是初始化扫描，它是从 sink 端反向触发的拓扑排序起点；Sequence(-1)/Sequence(0) 也不是两个执行阶段，而是图遍历中“收集依赖”与“触发执行”的原子切分。真正让 RTBay2YUV 实现 sub-16ms 处理、MFSR 在 30fps 下不丢帧的，不是算法优化，是这套图状调度机制让 buffer 生命周期、port 绑定、request 传播全部可建模、可推导、可验证。搞懂它，你才真正拿到高通 camera 架构里那把“调度权钥匙”。

2. FeatureGraph：不是容器，是运行时图引擎——m_linkData 如何用三类 Link 实现跨 FeatureNode 的 request 粒度依赖传播

FeatureGraph 常被误读为 FeatureNode 的集合管理器，就像 std::vector<FeatureNode*>。错。它的本质是运行时图引擎：所有调度决策（谁 ready、谁 wait、谁 submit）都基于 m_linkData 中维护的 Link 状态图谱实时计算得出，而非静态配置。m_linkData 是全局单例，类型为std::vector<ChiFeature2GraphLinkData>，每个元素对应一条 Link，其核心字段不是简单的 src/dst 指针，而是：

• pSrcGraphNode/pSinkGraphNode：指向 FeatureNode 实例的强引用（非 raw ptr，含 refCount）
• portToOutputLinkIndexMap/portToInputLinkIndexMap：map<uint32_t, uint32_t>，key 是 portId（如CAM_INTF_PARM_SENSOR_STREAM_ID），value 是该 port 在本 Node 所有 output/input links 中的索引 —— 这是实现port 级别绑定的关键
• linkState：枚举值NotVisited/Disabled/OutputPending，不是全局状态，而是 per-request state
• requestIndex：该 Link 正在服务的 request 序号（来自上层 URO 的 curProcessSequenceId）

这三者共同构成“请求上下文感知”的图结构。下面拆解三类 Link 如何协同工作。

2.1 ExtSrcLink：上层输入的“请求注入点”，决定整个图的启动边界

ExtSrcLink 描述的是 FeatureGraph 与上层（APP 或 HAL）的接口，即哪些 port 是外部提供的 sink input。例如 Preview 流的 YUV buffer、metadata buffer、RDI buffer 都通过 ExtSrcLink 接入。关键逻辑在WalkAllExtSinkLinks()中：

// chi_feature2_graph.cpp for (uint32_t extSinkLinkIndex = 0; extSinkLinkIndex < numSinkLinks; ++extSinkLinkIndex) { ChiFeature2GraphLinkData* pExtSinkLinkData = &m_linkData[extSinkLinkIndex]; // 初始全设为 Disabled，避免未使用 port 干扰调度 pExtSinkLinkData->linkState = ChiFeature2GraphLinkState::Disabled; // 仅当上层明确请求该 port 时，才激活 if (IsPortRequestedByURO(pExtSinkLinkData->portId)) { pExtSinkLinkData->linkState = ChiFeature2GraphLinkState::OutputPending; // 关键：将此 requestIndex 和 portId 记入上行 Node 的 requestTable ProcessInputDepsForUpstreamFeatureRequest(pExtSinkLinkData, requestIndex); } }

提示：IsPortRequestedByURO()并非简单查表，而是解析UsecaseRequestObject中的m_extSinkPortIdToChiStreamMap—— 这个 map 是 configure_streams() 阶段由 APP 通过CHI_STREAM_TYPE_PREVIEW等枚举动态注册的。这意味着同一份 FeatureGraph 二进制（如com.qti.feature2.gs.so），在不同 usecase（Preview vs Video vs ZSL）下，激活的 ExtSrcLink 子集完全不同，图结构是 runtime 动态裁剪的。

ProcessInputDepsForUpstreamFeatureRequest()的作用是：根据当前requestIndex，在pSrcGraphNode->requestTable中创建或扩展条目，并将pExtSinkLinkData的 port 信息存入requestTable[requestIndex]。requestTable是std::vector<std::vector<ChiFeature2RequestOutputInfo>>，其 size() 即为该 Node 当前需处理的 request 数量，而requestTable[i].size()就是第 i 个 request 的 output port 数量。这才是Ready状态判定的基础：CheckAllOutputLinksReadyToProcessRequest()函数遍历pSrcGraphNode->portToOutputLinkIndexMap，检查每个 output link 的linkState == OutputPending且该 link 已被requestTable引用 —— 缺一不可。

2.2 ExtSinkLink：下游输出的“请求出口”，驱动 result 反向传播路径

ExtSinkLink 与 ExtSrcLink 对称，描述 FeatureGraph 向上层返回的 output port，如CAM_INTF_PARM_OUTPUT_STREAM_ID。但它不直接参与 request 启动，而是在ProcessResult()阶段起关键作用。当某个 FeatureNode 完成 Sequence(0) 执行，camx 返回ProcessResultMessage时，Feature2 不是简单地 release buffer，而是：

1. 解析 message 中的hBuffer和portId
2. 在m_linkData中查找linkType == ExternalSink && portId == message.portId
3. 通过pSinkGraphNode找到接收方 Node（通常是上层 APP 的 callback handler）
4. 调用pSinkGraphNode->OnBufferResult()，并将requestIndex从 link 中还原（因为pExtSinkLinkData在WalkBackFromLink()时已将requestIndex写入pSinkGraphNode->requestTable）

这个设计彻底解耦了 result 传递与 request 提交：submit 时只关心 dependency 满足，result 返回时只关心 portId 和 requestIndex 匹配。没有全局 sequence counter，没有隐式 request ID 传递 —— 所有上下文都固化在 Link 结构体内。

2.3 InternalLink：FeatureNode 间的“神经突触”，支持 virtual link 与 stage 复用

InternalLink 是 FeatureGraph 区别于 CamX pipeline 的核心创新。CamX 中 IFE→IPE 是固定物理连接，而 Feature2 中Bayer2YUV → RealTimeDisplay是逻辑连接，且可动态配置。InternalLink字段包含：

• pSrcGraphNode/pSinkGraphNode：同上，但指向图内其他 FeatureNode
• upstream/downstream标志：用于WalkBackFromLink()递归遍历时区分方向
• virtualLinkFlag：布尔值，ZSL 场景下为 true，表示该 link 不真实传输 buffer，仅用于 dependency 传递（如 metadata 通知）

最精妙的是对stageId和stageSequenceId的支持。以 MFSR 为例，其StageDescriptor定义了 5 个 stage：BlendInit、BlendLoop[0]、BlendLoop[1]、BlendLoop[2]、Postfilter。每个 stage 对应一条独立 pipeline（如ipe_blend_0、ipe_blend_1），但它们共享同一组 input buffer（前一帧的 YUV）。InternalLink通过stageId字段标识该 link 属于哪个 stage，而stageSequenceId（如BlendLoop[1]的stageSequenceId=1）则用于在CreatePipeline()时选择具体 pipeline 实例。m_linkData中一条 InternalLink 可能同时关联多个 stageSequenceId，靠requestTable中的requestIndex映射到具体实例 —— 这正是maxProcessSequence=3（MFSR 最大 3 帧循环）的实现基础。

注意：InternalLink的linkState变更不发生在WalkAllExtSinkLinks()，而是在ProcessGetInputDependencyMessage()中。当上游 Node 的 output buffer 就绪，它会主动遍历自己的portToOutputLinkIndexMap，找到所有linkType==Internal且portId匹配的 link，将其linkState设为OutputPending，并调用WalkBackFromLink()触发下游 Node 的 dependency 检查。这是真正的事件驱动图更新，而非轮询。

3. CHITargetBufferManager：不是 buffer 分配器，是跨 FeatureNode 的 buffer 生命周期协约引擎

CHITargetBufferManager（CTBM）常被简化为“封装了 ImageBufferManager”，这是危险的误解。它真正的角色，是定义并强制执行 FeatureNode 之间关于 buffer 使用权的协约（Contract）。CamX 中 buffer 生命周期由 pipeline node 自主管理，易出现 double-free 或 use-after-free；而 CTBM 通过三个队列（ImportList、ProducerList、ConsumerList）和 refCount 的严格状态机，确保每个 buffer 在任意时刻只属于一个明确的“责任主体”。其设计哲学是：buffer 不是资源，而是消息载体；refCount 不是计数器，而是所有权令牌。

3.1 三队列模型：Import/Producer/Consumer 的语义鸿沟与流转契约

CTBM 的三个队列绝非简单缓存，而是承载不同所有权语义的状态槽：

关键流转逻辑在SetupTargetBuffer()中：

// chi_target_buffer_manager.cpp CDKResult CHITargetBufferManager::SetupTargetBuffer( ChiTargetBufferHandle* pTargetBufferHandle, ChiFeature2RequestObject* pRequestObject) { CDKResult result = CDKResultSuccess; CHIBufferNode* pNode = nullptr; if (pTargetBufferHandle->isExternal) { // 外部 buffer：从 ImportList 取出节点，挂到 ProducerList pNode = FindNodeInImportList(pTargetBufferHandle->hBuffer); if (nullptr != pNode) { RemoveNodeFromImportList(pNode); AddNodeToProducerList(pNode); // refCount 设为 1 } } else { // 内部 buffer：新申请节点，通过 ChiBufferManager 分配内存 pNode = AllocateNewNode(); ChiBufferManager::AllocateBuffer(&pNode->bufferInfo); AddNodeToProducerList(pNode); // refCount 设为 1 } // 将 pNode 关联到当前 request，供后续 Submit 使用 pRequestObject->SetTargetBufferNode(pTargetBufferHandle->portId, pNode); return result; }

提示：pTargetBufferHandle->isExternal的判定依据是portId类型。若portId属于CAM_INTF_PARM_OUTPUT_STREAM_ID等预定义 sink port，则为 external；若为CAM_INTF_PARM_INTERNAL_BUFFER_ID，则为 internal。这个判定发生在CreateUsecaseRequestObject()阶段，由URO的m_extSinkPortIdToChiStreamMap和m_internalPortIdToBufferTypeMap共同决定。

3.2 refCount 的双重语义：跨 Node 传递与本地复用控制

refCount 在 CTBM 中承担两种截然不同的职责：

1. 跨 Node 传递语义：当 buffer 作为 output 从 Node A 传给 Node B 时，UpdateTarget()调用：

   // Node A 的 ProcessResult 中 CHITargetBufferManager::UpdateTarget(pOutputNode, pDownstreamNode); // 内部执行： // 1. pOutputNode 从 ProducerList 移除，refCount-- // 2. pOutputNode 挂到 ConsumerList，refCount++ （因为下游开始消费） // 3. 返回 TargetBufferInfo 给下游 Node B，其中 refCount=1

   此时 refCount=1 表示“下游已声明消费意图，但尚未完成处理”。

2. 本地复用语义：当同一 buffer 被同一 FeatureNode 多次复用（如 MFSR 的 reference frame），CTBM 通过minNumOfBuffers参数控制最小保有量：

   void CHITargetBufferManager::ReleaseTargetBuffer(CHIBufferNode* pNode) { pNode->refCount--; if ((0 == pNode->refCount) && (ProducerList->NumNodes() + ConsumerList->NumNodes() >= m_minNumOfBuffers)) { // 仅当总 buffer 数 >= minNumOfBuffers 时，才真正释放内存 ChiBufferManager::FreeBuffer(&pNode->bufferInfo); FreeNode(pNode); } }

   m_minNumOfBuffers在Create()时由URO的maxProcessSequence决定（如 MFSR 为 3），确保即使所有 request 都完成，至少保留 3 个 buffer 供下一帧复用。这是 RealTime 场景零 malloc 的关键。

3.3 Buffer 生命周期的完整闭环：从 Import 到 Release 的七步状态机

一个 buffer 的完整生命周期如下（以 Preview YUV buffer 为例）：

1. Import：APP 调用CHI_STREAM_REGISTER_BUFFER()，CTBM 创建CHIBufferNode，存入ImportList，refCount=0
2. Setup：SetupTargetBuffer()将 node 移至ProducerList，refCount=1，Node A 获得写权
3. Submit：Node A 将pNode->bufferInfo提交给 camx pipeline
4. Produce：camx 处理完成，触发ProcessResultMessage，CTBM 收到后调用UpdateTarget()
5. Consume：UpdateTarget()将 node 移至ConsumerList，refCount=1（下游 Node B 开始读）
6. Release Input：Node B 处理完毕，在ProcessResult()中调用ReleaseTargetBuffer()，refCount=0
7. Recycle or Free：若ProducerList+ConsumerList总数 ≥minNumOfBuffers，node 留在ConsumerList待复用；否则FreeBuffer()

注意：步骤 4 和 5 中，UpdateTarget()的调用者是上游 Node（Producer），而非 camx。camx 只负责触发回调，CTBM 主动管理流转。这避免了 camx callback 中复杂的 buffer 管理逻辑，将所有权转移完全收口到 CTBM。

4. ProcessRequest 状态机：不是两阶段执行，是 request 粒度的图遍历状态同步协议

ProcessRequest()常被理解为“先 setup dependency，再 submit buffer”，这掩盖了其本质：它是 FeatureNode 对 FeatureGraph 全局图状态的本地镜像同步协议。每个 FeatureNode 的FeatureRequestObject（FRO）状态机，不是独立运行，而是通过m_linkData中 Link 的linkState变更来驱动。Sequence(-1)和Sequence(0)不是时间先后，而是图遍历中“依赖发现”与“执行触发”的逻辑分界。

4.1 FRO 状态机的四个核心状态及其图语义

FRO 的五种状态（Initialized/ReadyToExecute/InputResourcePending/Executing/OutputResourcePending）中，前三种是CanRequestContinue()返回 true 的活跃态，后两种是终态或中间态。其转换完全由 Link 状态驱动：

关键洞察：ReadyToExecute状态的判定，不依赖 camx 的 ready 队列，而完全基于m_linkData中本 Node 的 output links 状态。这意味着即使 camx 的某个 pipeline node 因 hardware busy 暂停，只要linkState仍是OutputPending，Feature2 就认为该 output 有效，可继续调度下游 —— 这是 RealTime 场景下避免 pipeline stall 的根本保障。

4.2 Sequence(-1)：不是“准备 dependency”，是构建 request-aware 的 dependency 图

Sequence(-1)的核心函数PopulateDependency()，其逻辑远超字面意义：

// chi_feature2_base.cpp CDKResult ChiFeature2Base::PopulateDependency( ChiFeature2RequestObject* pRequestObject) { CDKResult result = CDKResultSuccess; UINT8 requestId = 0; for (requestId = 0; requestId < pRequestObject->GetNumRequests(); requestId++) { // 获取该 request 的 output ports 列表 std::vector<ChiFeature2RequestOutputInfo>* pRequestOutputs = &pRequestObject->GetRequestTable()[requestId]; for (auto& outputInfo : *pRequestOutputs) { // 根据 outputInfo.portId，在 m_linkData 中查找所有 InternalLink std::vector<uint32_t> linkIndices = FindInternalLinksByPortId(outputInfo.portId); for (uint32_t linkIndex : linkIndices) { ChiFeature2GraphLinkData* pLinkData = &m_linkData[linkIndex]; // 关键：将当前 requestId 写入上游 Node 的 requestTable // 这样当上游 output 就绪，就能精准通知 "requestId=2 的 port X 已 ready" pLinkData->pSrcGraphNode->AddDependencyRequest(requestId, outputInfo.portId); } } } return result; }

AddDependencyRequest()的实现，是将(requestId, portId)对存入pSrcGraphNode->dependencyMap，这是一个std::map<uint32_t, std::set<uint32_t>>，key 是上游 Node 的 request ID，value 是本 Node 期待的 port ID 集合。当上游 Node 的ProcessResult()执行时，它会遍历自己的dependencyMap，找到所有等待本 port 的下游 request ID，并将对应 link 的linkState设为OutputPending，再调用WalkBackFromLink()。这就是 request 粒度的、精准的、无广播的 dependency 通知机制。

4.3 Sequence(0)：不是“执行 submit”，是向 camx 注入 request-context-aware 的 buffer binding

Sequence(0)的OnExecuteProcessRequest()，其核心是SetBufferInfo()，但参数绝非简单 buffer handle：

// chi_feature2_base.cpp CDKResult ChiFeature2Base::SetBufferInfo( ChiFeature2RequestObject* pRequestObject, UINT8 requestId) { CDKResult result = CDKResultSuccess; ChiFeature2RequestInfo* pRequestInfo = pRequestObject->GetRequestInfo(requestId); // 遍历本 request 的所有 input port for (uint32_t inputPortIndex = 0; inputPortIndex < pRequestInfo->numRequestInputs; inputPortIndex++) { ChiFeature2RequestInputInfo* pInputInfo = &pRequestInfo->pRequestInput[inputPortIndex]; // 从 m_linkData 中找到对应的 InternalLink 或 ExtSrcLink ChiFeature2GraphLinkData* pLinkData = FindLinkByPortId(pInputInfo->portId); // 关键：根据 link 的 requestIndex，找到上游 Node 的 output buffer node CHIBufferNode* pNode = pLinkData->pSrcGraphNode->GetOutputBufferNode( pLinkData->requestIndex, pInputInfo->portId); // 将 pNode->bufferInfo 绑定到 camx 的 input port camxSession->SetInputBuffer(pInputInfo->portId, &pNode->bufferInfo); } // 同理处理 output port，调用 SetupTargetBuffer() for (uint32_t outputPortIndex = 0; outputPortIndex < pRequestInfo->numRequestOutputs; outputPortIndex++) { ChiFeature2RequestOutputInfo* pOutputInfo = &pRequestInfo->pRequestOutput[outputPortIndex]; SetupTargetBuffer(&pOutputInfo->targetBufferHandle, pRequestObject); } return result; }

GetOutputBufferNode(requestIndex, portId)是精髓：它确保了即使同一 port（如CAM_INTF_PARM_RDI_BUFFER_ID）在不同 request 中被多次使用（如 MFSR 的 loop[0] 和 loop[1]），也能精准返回对应 request 的 buffer node。CamX 的SetInputBuffer()接收的不是裸指针，而是CHIBufferNode*的封装体，其中包含了完整的 buffer info、fence、refCount —— 这使得 camx 在硬件层面提交时，已天然携带了 Feature2 的所有权语义。

5. 避坑指南：Feature2 开发中 5 个血泪经验总结的典型翻车现场

Feature2 的强大源于其抽象，但抽象也埋下了深坑。以下问题均来自某跨平台图像处理 Demo 的真实调试记录，每个都曾导致整机 camera 黑屏或 latency 爆表。

5.1 现象：Preview 流正常，Video 流必 crash，log 显示CHIBufferNode: invalid refCount -1

原因：在configure_streams()阶段，Video usecase 的URO未正确注册CAM_INTF_PARM_VIDEO_STREAM_ID到m_extSinkPortIdToChiStreamMap，导致WalkAllExtSinkLinks()中该 port 的 ExtSrcLink 保持Disabled状态。但ProcessRequest()仍尝试为该 port 创建requestTable条目，SetupTargetBuffer()时传入的pTargetBufferHandle为 null，AddNodeToProducerList()传入空指针，后续ReleaseTargetBuffer()对 null node 操作 refCount。
解决：在configure_streams()中，必须为 usecase 支持的所有 stream type 显式调用URO->RegisterSinkPort(portId, streamType)。可用ChiFeature2UsecaseRequestObject::ValidateSinkPorts()辅助校验。

5.2 现象：RTBayer2YUV 处理延迟稳定在 33ms，远超预期的 16ms，perf显示大量chi_feature2_graph::WalkBackFromLink调用

原因：RTBayer2YUV的StageDescriptor中，dependency字段错误地将CAM_INTF_PARM_RDI_BUFFER_ID设为必需，但RealTimeDisplay的 output port 实际是CAM_INTF_PARM_RDI_BUFFER_ID的 alias（如CAM_INTF_PARM_RDI_ALIAS_ID）。WalkBackFromLink()在CheckAllOutputLinksDisabled()时，因 portId 不匹配，误判为所有 output link 均Disabled，触发无限递归。
解决：dependency字段必须与上游 Node 的output portId严格一致。可在DoFeatureCreate()的PrepareStageData()中添加断言：ASSERT(UpstreamNode->HasOutputPort(dependencyPortId))。

5.3 现象：MFSR 在连续拍照时，第 3 张开始出现 YUV 数据错乱，adb logcat显示CHITargetBufferManager: buffer reuse conflict

原因：m_minNumOfBuffers设置为 2（误以为双缓冲足够），但 MFSR 的maxProcessSequence=3，导致第 3 帧启动时，reference frame buffer 被过早FreeBuffer()，新帧复用到已被释放的内存区域。
解决：m_minNumOfBuffers必须 ≥maxProcessSequence。在CHITargetBufferManager::Create()中，应从URO->GetMaxProcessSequence()获取值，而非硬编码。

5.4 现象：ZSL 场景下，metadata 流偶尔丢失，导致 AF 不工作，ProcessMetadataCallback()未被调用

原因：ZSL 的virtual InternalLink未设置virtualLinkFlag=true，导致ProcessGetInputDependencyMessage()试图从该 link 的pSrcGraphNode获取 buffer node，但 virtual link 无真实 buffer，返回 null，linkState无法设为OutputPending，下游 metadata consumer 永远卡在InputResourcePending。
解决：在FeatureInternalLinkDesc的 XML 定义中，ZSL metadata link 必须显式添加virtual="true"属性，并在DoFeatureCreate()的PrepareInternalLinkData()中解析并设置pLinkData->virtualLinkFlag = true。

5.5 现象：加载自定义com.qti.feature2.myalgo.so后，系统 camera app 启动失败，log 显示dlopen failed: cannot locate symbol 'ChiFeature2Graph::Create'

原因：so 文件编译时未链接libchi-cdk.so，或链接了错误版本（如 v1.2 的 so 链接了 v1.3 的 header）。ChiFeature2Graph::Create()是 weak symbol，若链接时未解析，runtime 会 fallback 到 stub 实现，返回 null。
解决：编译时必须添加-lchi-cdk，并在Android.mk中指定LOCAL_SHARED_LIBRARIES := libchi-cdk。用readelf -d libmyalgo.so | grep NEEDED确认依赖列表包含libchi-cdk.so。

6. 设计取舍的终极拷问：为什么 Feature2 不直接复用 CamX 的 DRQ，而要重造一套图引擎？

这个问题直指 Feature2 的灵魂。表面看，CamX 的 DRQ（Dependency Ready Queue）已实现了 node 级 dependency 管理：AddDeferredNode()将有依赖的 node 挂 deferred 队列，DispatchReadyNodes()将满足依赖的 node 移入 ready 队列。既然如此，Feature2 为何要抛弃这套成熟机制，从头实现m_linkData+WalkAllExtSinkLinks+FRO状态机？答案藏在三个被 CamX DRQ 故意忽略的维度里：request 粒度、port 粒度、usecase 动态性。

6.1 CamX DRQ 的三大隐式假设，正是 Feature2 要打破的枷锁

这并非技术炫技。某高校实验室曾做过对比实验：将 MFSR 逻辑强行塞入 CamX pipeline（IFE→IPE→CPP），在 30fps 下，DRQ 因频繁的 ready/deferred 切换导致平均 latency 28ms，峰值达 45ms；而 Feature2 图引擎下，稳定在 14.2±0.3ms。差距的根源，是 DRQ 的IsPortReady()返回 true 时，它不知道这个 port 的 buffer 是为第几帧准备的 —— 它只认“端口”，不认“上下文”。

6.2 图引擎的验证方法：如何证明你的 FeatureGraph 真正按 DAG 执行？

理论再完美，也要可验证。Feature2 提供了三层验证手段，缺一不可：

1. 编译期验证：chi_feature2_validator工具。它解析feature2.*.so的ChiFeature2Descriptor，检查StageDescriptor中的dependency是否形成环路。命令：chi_feature2_validator -i com.qti.feature2.mfsr.so --check-dag。若输出Cycle detected: Bayer2YUV -> MFSR -> Bayer2YUV，说明 XML 中存在dependency循环，必须修正。

2. 启动期验证：CHI_LOG_LEVEL=4下的FeatureGraph初始化 log。关注ChiFeature2Graph::Create()后的Link summary：

   [CHI] FeatureGraph: 5 nodes, 12 links (ExtSrc:3, ExtSink:2, Internal:7) [CHI] Link[0]: ExtSrc, port=0x1001, state=Disabled, requestIndex=0 [CHI] Link[5]: Internal, port=0x2002, state=OutputPending, requestIndex=1

   若state列大量出现NotVisited，说明WalkAllExtSinkLinks()未正确触发，需检查URO的 port 注册。

3. 运行期验证：perftrace +m_linkDatadump。在ProcessRequest()关键点插入__android_log_print(ANDROID_LOG_DEBUG, "CHI", "FRO[%d] state=%s, linkState[%d]=%d", requestId, StateName(), linkIndex, m_linkData[linkIndex].linkState)。用adb shell perf record -e sched:sched_switch -a sleep 5抓 trace，再用perf script | grep "FRO\["过滤，可清晰看到每个 request 的 state 转换与 linkState 变更的严格时序对应 —— 这是图引擎在真实硬件上运行的铁证。

从那以后我每次写新的 FeatureNode

本文还有配套的精品资源，点击获取