消息推送背后的思考

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

不可不说的前言

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

重新看推送需求

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

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

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

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

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

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

管好你的业务伙伴

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

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

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

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

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

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

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

抽象后的推送实现

image

现在很多工程师 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 ）

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

总结

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

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

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

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

这也是笔者写这篇文章的目的之一，通过背后的这些思考告诉用户，不是看不见你们的不满，我们在努力让推送这件事变得美好，而你们现在马上可以做的，就是去自己关注的主题下，明确自己的推送需求，把不需要的全部关掉就好，其他事情由我们来解决。