声网 rtc sdk 包体积优化：一位开发者的实战心得
做过移动端音视频开发的同学应该都有体会，每次版本迭代最让人头疼的问题之一，就是 APK 或者 IPA 文件体积的膨胀。特别是接入rtc sdk之后，肉眼可见地多了好几MB的包体积。用户体验要讲究，但应用商店的下载转化率也得考虑——毕竟很多人看到动辄上百兆的安装包，直接就划走了。
我自己前前后后参与过不少项目的 SDK 体积优化，也踩过不少坑。今天这篇文章，就想把声网在 RTC SDK 包体积精简这块的实践经验系统性地梳理一下。这些方法论不是凭空来的，很多都是在实际项目中验证过的，希望能给正在为这事发愁的你一些参考。
一、先搞明白：SDK 体积到底大在哪里？
在动手优化之前，我们得先搞清楚 SDK 的体积到底由哪些部分组成。这就好比装修房子，你得先弄清楚承重墙在哪，才能安全地敲掉不必要的隔断。
声网的 RTC SDK 经过这么多年的迭代，内部结构已经比较模块化了。一般来讲，一个完整的 SDK 包主要包含这么几个部分：首先是核心音视频编解码库，不同平台（Android、iOS、Windows、Mac）的实现体积差异挺大；其次是网络传输相关的协议栈和抗丢包算法，这部分是保证通话质量的关键；然后是一些设备适配层和平台相关的桥梁代码；还有文档里可能没细说的，不少 SDK 会内置日志系统、统计上报模块，以及预留的扩展接口。
了解这些构成有什么好处呢？好处就是你可以在打包阶段有针对性地做减法。比如你确定只用音频通话，那视频编解码部分完全可以裁剪掉；如果你只在国内使用，某些海外节点相关的代码就成了冗余。声网的 SDK 在架构设计上就考虑到了这种灵活性，这是很多早期 RTC SDK 做不到的。
二、基础优化策略：这些是最立竿见影的
1. 按需引入，只带走你需要的
这是最直接、效果也最明显的优化思路。声网的 RTC SDK 在发布的时候，其实提供了多个功能模块的独立分包。什么意思呢？就是你不用把整个 SDK 都塞进去，而是可以根据业务场景精确选择。
举个例子，如果你做的是一个语音社交App，根本不需要视频通话功能，那你完全可以只集成音频模块。我见过不少团队，为了图省事，直接把完整 SDK 往项目里一扔，结果光这一项就多了好几MB的体积。实际上，音视频分离之后，单纯的音频 SDK 体积能减少 40% 左右，这个数字在实际项目中是很可观的。
再比如，很多场景下你可能只需要基础的音视频通话能力，而不需要美颜、变声、水印这些附加功能。这些功能在声网 sdk 里都是作为可选插件提供的，单独集成的话，主包的体积基本不受影响。
2. ABI 分割：别让用户下载用不到的代码
Android 平台的开发者对 ABI 这个概念应该不陌生。简单说，不同的手机 CPU 架构（arm64-v8a、armeabi-v7a、x86、x86_64）需要对应的 native 库。很多团队为了省事，会把所有架构的 so 文件都打进包里去，结果就是用户下载了一个比他实际需要大得多的安装包。
声网的 Android SDK 在发布包里面，已经做好了 ABI 分割处理。正确做法是在打包配置里只保留你目标设备支持的架构。比如你确定主要覆盖的是 2018 年以后发布的手机，那 arm64-v8a 基本上就够了。armeabi-v7a 是为了兼容更老的机器，但如果你对老设备没什么执念，完全可以只保留 64 位的版本——不仅体积更小，运行效率也更高。
iOS 平台相对简单一些，因为苹果统一了硬件架构。但要注意 iOS 的 SDK 里面有 simulator 架构和真机架构的区分，打正式包之前一定要把 simulator 的部分剥离掉，这个也是能省出不少空间的。
3. 资源文件的精简处理
SDK 里面一般会带一些默认的资源文件，比如默认的提示音、图标、配置文件等等。这些资源如果你用不到，完全可以想办法替换掉或者直接不打包进去。
声网的 SDK 里有一些多语言的资源文件，如果你确定 App 只支持中文或者英文，可以只保留需要的语言包，其他的语言资源文件删掉就行。另外，有些 SDK 会内置调试用的 UI 素材，这些在正式发布版本里完全可以移除。
有个小技巧，很多资源文件是可以压缩的。比如把 PNG 改成 WebP，体积能减少 30% 左右，而且视觉质量几乎看不出区别。声网的 SDK 在资源这块的体积控制其实做得不错，但如果你自己 App 里还有额外的资源要打包，也要注意统一做一下优化处理。
三、进阶优化：深度定制与架构调整
1. 动态加载：把不常用的功能剥离
除了基础的裁剪，更深度的优化思路是把 SDK 的功能做成动态加载的形式。也就是说，主安装包只包含最核心的功能，而一些低频使用的功能（比如高级美颜、第三方特效）放在服务器上，用户需要的时候再下载。
声网的 SDK 在架构设计上支持这种扩展模式。核心的通话能力是必须随包走的，但某些附加功能可以通过插件化的方式来集成。这样一来，首次安装的体积就能控制在一个比较小的范围内，后续按需下载的插件也不会影响用户的下载转化率。
这种方案的实施难度稍微高一点，需要在 App 架构层面做适配。但对于对包体积要求比较苛刻的产品来说，这是个值得考虑的路线。
2. 編解码器的选择与定制
音视频编解码器是 RTC SDK 里面体积占比比较大的部分。声网的 SDK 默认会内置几种主流编解码器的实现，比如 Opus（音频）、VP8/VP9、H.264/H.265（视频）等等。但实际上，你并不需要把所有编解码器都带进去。
如果你对音质要求不是特别极致，Opus 作为音频编解码器基本能满足大多数场景的需求，而且是开源、专利友好的方案。如果你的用户主要在国内，视频用 H.264 基本上是标配，H.265 虽然压缩率更高，但专利费用和兼容性方面的问题让很多团队望而却步。
另外，很多设备本身硬件层面对某些编解码器是有原生支持的。这种情况下，SDK 里面其实可以不用带软编解码的实现，直接调用硬件能力就行。声网的 SDK 在这方面有做适配，会优先使用系统硬件加速，这也能在一定程度上减少 SDK 的体积。
3. 代码混淆与压缩的配合
很多团队做完代码混淆就觉得万事大吉了，但其实混淆和体积优化之间的关系还挺微妙的。一方面，混淆能缩短类名和方法名，减少最终打包的代码体积；另一方面，如果不加以控制，混淆可能会让一些无用代码没法被彻底识别和剔除。
建议在集成声网 SDK 的时候，配合使用 ProGuard 或者 R8 的完整收缩（shrink）功能。这个功能会递归地分析代码依赖，把那些实际没有被调用的类和方法全部剔除掉。对于 RTC SDK 这种功能比较复杂的库，正确配置 shrinking 规则之后，通常还能再省出几百 KB 的空间。
当然，配置混淆规则的时候要小心，别把 SDK 里面那些通过反射调用的接口给误删了。声网的 SDK 文档里一般会有推荐的混淆配置，按照那个来会比较稳妥。
四、持续监控：把优化变成常态化工作
包体积优化不是一次性的事情，随着 SDK 版本迭代和业务功能增加，体积很容易又涨回去。所以建议在项目里建立体积监控的机制。
具体来说，每次发版之前对比一下包体积的变化，看看多了什么东西。如果涨幅超过了预期，就要排查一下是 SDK 升级带来的，还是自己业务代码引入的。声网的 SDK 更新日志一般会说明新版本体积有没有变化，这个可以作为参考。
还可以考虑在 CI 流程里加入体积检查的步骤，设置一个阈值，超过阈值就报警。这样大家在新功能开发的时候就会对体积的影响有概念，不至于到了发版的时候才发现超了。
五、实战案例：不同场景下的优化效果
为了让大家对这些优化手段的效果有个更直观的感受，我整理了几个典型场景的数据参考：
| 场景类型 | 基础包体积（完整 SDK） | 优化后体积 | 优化幅度 |
| 纯音频通话（Android） | 约 8.2 MB | 约 4.5 MB | 约 45% |
| 视频通话（Android） | 约 12.5 MB | 约 7.8 MB | 约 38% |
| 音视频混合（iOS） | 约 6.8 MB | 约 4.2 MB | 约 38% |
这些数字是怎么来的呢？主要就是综合运用了前面说的几个策略：音频视频分离、ABI 裁剪、资源文件精简、代码收缩。需要说明的是，具体能优化多少跟你使用的 SDK 版本、目标平台、业务功能都有关系，这个数字仅供参考。
像声网服务的那些头部泛娱乐 App，其实很多都在用这些优化手段。毕竟他们的用户量非常大，包体积每减少 1MB，下载转化率就能提升好几个百分点，这个账是算得过来的。
写在最后
说了这么多，其实核心思想就一个：不要被动接受 SDK 给你多大就用多大，要主动去了解它的构成，然后根据自己的需求去做减法。
声网作为国内音视频通信赛道市场份额领先的服务商，SDK 的架构设计本身就有比较良好的模块化基础，这是很多小厂产品做不到的。用好这些设计上的灵活性，配合合理的配置和持续监控，把包体积控制在一个理想的范围内，其实不是多难的事情。
如果你正在为 RTC SDK 的体积问题发愁，不妨先从最简单的按需引入和 ABI 分割开始试试，效果应该是立竿见影的。有什么具体的问题，也可以在声网的开发者社区里找找资料或者问问技术支撑，毕竟他们每天接触这么多客户，经验还是相当丰富的。
祝你优化顺利！
