CANN Runtime API 可选组件产品级编译隔离实战三步分阶段方案与 ApiImplMbuf 案例解析【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime导读本指南面向 CANN Runtimeruntime仓库的开发者系统讲解如何将某产品不支持某 API 组件从依赖链接器回收未使用函数升级为组件源文件根本不进入目标产品构建的产品级编译隔离方案。文章以 SKILL.md 为骨架融合其参考文档method.md、mbuf-case.md、risk-and-validation.md、submission.md并以当前仓库中 Mbuf 组件的工厂解耦实现、arch5162 平台桩文件与 CMake 源列表作为源码证据。读完你将掌握如何确认裁剪输入、如何追踪调用链并建立源文件/符号/依赖四张表、如何按自适应准备 → 工厂解耦 → 目标产品隔离三步分阶段上库参考 PR4264/PR4265/PR4254 的 Mbuf 案例、以及如何用对象缺失、ABI 差分、ldd -r和同基线体积对比完成可验证、可回退的隔离。一、什么是 Runtime API 可选组件隔离在 CANN Runtime 中公开 C APIacl/rt/rts系列通常经由统一的 API 层ApiXxx、具体实现层ApiImplXxx和 driver/provider 层逐层转发。传统做法是即使某芯片或构建 target 不使用某个组件例如 arch5162 不使用 Mbuf组件源文件仍会被编译进libruntime.so只是期望链接器的--gc-sections把未引用函数回收掉。组件隔离的核心主张是将不支持某组件落实为源文件不进入目标产品而不是只依赖链接器回收未使用函数同时保持支持该组件的产品行为完全不变并把方案拆成可验证、可回退的阶段。该方案追求三项收益减小libruntime.so体积目标产品不再编译组件实现与 provider 源文件解除公共 Runtime 对具体实现的依赖runtime.cc不再 include 组件具体头文件不再执行其new、sizeof或具体类型日志保留公开 C API 的 ABI裁剪后公开符号集合必须与裁剪前一致不支持语义由平台 API 桩明确提供返回既有 feature-not-support 错误码。二、开始前确认输入开始规划前先确认以下五类信息能从代码和构建配置中确定时直接继续输入项说明示例目标组件组件名、对应 C API、driver/provider 实现ApiImplMbuf及rtMbuf*/rtBuff*API目标产品需要裁剪的芯片或构建 target 及其正式库、UT target、平台实现文件arch5162 及其正式库、UT target兼容要求公开符号是否必须保留不支持时返回哪个错误码保留全部公开 C API 符号统一返回既有 feature-not-support 错误码裁剪目标停止编译的源文件清单、期望减少的动态库或明确的大小限制移除api_c_mbuf.cc、api_impl_mbuf.cc、npu_driver_mbuf.cc交付范围仅分析还是实施、提交 PR 并跟踪 CI实施并分三步提交 PR前置条件若目标组件仍混在主Api/ApiImpl大类中、尚未形成可独立创建的ApiXxx/ApiImplXxx必须先完成模块边界拆分仓库中存在$runtime-api-module-splitSkill 时按其方法执行再使用本隔离方案做产品级编译隔离。三、加载参考文档规划与执行过程中按需读取仓库中的参考文档始终读取 method.md建立调用链、编译单元和产品矩阵制定或执行验证时读取 risk-and-validation.md风险矩阵、验证命令与 CI 判定规划提交、创建 PR 或处理回退时读取 submission.md分步骤上库与回退目标为ApiImplMbuf或涉及 PR4264/PR4265/PR4254 时读取 mbuf-case.md。注意案例只提供已验证模式开始任务时仍需刷新最新主线与 PR 状态。四、基本约束六条红线无论组件如何拆分都必须遵守以下约束支持产品行为不变支持该组件的产品保持原调用链、参数、错误码、日志和对象生命周期ABI 不变目标产品不编译组件实现时公开 C API 符号集合必须与裁剪前一致不支持语义由平台 API 桩明确提供公共层纯净公共runtime.cc不包含可选组件具体头文件不执行其new、sizeof或具体类型日志差异收敛到 CMake平台差异优先收敛到 CMake 源列表、平台工厂和平台 API 文件不要在公共源码新增产品宏证据要硬不以头文件中只有声明推断可链接也不以--gc-sections推断完成隔离必须检查最终引用、目标文件和动态符号同基线对比体积动态库大小必须在同一提交基线、编译器、构建类型、链接参数和 strip 状态下对比。五、执行流程总览隔离按以下五步推进1. 建立边界和基线逐层追踪调用链输出四张表 2. 选择第一步自适应准备按模块特性决定非固定模板 3. 执行第二步公共层与具体实现解耦通用稳定模式 4. 执行第三步目标产品隔离通用稳定模式 5. 验证和上库按风险/验证矩阵逐项取证跟踪 CI5.1 建立边界和基线逐层追踪逐层追踪目标组件的端到端链路公开 acl/rt/rts API - api_c*.cc C 入口 - ApiXxx::Instance / Runtime::ApiXxx_ - ApiImplXxx - driver/provider - 产品 CMake、UT CMake、stub 和导出符号以 Mbuf 为例原调用链为见 mbuf-case.mdrtMbuf*/rtBuff* C API - ApiMbuf::Instance() - Runtime::ApiMbuf_() - ApiImplMbuf - NpuDriver::Mbuf* - HAL Mbuf API输出内容包括源文件矩阵、符号基线、Runtime 生命周期和实际引用证据。不要只搜索类名同时检查 include、sizeof、工厂、虚析构、静态对象、源文件列表和链接输入。5.2 建立四张表按 method.md 建立四张表作为后续三步的设计与验证依据。表一调用链表公开接口C 入口抽象接口具体实现provider/driver目标产品行为rtMbufAlloc等api_c_mbuf.ccApiMbuf::Instance()ApiImplMbufNpuDriver::MbufAlloc返回 not-support同时记录参数检查、错误转换、日志、profiling、Context/Device 隐式行为和对象生命周期。表二源文件矩阵源文件/能力普通产品目标产品普通 UT目标 UT处理决定api_c_mbuf.cc编译不编译保留桩编译编译 not-support 桩平台桩替代api_impl_mbuf.cc编译不编译编译不编译工厂下沉npu_driver_mbuf.cc编译不编译编译不编译编译单元拆分检查 src/runtime/cmake/runtime.cmake 以及所有平台CMakeLists.txt。新增或移动一个.cc时不仅搜索正式目标也搜索静态 UT 源列表和 910B、tiny、cmodel/camodel、arch5162 等单独目标。表三具体类型依赖表搜索以下依赖并按类别归类rg -n \ -e ApiImplXxx|CreateImplXxx|IsImplXxxSupported \ -e sizeof\(ApiImplXxx\)|api_impl_xxx.hpp \ src tests分类记录需要完整类型的new、delete、sizeof、成员访问和模板实例化仅需前置声明的指针、引用和抽象接口工厂、静态注册、单例和跨 SO 符号析构、初始化失败回滚和进程退出路径。结论公共 Runtime 只保留抽象依赖具体分配、对象大小和具体日志归属组件实现编译单元。表四符号表从裁剪前普通/目标库提取真实导出集合不按单一名称前缀猜测。例如 Mbuf 除 15 个rtMbuf*外还有rtBuffGet和rtBuffPut共 17 个公开 C API。记录符号名、类型、可见性、定义文件和裁剪后提供者。内部 C 方法声明不等同于公开 ABI。六、第一步自适应准备编译单元闭合第一步的目标是让组件形成可单独加入或移除的编译单元。具体动作必须按模块特性决定不能机械复制 Mbuf无需修改C API、实现和 provider 已各自在专属源文件依赖闭合则跳过并保存证据原样拆源文件目标方法混在共享.cc中且能按职责完整移动时原样移动并同步所有正式/UT target提取公共基础能力共享.cc中存在其他模块真实复用的代码时只拆组件私有部分不得把无关组件一起标成可选收敛静态注册/全局状态组件由注册器或全局对象隐式拉入时先建立可选注册边界拆分 API 入口文件目标产品需要保留少量 ABI 桩而通用入口与具体实现耦合时先划分平台入口。ApiImplMbuf的第一步采用 PR4264把NpuDriver::Mbuf*方法从混合职责的 npu_driver_queue.cc 原样拆到npu_driver_mbuf.cc并把新文件加入所有原正式/UT target。该做法的要点是不修改 C API 路由不修改 Runtime 创建方式arch5162 仍编译并支持 Mbuf可独立合入和回退。该做法是 Mbuf 案例不是其他模块的固定模板。第一步必须保持所有产品能力不变若产生代码 PR应可独立编译和回退并明确说明其与第二步是否存在技术依赖。七、第二步公共层与具体实现解耦工厂模式该步骤是通用稳定模式目标是把组件裁剪与否的影响从公共代码中彻底剥离提供抽象工厂和能力入口例如CreateImplXxxAndGet()、IsImplXxxSupported()将具体类型分配、sizeof(ApiImplXxx)、分配失败日志和大小日志移动到组件实现编译单元runtime.cc只依赖抽象类型和工厂契约本阶段所有原支持平台仍返回支持并创建原实现不做目标产品裁剪增加工厂分配失败和 Runtime 初始化失败传播 UT。设计边界如下runtime.cc - IsImplXxxSupported() - CreateImplXxxAndGet() : ApiXxx* api_impl_xxx.cc - include api_impl_xxx.hpp - new (std::nothrow) ApiImplXxx - sizeof(ApiImplXxx) - 分配失败与大小日志本阶段所有平台保持支持避免把结构重构与能力变化放在同一 PR。工厂返回空时Runtime 只传播统一初始化错误具体日志由知道完整类型的工厂负责。不要把ApiXxx::Instance()随意移动到实现编译单元。先确认哪个动态库直接调用并提供该符号避免 API 动态库依赖实现动态库中的新符号。Mbuf 案例中ApiMbuf::Instance()继续留在 API 侧当前仓库见 api_mbuf.hpp 中的静态Instance()声明移动到具体实现文件会改变动态库符号归属并可能使普通api_c_mbuf.cc出现跨 SO 未解析引用。对 Mbuf第二步对应 PR4265runtime.cc移除api_impl_mbuf.hpp增加IsImplMbufSupported()将CreateImplMbufAndGet()、new、sizeof(ApiImplMbuf)和日志移入api_impl_mbuf.cc。PR4265 不引用npu_driver_mbuf.cc因此在 Mbuf 案例中与 PR4264 技术独立可单独基于master编译和回退。其他模块必须重新判断不能直接继承这一独立性结论。7.1 当前仓库中的工厂实现证据工厂契约已在当前仓库落地见 api_impl_creator.hpp。该头文件同时声明了多个可选组件的能力入口与工厂例如bool IsImplMbufSupported(); ApiMbuf* CreateImplMbufAndGet(); void DestroyImplMbuf(ApiMbuf* apiImplMbuf);以及 Soma、Event、Esched、Snapshot、RtConfig、DeviceTopology 等组件的同名模式。具体实现见 api_impl_mbuf.ccbool IsImplMbufSupported() { return true; } ApiMbuf* CreateImplMbufAndGet() { ApiMbuf* const apiImplMbuf new (std::nothrow) ApiImplMbuf(); if (apiImplMbuf nullptr) { RT_LOG_OUTER_MSG_IMPL(ErrorCode::EE1013, sizeof(ApiImplMbuf), new); RT_LOG(RT_LOG_ERROR, create ApiImplMbuf failed.); return nullptr; } RT_LOG(RT_LOG_INFO, ApiImplMbuf:Runtime_alloc_size %zu, sizeof(ApiImplMbuf)); return apiImplMbuf; }可以看到new、sizeof(ApiImplMbuf)、分配失败日志与大小日志全部归属实现编译单元正是第二步设计边界的落地形态。抽象接口ApiMbuf在 api_mbuf.hpp 中定义包含 17 个纯虚方法MbufInit、MbufBuild、MbufAlloc、MbufAllocEx、MbufUnBuild、MbufGet、MbufPut、MbufFree、MbufSetDataLen、MbufGetDataLen、MbufGetBuffAddr、MbufGetBuffSize、MbufGetPrivInfo、MbufCopyBufRef、MbufChainAppend、MbufChainGetMbufNum、MbufChainGetMbuf与 17 个公开 C API 一一对应。公共 Runtime 侧的能力入口调用见 runtime.ccif (IsImplMbufSupported()) { apiImplMbuf_ CreateImplMbufAndGet(); }即 Runtime 只依赖抽象类型与工厂契约组件是否创建完全由能力入口决定。八、第三步目标产品隔离该步骤同样采用通用稳定模式依赖第二步以及必要的第一步准备目标平台能力入口返回不支持组件实现指针保持为空从目标产品正式库和 UT target 中移除 C API 通用实现、具体实现和专属 provider 源文件在目标平台 API 文件中保留所有公开 C API 符号签名和可见性不变统一返回约定的不支持错误码为每个公开接口增加目标平台 UT同时保留支持平台正常路径 UT检查目标链接输入不含组件对象、ldd -r无未定义符号、动态符号集合无缺失。目标平台提供的产物为IsImplXxxSupported() false必要时提供返回空的工厂定义满足统一声明对外 C API 不支持桩保留原签名和VISIBILITY_DEFAULT每个公开接口的 not-support UT。目标 CMake 同时移除通用 C API 文件、具体实现文件、专属 provider 文件正式 target 与平台 UT target 必须一致。支持产品继续使用原链路不应经过平台不支持桩。8.1 Mbuf 第三步PR4254 与当前仓库的 arch5162 桩Mbuf 的第三步对应 PR4254启用 arch5162 隔离arch5162 能力入口返回不支持不创建ApiImplMbuf从 arch5162 正式/UT target 移除api_c_mbuf.cc、api_impl_mbuf.cc、npu_driver_mbuf.cc在 arch5162 平台 API 文件案例中为api_c_arch5162.cc提供不支持桩增加 arch5162 逐接口 UT支持产品继续走原链路。当前仓库的 arch5162.cmake 可以印证平台桩思路它保留了api_c_mbuf.cc注释明确标注17 stubs并引用impl/api_impl_mbuf_stub.cc即目标平台通过平台 API 桩文件保持 17 个公开符号的 ABI 完整性。类似的桩文件还存在于 api_impl_mbuf_stub.cc。同时在 src/runtime/cmake 下的runtime.cmake、cmodel.cmake、v200.cmake、tiny.cmake等平台配置中分别维护各自的 Mbuf 源文件集合体现了平台差异收敛到 CMake 源列表的约束。合入关系PR4264 Mbuf driver 编译单元准备 ---\ - PR4254 arch5162 隔离 PR4265 Runtime 工厂解耦 ---/在前两步未合入时允许用聚合分支验证最终状态正式分步骤上库时第三步必须在前置 PR 实际合入后重放到最新主线并重新执行 CI。九、C 声明与链接判断类头文件可以保留未在目标产品中定义的成员函数声明只要目标链接中没有对这些函数的实际引用。-Wl,--no-undefined检查链接输入中的未解析引用不要求每个未使用声明都有定义。以下情况会形成实际依赖直接或间接调用函数虚函数被纳入目标所需 vtable取函数地址显式模板实例化或静态注册引用析构或初始化路径调用链接脚本或--whole-archive强制拉入含引用对象。因此必须结合nm -C、readelf、link.txt、对象列表和最终ldd -r判断不能只看源码搜索结果。Mbuf 案例的结论是NpuDriver头文件保留 Mbuf 成员声明不会自动产生链接错误arch5162 移除 C API、ApiImplMbuf和 driver 实现后没有代码引用这些成员因此-Wl,--no-undefined仍可通过。十、风险与验证矩阵按 risk-and-validation.md 逐项核对风险域典型问题必查证据能力判断仍创建被裁剪实现或支持产品误返回不支持平台工厂定义、初始化 UT、产品矩阵ABI删除 C API 源文件后导出符号缺失裁剪前后nm -D集合差分、API Check调用链支持产品路由、参数或错误语义变化普通产品原 UT、成功/失败路径对比具体依赖runtime.cc仍有 include、sizeof、new源码扫描、依赖.d文件、编译结果链接vtable、工厂或 driver 方法未定义link.txt、nm -C -u、ldd -rCMake正式 target 已移除但 UT/其他产品遗漏新增源文件全产品源文件矩阵、目标编译生命周期工厂失败未传播部分初始化对象泄漏分配失败注入、Runtime 回滚/析构 UT平台桩签名、可见性或错误码不一致头文件对照、逐接口 not-support UT静态副作用组件对象虽未调用但静态注册仍执行对象缺失证明、初始化行为检查体积统计条件不同或 debug 信息掩盖收益同基线构建、stat、size、strip 状态覆盖率新能力分支和失败路径未覆盖增量覆盖率报告、定向失败 UT回退聚合提交无法单独恢复目标产品能力分阶段提交与反向回退演练10.1 分步验证要点第一步有代码改动时比较移动前后函数集合和实现内容确认仅调整编译单元归属所有原先获得定义的正式/UT target 都加入新源文件支持产品和目标产品仍走原调用链并通过原 UT若提取公共能力验证没有扩大公共层职责。若跳过则保存专属源文件、依赖闭合和 target 可单独移除的证据。第二步普通产品、目标产品均编译并创建原组件实现runtime.cc不包含具体实现头文件依赖文件中也无该头文件工厂成功、具体对象分配失败、Runtime 失败传播均有 UT普通动态库ldd -r无未定义符号API 单例或入口符号仍由原动态库提供本阶段不改变任何平台的 feature-not-support 行为。第三步目标正式库与目标 UT target 均不编译组件三个层次的源文件目标 Runtime 初始化跳过组件创建且其他组件正常初始化所有公开接口逐一返回约定的不支持错误码支持产品原功能 UT 保持通过目标和基线公开符号集合一致-Wl,--no-undefined构建和ldd -r均通过cmodel/camodel、关键芯片目标、API Check 和 PreSmoke 均执行并通过。10.2 常用证据命令以仓库当前 target 和构建目录为准调整路径git diff --check origin/master...HEAD git diff --stat origin/master...HEAD git log --oneline origin/master..HEAD rg -n api_impl_xxx|ApiImplXxx|CreateImplXxx|IsImplXxxSupported src tests find target-build -type f \ \( -name api_c_xxx.cc.o \ -o -name api_impl_xxx.cc.o \ -o -name provider_xxx.cc.o \) rg -n api_impl_xxx.hpp target-build/**/runtime.cc.o.d ldd -r target-build/src/runtime/libruntime.so nm -D --defined-only baseline-lib | awk {print $3} | sort baseline-symbols nm -D --defined-only target-lib | awk {print $3} | sort target-symbols comm -3 baseline-symbols target-symbols stat -c %s baseline-lib target-lib size baseline-lib target-lib符号基线应按公开头文件和裁剪前库确定不要只使用名称前缀过滤如 Mbuf 的rtBuffGet/rtBuffPut就不以rtMbuf开头。find无输出只能证明指定对象文件不存在还需结合链接和行为检查。十一、测试要求至少覆盖以下六类用例支持产品组件 API 正常和底层失败路径工厂new (std::nothrow)返回空分配失败注入Runtime 收到空工厂结果并返回初始化错误失败传播目标产品每个公开 C API 的 not-support 路径逐接口 UT目标产品 Runtime 初始化时组件指针保持为空其他 Runtime 组件不受影响。运行定向用例后再运行承载改动源文件的完整测试 binary。用例数量不是唯一证据同时记录命令、target、过滤器和结果。十二、CI 判定创建或更新每个 PR 后读取线上任务表重点核对正式 X86/ARM 编译Runtime common、910B、v201、David 等 UTUT_Test_camodel_check增量覆盖率报告API Check、PreSmokepre-commit、codespell、markdownlint 和链接检查。若UT_Test_camodel_check失败进入对应流水线读取日志不根据总状态猜测原因覆盖率失败时下载报告定位新增未覆盖行后补异常路径 UT。只把实际结束且目标任务成功的流水线写成通过警告、跳过和不可读日志单独记录。十三、分步骤上库、聚合分支与回退13.1 步骤关系步骤稳定目标是否固定实现1. 自适应准备形成可独立裁剪的编译单元否可拆文件、提公共能力、收敛注册依赖或直接跳过2. 工厂解耦公共 Runtime 不感知具体实现所有平台行为不变基本固定3. 产品隔离目标产品停编译组件ABI 桩返回不支持基本固定第一步和第二步是否可并行或独立合入必须由依赖图证明第三步始终依赖第二步以及第一步中确有必要的准备。13.2 PR 边界第一步 PR只解决编译单元闭合。包含模块特有的源文件拆分或依赖收敛以及所有产品/UT CMake 同步不包含Runtime 工厂重构、目标产品能力关闭、ABI 桩。验收所有产品能力和调用链不变独立 CI 通过回退单独回退该 PR 恢复原编译单元布局。若无需改动不创建空 PR在方案中提供可直接移除专属文件的证据。第二步 PR包含能力入口、抽象工厂、具体分配/日志下沉、Runtime 抽象调用和失败 UT不包含任何产品返回不支持、CMake 删除组件源文件、C API 桩。回退单独恢复公共 Runtime 直接创建具体实现的旧逻辑。第三步 PR必须基于前置步骤实际合入后的最新origin/master包含目标平台能力关闭、目标 CMake 删除源文件、公开 C API 桩、平台 UT 和设计文档更新不包含支持产品行为调整、无关模块裁剪、前两步已合入内容。回退优先单独回退本 PR 即可恢复目标产品组件能力前两步可保留。13.3 聚合分支与冲突处理前置 PR 尚未合入时可维护一个包含完整三步的聚合分支用于证明最终编译、行为、ABI 和体积收益但聚合分支不能替代分步骤 PR。流程为先判断第一步与第二步是否存在技术依赖可独立时两者分别基于master验证和提交有依赖时第二步必须等待第一步实际合入再基于最新master提交前两步实际合入后将第三步重放到最新master确认第三步 diff 只剩目标平台差异、桩、UT 和必要文档再运行完整 CI。不要把尚未合入的前置提交永久保留在第三步 PR 中并宣称已完成拆分。每次前置 PR 合入后获取最新origin/master→ 在隔离 worktree 中重放后续单提交 → 按 hunk 解决 CMake、平台 API 和 Runtime 生命周期冲突 → 重新检查 diff 边界和单提交历史 → 完整重跑本地验证和线上 CI。故障回退顺序通常为第三步 → 第二步 → 第一步若第一步与第二步经证明独立只回退引入问题的步骤不做捆绑回退。13.4 建议分支与提交命名Mbuf 案例的建议命名其他模块按实际障碍命名不复用driver-split标题# 第一步 refactor/api-mbuf-driver-split refactor: split NpuDriver Mbuf implementation # 第二步 refactor/api-mbuf-runtime-decouple refactor: decouple Runtime from ApiImplMbuf # 第三步 refactor/arch5162-api-mbuf-isolation refactor: isolate ApiMbuf from arch5162十四、PR 描述要求按仓库当前模板填写 PR 描述并至少说明本步骤解决的单一问题及不包含项与前后步骤的技术依赖和推荐合入顺序支持产品行为等价和目标产品不支持语义ABI、对象缺失、链接、大小和 UT 证据实际本地命令和线上流水线 ID独立回退方式。代码变化后立即更新线上 PR 描述并回读确认CI 失败修复后替换过期验证结论不保留计划通过式表述。推送和创建/更新 PR 前读取仓库gitcode-prSkill 和.gitcode/PULL_REQUEST_TEMPLATE.zh-CN.md仅在用户明确授权后执行线上写操作。十五、常见错误清单隔离实施中最容易踩的坑详见 method.md 第 7 节只加-ffunction-sections/-Wl,--gc-sections但组件源文件仍编译且静态初始化仍存在从 CMake 移除实现文件却遗漏 Runtime 中的sizeof或失败日志删除目标产品 C API 文件后未补 ABI 桩只按rtXxx前缀统计符号漏掉历史命名接口如rtBuffGet/rtBuffPut只修改正式 CMake遗漏 UT 静态源列表或平台目标将第一步固定成拆 driver 文件导致其他组件产生没有收益的机械重构用不同构建类型或不同 strip 状态比较动态库大小。十六、可迁移与不可机械复用可迁移到其他组件的模式具体类型分配和sizeof下沉到实现编译单元Runtime 只依赖抽象工厂和能力入口IsImplXxxSupported/CreateImplXxxAndGet目标产品通过 CMake 源列表停止编译平台 API 桩保留 ABI 并返回统一不支持错误码对象缺失、符号、链接、失败 UT 和同基线体积验证方法。不可机械复用的假设第一步一定拆 driver 文件所有组件的第一步与第二步都技术独立所有接口都使用rtMbuf*命名Mbuf 的 17 个接口数和错误码可直接套用到其他模块。一句话总结把裁剪做成编译期事实源文件不进产品、公共层无具体依赖而非链接期巧合gc-sections 回收并用分阶段 PR、ABI 差分和对象缺失证据让每一步都可验证、可回退——这就是 CANN Runtime 可选组件产品级编译隔离的全部要点。仓库中 Mbuf 的工厂解耦实现api_impl_creator.hpp、api_impl_mbuf.cc、runtime.cc与 arch5162 的平台桩源列表arch5162.cmake可作为后续组件隔离的直接参照。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考