一款不变、易用、安详、小巧机动的推送SDK是怎么样的？本文将从“小”、“稳”、“好用”以及“安详”四个角度来详细叙述。

对付非技能身世的产物司理来说，假如溘然接到一个要“设计SDK”的活儿，其实并不容易。究竟，SDK是主要面向开拓者的，更像一个toD产物。那么，产物司理在设计SDK时，需要留意哪些点呢？换句话说，一款好的SDK应该具备哪些特性？本文将从“小”、“稳”、“好用”以及“安详”四个角度来详细叙述。

1. 小 1.1 65535限制

我们以一款好的推送SDK为例，那么首要需思量到SDK包体的小巧机动性。

为什么选择更小体积的包体？

对付商务人员来说，包体体积小，他们更容易接管。对付技能人员来说，他们在开拓产物时，普遍追求“代码少、成果全”，这是来自措施员的代码洁癖。

那么从代码层面来看，是因为系统有“65535限制”。

如上图（左）所示，措施最终会生成dex文件，dex文件主要由以下几部门构成：header（标头）、陆续串的ids（标识符列表）、data（数据区）以及link_data（静态链接文件中利用的数据）。

细看上图(右），它包括了一个method_ids_size字段，该字段的主要浸染是界说个数。按照谷歌的界说，uint是一个16位的short范例，最长长度是65535。假如将dex工程反编译，会生成许多 *** ali的文件，再去看 *** ali里的函数挪用（好比invoke direct {***} 函数名@BBB），会发明挪用的地点其实就是适才unit里界说的偏移量计较得出的。因此，这个函数地点最多也只能有65535个。

1.2 如何使包体体积变小

如何减小包体的体积，发起从以下几个方面思量：

（1）自研，不嵌套

在设计研发SDK时，不发起在SDK内嵌套一系列框架，譬喻三方 *** 框架、db框架或任务调治框架等。我们主张选择最焦点的一部门举办自主研发。

（2）代码优化

从算法层面，在结果沟通的环境下，可适当淘汰代码的行数；对付有默认赋值的变量不需要举办初始化赋值；选择符合的字符串拼接 *** ，发起利用StringBuilder要领拼接字符串，可以办理字符串频繁修改带来的内存耗损，也有利于淘汰包体体积巨细。

（3）追求实用，放弃完美

SDK包体该当追求实用性，以完善主成果为主，其他相对次要的部门可以适当淘汰时间或精神投入，放弃完美主义思维。

（4）代码夹杂

借助代码夹杂实现更小体积的包体，且不易被逆向。

1.3 省电省流量

省电省流量是“小”的另一个方面。SDK假如没有对流量和电量有严格的限制，不然会呈现手机发烫、高耗电提醒、流量挥霍、内置SDK APP难以上架等问题。

针对上述问题，我们可以配置通过Lock杀手，智能心跳、自界说协议、链路归并、按需活泼等 *** 尽大概地低落SDK对电量以及流量造成的耗损。

（1）Lock杀手：代码中WiFiLock、WakeLock等会强制叫醒APP，导致APP发生较大耗电量。在不影响成果的前提下，我们应只管淘汰可能不消该类锁。

（2）智能心跳：应按照差异的运营商、 *** 状态等,选择差异的心跳计策，而且按照差异的应用场景摸索心跳的更大界线，只管耽误心跳周期，淘汰电量和 *** 的耗损。

（3）自界说协议：市场上常用的json、xml、甚至PB协议，都有较量好的兼容扩展性，但同样也带来了空间挥霍的问题，自界说协议可以充实操作空间，准确操作每一个byte甚至bit，极简化封装，承载更大的信息量，淘汰流量和电量挥霍。

（4）链路归并：当一个设备有多个APP的推送链路同时活泼时，我们会运用归并链路技能，将利用同一款SDK的 APP 之间的长毗连链路举办归并，淘汰流量电量的挥霍。

2. 稳 2.1 晋升不变性

在设计SDK时，还要思量到SDK的利用不变性。不然在实际应用中，大概会碰着ANR、OOM、Crash、内存泄露、闪退等棘手的问题，我们需要通过一连的迭代和优化来将错误最小化。

（1）做好代码打点

除了借助SVN、GIT等东西做好代码托管外，还需遵循必然的代码类型，借助雷同gerrit等东西举办代码review，利用verify流程。在担保呆板找不到问题的前提下，再用人眼去分辨是否切合业务逻辑。

（2）自动化测试

自动化测试可以大幅晋升回归测试的效率，很是适合火速的开拓进程。另外，自动化测试可以替代大量的手工机器反复性操纵，测试工程师可以把更多的时间花在更全面的用例设计和新成果测试上。

（3）运用代码模块化等小能力