江苏龙网

  1. 首页 > 人文 > >

如何设计一款稳定、好用、安全的推送SDK？


一款稳定、易用、安全、小巧灵活的推送SDK是怎么样的？本文将从“小”、“稳”、“好用”以及“安全”四个角度来具体阐述 。
如何设计一款稳定、好用、安全的推送SDK？
本文插图
对于非技术出身的产品经理来说 ， 如果突然接到一个要“设计SDK”的活儿 ， 其实并不容易 。 毕竟 ， SDK是主要面向开发者的 ， 更像一个toD产品 。 那么 ， 产品经理在设计SDK时 ， 需要注意哪些点呢？换句话说 ， 一款好的SDK应该具备哪些特性？本文将从“小”、“稳”、“好用”以及“安全”四个角度来具体阐述 。
1. 小
1.1 65535限制
我们以一款好的推送SDK为例 ， 那么首要需考虑到SDK包体的小巧灵活性 。
为什么选择更小体积的包体？
对于商务人员来说 ， 包体体积小 ， 他们更容易接受 。 对于技术人员来说 ， 他们在开发产品时 ， 普遍追求“代码少、功能全” ， 这是来自程序员的代码洁癖 。
那么从代码层面来看 ， 是因为系统有“65535限制” 。
如何设计一款稳定、好用、安全的推送SDK？
本文插图
如上图（左）所示 ， 程序最终会生成dex文件 ， dex文件主要由以下几部分组成：header（标头）、一连串的ids（标识符列表）、data（数据区）以及link_data（静态链接文件中使用的数据） 。
细看上图(右） ， 它包含了一个method_ids_size字段 ， 该字段的主要作用是定义个数 。 根据谷歌的定义 ， uint是一个16位的short类型 ， 最长长度是65535 。 如果将dex工程反编译 ， 会生成很多smali的文件 ， 再去看smali里的函数调用（比如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 ， 极简化封装 ， 承载最大的信息量 ， 减少流量和电量浪费 。


推荐阅读


上一篇：速卖通速卖通俄罗斯与虚拟影响者阿里奥娜·波尔开始出售虚拟服装

下一篇：音频怪物你的下一款耳机，会为索尼充值信仰，还是选个百元随便玩玩？