消息推送背后的思考

本文为原创，如需转载请标明出处，侵权必究。

不可不说的前言

去年笔者写了一篇 《安卓推送这件小事》 ，如今回过头来再看，很多地方已有些过期，趁着春节，从新思考和整理下推送这件事，这篇文章的目标受众不只是对客户端推送实践感兴趣的工程师，还包括对推送的用户体验现状不满的用户。

从新看推送需求

推送分推送需求和推送技术，推送技术由工程师实现，推送需求来自用户，这里的用户包括以下几个角色：

• 产品经理用户
• 工程师用户
• 普通用户

不一样角色对推送的需求不一样，或者说对推送的度量的容忍度不一样。主要有如下度量维度：

• 推送的到达率（到没到）
• 推送的实时性（何时到）
• 推送的表现形式（以什么样的 ui 展现）
• 推送的后台耗电（后台是用户无感知，可是系统很敏感）
• 推送内容（该推的不推，不应推的瞎推）

而咱们最该关心的是普通用户的需求，即推送的到达率和推送内容。若是不理清上面的需求分析，即便推送技术实现得再好，也没法在实际场景得到成功。做为工程师不能埋头作技术，任何一项业务背后都有它的核心需求。

以上说明了作推送这个需求时的考虑问题的优先级，在不断的迭代过程当中，仍是须要把各方面都作到尽善尽美的。

管好你的业务伙伴

在人力成本受限的状况下，客户端实现推送不可凭一己之力，整个推送的实现过程与其说是开发，不如说是项目管理。咱们来看看推送须要和哪些业务伙伴打交道：

• Android 的官方推送 FCM
• 第三方的推送实现（包括手机厂商自带推送和第三方推送）
• 手机厂商的后台策略（如电池优化）
• Android 自身的后台策略
• 第三方 app 的后台策略（如绿色守护的后台纯净模式）
• 手机对通知的 ui 支持状况
• Google Play 的隐私策略

那么笔者是如何来看这个问题的呢，首先须要进行一次项目管理的需求转换，上面几个业务伙伴的分类不便管理，须要作一次从新分类，具体以下：

• 推送实现（ FCM、手机自带推送、第三方推送、后台纯净）
• 后台策略（何时启动、何时中止，到了后台只有当前使用的推送在干活，其余都要干掉）
• 通知形式（主要指透传消息的展现形式，分为系统默认和自定义）
• 隐私策略（隐私不注重，直接给你下架）

上面分类后是否是逻辑清楚了不少呢，可是还不够，咱们只是进行了功能上的划分，在时序上还要想明白：

• 后台策略贯穿整个 app 的生命周期
• 推送和通知的依赖关系，老是先收到推送，而后才有通知

需求抽象到这里，那么实现也就水到渠成了。

抽象后的推送实现

如今不少工程师 UML 图都懒得画，虽然 UML 不等于架构能力，可是确实是提高抽象和架构能力的一个很好的工具。

图中的每个方法是对推送概念的一个抽象。

值得注意的细节

别忽视这些细节，关键时候可能会让你的整个推送用起来不爽。

细节一：引入 sdk 的注意事项

在这里提到的 sdk 是推送实现的 aar 或者 jar 。

• 尽可能不要依赖 aar ，而是依赖 jar 和本身搞定资源文件。
• 有些 sdk 分 Google Play 和国内版，打包的时候经过条件判断引入不一样的 sdk 。
• 关注 sdk 的方法数和大小，有些版本会忽然就大了好几倍。
• 关注 sdk 的升级日志，若是是修复空指针或者提升稳定性啥的，记得必定要升。

细节二：杀不掉的推送进程

咱们的推送平台策略是服务端下发的，会根据下发的 vendor 来决定开启指定平台的推送，关闭其余平台的推送。但以前常常有用户经过系统工具看到后台跑了两个推送进程，这是怎么回事呢？原来，推送实现为了知足不被杀掉的需求，会尽量地让本身的推送进程活着，即便手动调用了 sdk 的 stop 方法也没用。

这个时候只能上大杀器了，咱们在 stop 方法以后延时几百毫秒调用 Process.killProcess() 方法。

细节三：发挥不稳定的 FCM

你们知道 FCM 推送是要知足必定条件的，而且即便知足条件，也不必定能够收到推送，那么就须要对条件的判断有一个策略，这个策略还在迭代，等到稳定后再讲。

解决技术问题，也不要忘记解决人的问题

任何涉及到业务伙伴的事情，若是只关心技术文档或者代码，可能会事倍功半，由于代码是人写的，既然你引入了别人写的 sdk ，那么就要去创建一条沟通路径，包括以下方式：

• 跟踪 github 上该项目，保持和主要开发者的沟通
• 创建和国内第三方 sdk 的售前或者技术支持人员的沟通路径（最好是微信或 qq ）

相信我，当你真的发生问题的时候，直接联系相关人员，远比本身调试代码来得容易。

总结

说到这里，是否是理解了笔者以前说的，推送这件事，本质是项目管理而不只仅是开发呢，其实其余事情也同样，明白了根源在哪里，解决问题的思路就会很不一样，不会纠结于具体的技术细节，而是先确保大方向的正确性。

上面这些我全作到了，但用户仍然不满意

上面这些只是不断迭代实践得来的经验，推送这件事任重而道远，去年如火如荼的**“安卓统一推送联盟”**，正是为了解决这一问题而来，但因为历史缘由和各方利益的博弈，到最终解决问题仍是有很多路要走。

可能用户最不满意的仍是前面提到的：该推的不推，不应推的瞎推。

这也是笔者写这篇文章的目的之一，经过背后的这些思考告诉用户，不是看不见大家的不满，咱们在努力让推送这件事变得美好，而大家如今立刻能够作的，就是去本身关注的主题下，明确本身的推送需求，把不须要的所有关掉就好，其余事情由咱们来解决。