阅读 3330

消息推送背后的思考

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

不可不说的前言

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

重新看推送需求

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

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

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

  • 推送的到达率(到没到)
  • 推送的实时性(什么时候到)
  • 推送的表现形式(以什么样的 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 )

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

总结

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

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

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

可能用户最不满意的还是前面提到的:该推的不推,不该推的瞎推

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

关注下面的标签,发现更多相似文章
评论