依赖链的问题
许多通过包管理器 (APM) 安装的 AIR 扩展并不是单独提供的。它们会带来一连串辅助 ANE：共享核心库、Android 支持库、Google Play 服务、Firebase、网络库和图像库。这些辅助组件往往只是因为另一个扩展需要它们才存在。
这些 ANE 中的每一个都会被打包进您的应用，并在启动时加载，无论您的应用是否使用该功能。应用因此变得更大、启动更慢，并在后台做更多工作。
我们在自己的应用中测得的结果
我们的应用传输实时视频和双向语音，而且常常运行在较旧的手机和平板上。2026 年，我们将其中所有第三方扩展替换为我们自己的独立扩展，并在真实设备上比较了结果：
| Android 应用中的扩展 | 45 个，其中 35 个为第三方扩展，大多数是辅助 ANE → 13 个，全部为自有扩展 |
| 应用描述文件 | Android：197 → 133 行（清单附加项 117 → 85），iOS：161 → 126 行。需要维护的清单条目更少，出错的地方也更少 |
| 应用大小 | Android 上 −6.5 MB（−10 %），iOS 上 −5.9 MB（−14 %） |
| 应用启动 | 约快一倍 |
| 后台工作 | 没有分析库或辅助库与视频流同时运行：为视频和语音留出更多 CPU 和带宽，这在较旧的设备上尤为重要 |
冲突与更新压力
当多个扩展共享相同的辅助 ANE 时，它们的版本必须保持一致。一个扩展的新版本往往需要共享辅助组件的新版本，进而需要所有使用这些组件的其他扩展的新版本。
结果是：本不需要的更新、构建时的版本冲突，而且每种组合都必须在每个平台上重新测试。这些工作并不会让您的应用变得更好。
我们的方法：自成一体
把平台库包进一层薄薄的外壳，再挂上一串辅助 ANE，是快速推出大量扩展的捷径。把每个扩展都做得完整且独立，则要花费多得多的功夫：每个扩展都必须恰好带上自己所需的一切，在每个平台上单独测试，并且还要能与其他所有扩展并存运行。我们选择了承担这份工作，好让您的应用不必承受其后果。
- 每个功能一个文件。每个扩展都是单个 ANE。没有核心库，没有辅助 ANE，也不需要包管理器。
- 只包含功能所需的内容。如果需要平台库，例如 Google Play Billing，或在 Android 上用于推送的 Firebase Cloud Messaging，构建时会自动仅添加该库。除此之外别无其他。
- 独立更新。更新一个扩展绝不会迫使您更新另一个扩展。
- 经过生产环境验证。每个扩展都在我们自己的 iOS、Android 和 macOS 应用中运行，并在当前和较旧的设备上经过测试。