声网 rtc 的 SDK 包体积优化：我是怎么被这个"大块头"折磨惨的
说起 SDK 包体积这事儿，我就想起去年刚接手一个社交类 APP 项目的时候。客户指着隔壁竞品说："你看人家这个 App 才 30 多 MB，我们的怎么就 80 多 MB 了？"当时我心里那个憋屈啊——用的都是声网的 rtc sdk，凭什么差距这么大？
后来查了一圈才发现，问题根本不在声网身上，而是我们自己对 SDK 的集成方式太"粗放"了。这篇文章就想聊聊，我在优化声网 rtc sdk 包体积过程中踩过的坑、总结出的方法，以及最终看到的效果。希望能给正在被类似问题困扰的开发者们一点点参考。
先搞明白：SDK 体积到底由什么组成？
在动手优化之前，我觉得有必要先搞清楚声网 RTC SDK 的整体架构。声网的 RTC SDK 实际上是一个模块化的解决方案，它把不同的功能拆分成了不同的动态库和静态库，你要是全给塞进去，那体积小不了才怪。
我记得第一次用 Android Studio 的 Analyze APK 功能查看包体积的时候，整个人都傻了。光是一个 agorartc.so 文件就占了将近 20 MB，更别说还有其他什么音频处理模块、视频编解码模块、网络传输模块之类的。后来问了声网的技术支持才知道，他们家 SDK 其实支持按需加载，你不需要的功能完全可以不集成进去。
这里我给大家整理一下声网 RTC SDK 的主要组成部分：
| 模块名称 | 主要功能 | 体积影响 |
| 核心音视频引擎 | 基本的音视频采集、渲染和传输 | 较大 |
| 视频编解码器 | H.264、H.265、VP8/VP9 等编码支持 | 中等 |
| 音频处理模块 | 3A 算法、回声消除、噪声抑制 | 中等 |
| 网络传输模块 | 拥塞控制、码率自适应 | 较小 |
| 增值功能模块 | 美颜、虚拟背景、AI 降噪等 | 可选 |
搞清楚了这些，后面优化起来就有方向多了。
我的优化实践：从"大而全"到"按需取用"
第一步：砍掉用不到的功能模块
这大概是我做过的最立竿见影的优化了。当时我们那个社交 APP 其实只需要基础的视频通话功能，什么 AI 降噪、虚拟背景、美颜这些花里胡哨的功能一个都没用到。结果呢？这些模块的代码全被我稀里糊涂地集成进去了。
具体怎么操作呢？其实声网的 SDK 在集成文档里写得很清楚，他们在 Maven 仓库里提供了不同的 SDK 包，有精简版、标准版和增强版三种。我当时图省事，直接拉了增强版回来，结果装了一堆用不上的东西。
后来改成只集成标准版之后，包体积直接少了将近 8 MB。这里我要提醒一下，如果你的项目确实不需要那些高级功能，一定不要手滑集成增强版。很多人觉得功能越多越好，实际上用不上的功能都是浪费。
第二步：善用 ABI 分包，只保留需要的 CPU 架构
Android 设备的 CPU 架构分好几种，armeabi-v7a、arm64-v8a、x86、x86_64 之类的。声网的 SDK 也针对这些架构分别提供了不同的 so 库文件。
我之前犯的一个错误是，把所有架构的 so 文件全打包进去了。你知道这意味着什么吗？一个 arm64-v8a 的 so 库可能就比 armeabi-v7a 大 30% 左右，你要是把四个架构都打包进去，那体积蹭蹭往上涨。
后来我研究了一下我们产品的用户设备分布，发现 99% 以上的用户都是 arm 架构的设备，x86 架构的基本可以忽略不计。而且现在 64 位设备越来越多，32 位设备已经很少了。
所以我的做法是在 build.gradle 里做了 ABI 分包配置，只保留 arm64-v8a 和 armeabi-v7a 两个架构。这一下子又省了大概 6 MB 的体积。
配置方法其实很简单，就是加一行 ndk.abiFilters 的设置，大家有兴趣可以去翻声网的官方文档，里面写得很详细。
第三步：资源文件该删就删，别心疼
SDK 里一般会自带一些默认的配置文件、音频资源或者图标素材什么的。这些东西看似不大，但积少成多也很可观。
我记得声网的 SDK 里自带了几套默认的音频铃声，什么等待音、掉线提示音之类的，加起来也有几百 KB。我们产品有自己的音效体系，这些默认的完全可以删掉。
操作方法就是直接找到 SDK 里的资源文件夹，把不需要的文件删掉就行。不过要注意，删之前最好确认一下这些文件确实没有被代码引用，否则删了之后 APP 可能会崩溃。
第四步：开启 ProGuard 混淆，压缩代码体积
这一步其实属于老生常谈了，但确实有效。ProGuard 不仅能混淆代码，还能删除未被使用的类和方法，甚至可以把一些长的变量名、方法名压缩成短名字，从而减小体积。
我在配置 ProGuard 规则的时候，专门针对声网 SDK 加了几条保留规则，防止 SDK 的核心类被误删。声网的文档里也有现成的 ProGuard 规则模板，拿过来用就行。
开启混淆之后，我测了一下，整体体积又小了 2 MB 左右。虽然看起来不多，但蚊子腿也是肉啊。
第五步：考虑使用动态库加载
如果你对包体积的要求特别严苛，还可以考虑把声网的 SDK 做成动态加载的方式。也就是说，主 APK 里不直接包含 so 库文件，而是在用户首次使用某个功能的时候再从服务器下载。
这种方法的优点是可以把 SDK 体积从 APK 里"剥离"出来，缺点是实现起来稍微复杂一些，而且首次使用的时候需要下载额外的资源，可能会有一定的等待时间。
我当时评估了一下，觉得对于我们这种用户量还可以的产品来说，这招的投入产出比不太高，就没采用。不过如果是做海外市场、用户网络条件不太好的地区，这招倒是可以考虑一下。
优化效果：数字来说话
说了这么多方法，大家肯定想知道实际效果怎么样。我给大家列一下我优化前后的对比数据吧：
| 优化项 | 优化前 | 优化后 | 节省体积 |
| SDK 版本选择 | 增强版 | 标准版 | 约 8 MB |
| ABI 架构分包 | 全架构 | 仅 arm64-v8a + armeabi-v7a | 约 6 MB |
| 删除无用资源 | 默认资源全保留 | 仅保留必要资源 | 约 0.5 MB |
| 开启 ProGuard | 未混淆 | 开启混淆 | 约 2 MB |
| 总计 | 约 40 MB（仅 SDK 部分） | 约 23.5 MB（仅 SDK 部分） | 约 16.5 MB |
最后算下来，整个 APP 的安装包体积从 80 多 MB 降到了 50 多 MB，虽然跟竞品的 30 多 MB 比还有差距，但已经缩小了很多。更重要的是，我们的功能一个都没少，用户体验也没打折扣。
一些踩坑后的心得体会
搞完这一圈优化之后，我总结了几点经验教训，想跟大家分享分享。
第一点，集成 SDK 之前一定要仔细看文档。声网的文档其实写得挺详细的，各种配置选项、集成方式都有说明。我之前就是太懒了，看了个开头就照着示例代码直接复制粘贴，结果集成了一堆用不上的东西。
第二点，优化是个循序渐进的事情。不要想着一口气把所有优化手段全用上，那样很容易出问题。我的做法是先做影响小的改动，测试没问题之后再做影响大的改动。
第三点，数据驱动决策。在决定砍掉某个功能模块之前，最好先看一下这个功能的使用数据。如果 99% 的用户都不用，那果断砍掉；如果使用率还挺高，那就得掂量掂量了。
第四点，多跟官方技术支持沟通。声网的技术支持团队挺专业的，有些他们踩过的坑、做过的优化案例，直接问他们能省很多弯路。我现在有啥问题都会先去咨询一下他们的技术支持。
写在最后
回顾这段优化经历，我最大的感受是：SDK 包体积优化这件事，看起来简单，其实里面的门道还真不少。它不仅仅是个技术活，更是个需要耐心、细心的活。
当然话又说回来，包体积优化也不是无休止的事情。如果你已经做了该做的优化，体积还是降不到某个理想水平，那可能就得权衡一下了——是牺牲一些功能来换体积，还是接受现状、把钱花在别的地方（比如用户增长、体验优化）？
毕竟我们的最终目标不是做出一个体积最小的 APP，而是做出一个用户真正喜欢用的 APP。你说是不是这个理儿？
如果你在优化过程中遇到了什么难题，或者有什么其他的心得想交流，欢迎在评论区留言讨论，大家一起进步嘛。
