个推消息推送SDK技术沉淀（1）：如何使SDK包体体积变小？如何实现省电省流量？

1 为什么追求包体体积小

好的消息推送SDK首要需考虑到包体的小巧灵活性。为什么选择更小体积的包体？对于商务人员来说，包体体积小，他们更容易接受。对于技术人员来说，他们在开发产品时，普遍追求“代码少、功能全”，这是来自程序员的代码洁癖。而从代码层面来看，主要是由于系统的“65535限制”。

如上图（左）所示，我们的程序最终会生成dex文件，dex文件主要由以下几部分组成：header（标头）、一连串的ids（标识符列表）、data（数据区）以及link_data（静态链接文件中使用的数据）。细看上图(右），它包含了一个method_ids_size字段，该字段的主要作用是定义个数。根据谷歌的定义，uint是一个16位的short类型，最长长度是65535。如果将dex工程反编译，会生成很多smali的文件，再去看smali里的函数调用（比如invoke direct {***} 函数名@BBB），会发现调用的地址其实就是刚才unit里定义的偏移量计算得出的。因此，这个函数地址最多也只能有65535个。当然，谷歌给了我们一个巧妙的方式绕过该限制，就是通过分包，方式也简单，在AS的配置中加上multidex选项即可。

 

2 如何使包体体积变小

如何减小包体的体积，可以从以下几个方面考虑：

（1）自研，不嵌套：在研发SDK时，不建议开发者在SDK内嵌套一系列框架，例如三方网络框架、db框架或任务调度框架等。我们主张开发者选择最核心的一部分进行自主研发。

（2）代码优化：从算法层面，在效果相同的情况下，可适当减少代码的行数；对于有默认赋值的变量不需要进行初始化赋值；选择合适的字符串拼接方式，建议使用StringBuilder方法拼接字符串，可以解决字符串频繁修改带来的内存消耗，也有利于减少包体体积大小。

（3）追求实用，放弃完美：SDK包体应当追求实用性，以完善主功能为主，其他相对次要的部分可以适当减少时间或精力投入，放弃完美主义思维。

（4）代码混淆：借助代码混淆实现更小体积的包体，且不易被逆向。

 

3 省电省流量

省电省流量是“小”的另一个方面。作为一款好的推送SDK，应该对流量和电量有严格的限制，否则会出现手机发烫、高耗电提醒、流量浪费、内置SDK APP难以上架等问题。针对上述问题，我们可以通过Lock杀手，智能心跳、自定义协议、链路合并、按需活跃等方式尽可能地降低SDK对电量以及流量造成的消耗。

（1）Lock杀手：代码中WiFiLock、WakeLock等会强制唤醒APP，导致APP产生较大耗电量。在不影响功能的前提下，我们应尽量减少或者不用该类锁。

（2）智能心跳：应根据不同的运营商、网络状态等,选择不同的心跳策略，并且根据不同的应用场景探索心跳的最大边界，尽量延长心跳周期，减少电量和网络的消耗。

（3）自定义协议：市场上常用的json、xml、甚至PB协议，都有比较好的兼容扩展性，但同样也带来了空间浪费的问题，自定义协议可以充分利用空间，精确利用每一个byte甚至bit，极简化封装，承载最大的信息量，减少流量和电量浪费。

（4）链路合并：当一个设备有多个APP的推送链路同时活跃时，我们会运用合并链路技术，将使用“个推 SDK”的 APP 之间的长连接链路进行合并，减少流量电量的浪费。

 

作者：个推高级研发总监 公瑾