本专栏将分享阿里云视频云MediaBox系列技术文章，深度剖析音视频开发利器的技术架构、技术性能、开发能效和最佳实践，一起开启音视频的开发之旅。本文为MediaBox技术架构篇，重点从 ACPM介绍、技术架构以及高效管理等方面，介绍如何通过MediaBox ACPM的高效组件管理，来提升音视频终端SDK的稳定性和性能。

阿弗｜作者

01 ACPM介绍

背景

针对行业音视频数字化，阿里云视频云提出了MediaBox终端一体化套件，融合了播放、直播、超低延迟直播、实时音视频通信、短视频创作等多种音视频能力，但这并非简单地把SDK叠加起来，而是通过合理的架构设计、抽离复用各种基础组件等手段，最终构建出一个高性能、高可用、高灵活性、可插拔、易扩展性的一体化SDK。

其中得益于组件的高度复用，终端一体化总能以更小的包体提供同样的能力组合。但随着组件化的深入，组件的版本管理、组件间的依赖关系、组件开发进度不同带来的团队协作问题、组件本身的稳定性和性能等问题都需要更好地解决，因此我们设计了ACPM来统一解决组件化过程中出现的问题。

概念

ACPM全称是Aliyun C++ Package Manager，主要解决C++包管理的问题，同时也负责组件的资源、aar、源码调试等。ACPM的核心目标是简化项目中的依赖库管理，减少繁琐的配置工作，提高开发人员的生产效率，并确保项目的稳定性。

使用流程

包管理工具本身主要解决包的版本管理和依赖关系管理，但其本质是解决团队协作问题，使用工具目的也是为了团队提效，同时在高效中提升音视频终端SDK的性能和稳定性。因此，以下以组件的使用方和提供方两种角色的不同视角来描述工具流程：

图片 1.png

• 依赖组件（使用方）：负责根据描述分析依赖关系、下载对应组件、生成cmake工程需要的编译文件；

• 发布组件（提供方）：负责托管组件静态库（在MTL上）并记录发布时的具体信息以供依赖时分析。

02 技术思路

ACPM始于包管理问题，但我们现在谈论ACPM已经不仅限于包管理，而是整个组件化过程中的一系列工具。组件化的核心思想就是分而治之，我们把庞大复杂的工程拆解为一个个小组件，再组合起来，每个小组件其实都是一个独立的个体。跟SDK开发、应用开发一样，组件开发也有着严格的研发流程，只有把一个个小组件治理好了才能治理好庞大复杂的工程。

要让组件化过程变得高效，我们不仅要解决包管理的问题，还需要关注组件化的整个研发流程，对整体进行优化的同时，也为每个节点提供相应的工具来提高效率。

图片 2.png

03 高效管理

以下针对组件研发流程的每个节点，展开介绍我们是怎样去做的。

组件开发

想要高效地完成组件化，最直接的想法是并行地去做，并行开发每个组件，当然这要求组件本身是独立的、物理隔离的。然而，独立的组件需要独立的工程，要实现组件的多平台复用，这就要求每个组件都要建立平台工程来进行开发调试，其中的工作量无疑是非常重复且繁琐的。

虽然各组件的功能职责各不一样，但每个组件的工程结构实际上是相似的，所以我们在这个环节上提供工具脚本，实现一键搭建标准化的组件工程，让组件开发者只需关注逻辑开发本身即可。

图片 3.png

有意思的是，我们的组件开发工程本身也是通过ACPM包管理组织起来的，充分说明了一切皆组件。

组件测试

虽然组件是可以物理隔离的，但终归还是要组合在一起，想要实现高效融合，这就要求组件融合前已经是稳定的，如果组件本身的问题直到融合后才被发现，那么无论是对于问题的调试还是协作效率来说都是低效的，所以组件发布前都需要经过测试。由于我们的组件都是多平台复用的，如果要求组件的每个版本都对所有平台逐一测试会十分消耗人力，因此，我们需要自动化地去完成这项任务。

基于此，我们提供完整的测试平台进行实现，组件只需在平台上配置好一次任务，后续的所有版本都可以重复使用。我们也提供了各个平台所需的设备，组件开发者只需要编写好测试用例，其他的所有事情都可以自动化完成，这不但提高了组件的开发效率，同时也保障了组件的稳定性。

图片 4.png

组件构建&发布

写代码、编译、调试，是技术同学的日常。在提升开发效率上，减少编译时间是一件收益颇丰的事情，为此，我们绝大部分的组件都会提供各平台的预编译库。但对于多平台复用的组件而言，其中的过程又非常繁琐，况且与源码不一样，预编译库还可能产生难以发现的ABI兼容问题，更何况预编译库的问题追溯也比源码更加困难，因此我们需要记录每一次预编译发布的源码来源、构建过程等以更好地排查问题。

虽然要解决的问题很多，但这在效率上的收益值得我们去逐一攻克。为解决上述问题，我们基于集团的MTL，编写了插件、提供了各平台统一的编译链工具、发布前自动化安全检测、提供机器人提高发布效率等，以此实现组件构建和发布环节的高效管理。

图片 5.png

组件使用

ACPM提供简单而强大的方式集成依赖库，只需编写一个json文件去描述需要的依赖库名字和版本，无需手动下载和编译，工具就会自动地去处理这些步骤，让开发者可以专注于项目的核心开发。

为了让开发更加地高效，工具还会根据开发者当前构建的平台，按需下载对应的资源并做好相应的缓存。

同时，为了方便研发人员使用，工具可以开箱即用，甚至不需要提前安装，只需把工具的仓库作为子模块，研发团队中的其他成员就可以直接使用，大大提高了组件使用效率。

{
  ...
  "dependencies": {
    "包名": "版本号",
    "包名": {
      "version": "版本号",
      "forcedSpecifyVersion": "强制指定的版本号",
      "fromRepository": "正式 或者 开发版本",
      "sourceCodeFirst": "是否优先选用源码依赖",
      "customSourcePath": "自定义源码路径"
    }
  }
  ...
}

我们支持简易地通过名字和版本描述依赖，也支持自定义描述以满足更多的定制需求。

简单的工程（如上述所示）通常不会有问题，但复杂的工程难免会遇到依赖库冲突的问题。ACPM能够自动检测和解决依赖库之间的冲突问题，从而减少由不同库版本引起的问题，确保项目的稳定性和可靠性。

通常，冲突的解决是指找到一个版本使得各个依赖库都能兼容，而兼容的判断依据往往是API的兼容，由于我们提供的库很多都是预编译的库，我们不仅考虑到了API兼容也考虑到了ABI的兼容，从而使项目更加稳定可靠。

此外，在ABI兼容的前提下，我们通过强制指定冲突组件版本，实现自动解决冲突而无需重新编译子组件，以此满足组件高稳定基础上的高效管理需求。

图片 7.png

组件稳定性分析

虽然我们有一系列的手段保障稳定性，但现实是我们总会遇到意想不到的崩溃情况，因此我们需要监控SDK的稳定性情况。为了给客户最小的包体最优的SDK，我们最终会把组件组合成同一个动态库进行提供，并去掉相应的调试符号，但这样我们就很难知道崩溃发生在哪里。这就会占用研发人员更多的时间精力，以及难以对组件本身的稳定性情况有一个量化的认知。

在人工处理流程上，我们发现这个过程是可以通过工具自动化来提高整体效率，所以我们设计了如下流程：

图片 8.png