Android推送全家桶SDK设计与实践

背景

随着业务的发展壮大，push的到达率也是对日活不可忽略的因素，另外部门的产品线越来越多，push服务组件化可以提升各个产品线的开发效率。首先push服务组件化的目的是解耦业务和服务代码，便于无缝升级和扩展服务，于是会想到去做一个推送全家桶SDK，把各种小米、友盟、杭研等第三方推送等都放到碗里来。在设计阶段，网上虽然有一些类似push sdk的参考方案，但是真正应用到产品业务当中，却有很多设计上的不足，代码本身都是容易的，写这篇文章的目的是更多探讨如何系统性设计一个推送组件，以及如何真正满足业务发展实践。

方案

个人认为，推送组件对Android应用来说，不仅仅设计一套通用接口让推送服务跑起来那么简单。第三方推送平台的碎片化一定会带来很多问题，比如在调研时发现有以下主要问题

• 小米支持UserAccount和别名，友盟只支持别名；
• 小米UserAccount可在多点有效，友盟别名只是单点有效；
• 小米通知栏方式虽然强大，但是客户端无法对业务消息进行选择性关闭
• 杭研推送为了安全性，注册和绑定流程相对复杂，如何兼容到组件里来，并优化流程
• 如何实现推送到达和点击的统计
• 推送平台数据格式不同，客户端在不用if-else判断具体平台的情况下，如何做到数据兼容
• 推送平台往往有透传和通知栏模式，服务端切换推送方式对push sdk有何影响
• 服务端发一条私信和发一条广播，对push sdk来说有何区别
• 如何支持组播
• 是否去重
• 客户端如何协助优化服务端的推送服务

另外，push服务的模块化，不仅仅是集成第三方push种类，还有更细分的组合，对客户端来说，是让服务端在协议的约束下选择透传和通知栏，才能保证到达率的同时不会发生消息重复。

SDK实现

• 去重不属于协议的部分，sdk的职责要保证服务端多个渠道透传过来的数据不重复通知给接入app。具体去重的方式目前sdk支持3种：根据pushId去重，根据pushId加标题去重，自定义字段去重。sdk保存去重队列在非易失存储，另外也要设置一个合适的最大消息数存储上限，建议根据接入的第三方推送平台数目来设置。

• 对于消息回执，sdk需考虑可能网络失败，要有缓存和重传机制，支持批量上报，具体触发的时机可以是app启动的时候，也可以是进入某个页面。这块需用数据库来记录，对缓存消息设置一个过期时间。
• 之前各个产品杭研推送的绑定流程并不统一，sdk在做这块时优化了绑定流程。由于客户端需要从自家服务器上拉取绑定参数、签名、过期时间，消耗网络资源，启动时sdk判断参数未过期则不重复绑定。
• 另外，为了了解线上用户可能存在的各种问题，需接入日志组件来记录各种错误状态，这就涉及到不仅要监控推送数据接收，还要对每个推送注册和设置命令都进行监控。由于命令数据量不大，sdk将命令与推送数据放在同一个线程的消息队列里接收，并通知上层。