Android 端外推送到底有多烦？

时间 2019-11-16

原文原文链接

说Android端外推送比较烦，实际有两层意思：首先是说实现上比较麻烦，至今业界也没有找到一种完美的解决方案，Android程序员一般须要同时集成多家推送平台（若是有本身的端内推送，还要考虑与端内推送的配合）；其次是说Android推送的市场现状比较混乱，不管选择哪一家，都让人纠结万分，不免心情烦躁。不管是你花费了多少功夫，作了多少优化，仍然可能存在推送不到或推送延迟的状况。html

网上已经有不少关于Android推送的讨论，但不多有站在App开发者（特别是开发App的创业团队）的角度来进行介绍的文章。本文的目的，就是站在一个App开发团队的角度，集中讨论两方面的问题：android

如何对各家的推送平台进行技术选型；
在集成各家推送平台的SDK的时候，应该重点关注哪些问题。

为何本文只讨论端外推送？

一般大厂的App都会区分端内推送和端外推送（端指的是客户端），具体说来：git

当App在前台运行的时候，这时的推送称为端内推送。端内推送通常是走App本身实现的一套推送系统：推送服务器是本身的，客户端维护一条长链接连到本身的推送服务器，不依赖任何第三方的推送系统。
当App从前台退到后台，在短期内App未被杀死前，App本身的长链接仍然有效。这时的推送能够仍然走App本身的推送系统。所谓的“Android进程保活”，就是为了尽可能延长这段在后台存活的时间。
当App在后台运行足够长的时间后，App进程因为被清理或者其它缘由，App本身的长链接断开。这时的推送就称为端外推送了，只能走某个第三方推送平台了。

从这个过程来看，大厂的App的推送策略能够归纳为：优先使用本身的推送，实在不行再走第三方推送平台。为何这样呢？由于本身的推送系统更快、更有保障：程序员

更快，是由于你交给第三方推送平台的推送消息要跟不少其它家App的消息一块儿排队。若是某家App忽然在短期内发送大量推送消息给推送平台（推广活动，或者程序bug），那么这个推送平台上的其它App就有可能受到牵连，推送延迟变得很大。这样的状况是极可能会发生的。好比，在某个推送平台的技术交流群里，不按期地就会看到有人在喊：“是否是推送又堵了啊......”
更有保障。大厂一般有专门的队伍维护推送相关的服务，有问题能够快速推动优化。

咱们虽然算不上大厂，但咱们维护的微爱App也是有本身独立的端内推送的，而端外采用另外几家推送平台，后面咱们再详细讲。github

那为何本文只讨论端外推送呢？由于讨论端内推送和讨论端外推送是彻底不一样的两个话题。讨论端外推送，咱们主要是在讨论怎么对各家的推送平台进行选择，以及集成各家SDK的时候咱们应该重点注意哪些问题。这一般是不少初创团队更须要的。编程

而讨论端内推送，主要应该讨论一个推送系统的具体实现，这是一个比较复杂的问题，并非一篇文章就能讨论清楚的。在这里，咱们只是浮光掠影地浏览一下这个话题可能涉及到的内容，但不作展开讨论：安全

采用什么协议？XMPP仍是MQTT仍是自定义二进制协议？是否像微信同样，须要推送二进制数据（好比短语音和缩略图数据）？
如何保证后台长链接不死？涉及到“保活”的问题。
如何作才能真正保证不丢数据？涉及到系统的方方面面，好比消息的确认，客户端和服务器的数据同步，客户端的数据存储的事务保证，后台消息队列如何设计保证不丢数据。若是是IM，离线数据如何处理？
长链接的Keep Alive和链接状态的检测与维护。好比XMPP至关于一个永远解析不完的XML流，使用一个空格做为Keep Alive消息。
长链接的安全性。验证以及加密。

综上，本文要讨论的重点是端外推送。服务器

有哪些推送平台能够选择？

端外推送咱们必须依赖第三方的推送平台了。微信

这个状况其实原本跟iOS上相似。在端内推送系统的长链接失效的时候，咱们就只能经过其它的推送平台来完成。在iOS上咱们只用使用APNs就好了。网络

而在Android上，跟APNS对应的服务是谷歌的GCM (Google Cloud Messaging)，但很惋惜它在国内的可用性不高（主要缘由是手机厂商对Android系统的定制化，可能会将GCM服务裁减掉，以及国内运营商的一些限制）。若是咱们作的是一个海外的应用，那么端外推送基本只用考虑GCM就能够了。

那国内的Android推送平台有哪些能够选择呢？

根据我我的了解到的信息，我列出了下面这些（排名不分前后）：

小米推送（MiPush）
华为推送（华为Push）
友盟推送（U-Push）
个推
极光推送
阿里云移动推送（Alibaba Cloud Channel Service）
腾讯信鸽推送
百度云推送

咱们选的是哪家推送？选择标准是什么？

上面提到的各推送平台大致能够分为三大类：

大手机厂商的推送：小米推送、华为推送。
专业的第三方推送：友盟推送、个推、极光推送
BAT大厂的平台推送：阿里云移动推送、腾讯信鸽推送、百度云推送。

要对这些推送平台进行选择，咱们首先要知道各种推送平台的优点分别是什么。

首先，对于手机厂商的推送，他们的推送服务在他们本身生产的手机上属于系统级别的服务，理论上来讲，手机系统对他们自家的推送限制最小。

好比，在小米手机上，不在系统自启动名单里的App，在手机重启后，App声明的后台Service并不会自动运行。可是，小米推送做为手机系统级服务，仍然是能够收到推送的。

一样，华为推送的技术团队也对外宣称（原话）：

华为Push，在华为手机上是系统级别的服务，稳定性等各方面确定都会好些。

可是，即便是系统级别的推送服务，也不是百分百保证消息送达。这里比较奇葩的是华为推送，下面是他们技术支持给出的描述（原话）：

华为手机上：
Emui3.0上，Push广播有很大几率被限制，如： Mate7 3.0版本，荣耀6plus，P7 3.0版本，4X， 4A等。
Emui3.1上，Push广播基本不被限制，但个别型号机型存在问题，如：荣耀5x等。
Emui4.0及以上，Push广播有较高几率被限制，不被限制的机型如：荣耀畅玩4C，荣耀畅玩4X，Mate S，P8 MAX等。
如广播被限制，须要将应用设为开机启动项。因此对于及时性或到达率要求很是高的应用，咱们建议应用要考虑替代方案。
后续Push版本，华为将采用新的设计方案，解决被限制的问题，但发布计划待定。

另外，至于限制的问题，其实华为sdk仍是能接收到推送消息的，当将消息经过广播发送给应用是，若是手机管家查到该应用处于stop状态，那么会拦截该广播的。

看完以后的感受：还真他妈复杂！

总之，华为手机上的推送，华为推送本身也不太彻底能搞得定的。可是，咱们考虑再三，彷佛也没有更好的选择了。

再说第二类：专业的第三方推送。他们的优点看什么呢？看他们“保活”和“互拉”的能力。举个例子，假设你接入了友盟，而刚好今日头条也接入了友盟。有一天你的App被杀死了，可是今日头条的装机量估计比你的要大啊，这时用户启动了今日头条，那么推送系统也就会经过共享的推送通道顺便把你推送消息送达到手机上，而后还可能把你的进程也唤醒（被“保活”了）。

这么说来，选第三方推送平台，这个推送平台的规模效应就很重要了。那如何得知他们的规模和市场份额呢？最好的办法是问内部的朋友。不然，其实也没什么好的办法，每家确定对外都说本身最好啊。有一个不太精准的方法，就是看他们的合做客户里有哪些大的app，到他们官网上的合做案例里去看。这个信息总不能乱写把。

而对于BAT大厂的推送呢？看起来并无什么优点。各家的“全家桶”采用的“保活”阵营和推送通道，跟他们开放出来的是两码事。好比，你不要觉得用了腾讯信鸽推送，就能占上微信的光。

这里须要单独提一下的是阿里云的移动推送。在他们官网上提到，手机淘宝就是用了阿里云的这个推送。不过仔细研究一下会发现，手机淘宝也在同时使用其它的第三方推送平台啊（好比友盟推送）。两个平台到底谁借谁的力更多呢？不得而知啊。

综合上面的分析，咱们在微爱的Android客户端里使用的推送方案基本以下所述：

端内使用微爱本身的推送；
端外在小米手机上使用小米推送；
端外在华为手机上使用华为推送；
端外在其它手机上统一使用一种推送，也就是上面推送平台列表中的某一个。具体是哪一个就不说了，本文中咱们称它为X-Push吧。

注意：小米推送在非小米手机上固然也能工做，只不过就不是系统级别的服务了，受的限制就多一点。同理，华为手机也同样。咱们之因此这样选择，是为了让不一样的推送运行在各自擅长的环境里。

基本的架构图以下：

原本呢，对于推送平台的选择问题，到这里就应该结束了。可是，最近发生了一件事，让咱们以为被X-Push这家坑了一把，这让咱们忽然意识到了一个选择陷阱。如今把它分享出来，好让你们选择的时候必定要擦亮眼睛。

事情大体通过是这样的：咱们开始集成X-Push这家推送的时候，使用的是免费版服务。可是，咱们用了一段时间以后，他们的销售找了过来。宣称他们SDK里的“看护功能”，是付费功能，若是不付费，技术那边就会经过一些操做关闭这一功能。这里他们提到的“看护功能”，大概就是本文前面提到的“保活”和“互拉”的能力。

这个事情的关键点在于什么呢？

咱们一直以来都认为对于这类第三方推送平台，“看护功能”是他们最基础的一个功能。咱们在整个接入开发的过程当中，没有从任何来源获得关于“看护功能”要单独收费的说明。他们官网上的公开价格表压根没有提到这个功能，接入的技术支持QQ群里也没有任何人提到过，官方的开发文档更是无处说起。
咱们在整个接入和测试的过程当中，以及后来上线以后运行的这段时期内，这个“看护功能”都是一直包含在SDK内的。等用了一段时间以后，却忽然被告知这一基础功能要收费，实在让人措手不及。
若是明码标价，咱们在最开始选型的时候就会把这一因素考虑进去。可是该平台却在开始的时候故意隐藏可能存在的收费陷阱。
对方称若是被关闭了“看护功能”，那么“消息触达效果”会有明显地下降。咱们也能理解“免费+收费”的商业模式，可是一般来说，这种模式是对于基础功能免费，而对于高级功能收费，不多见到以下降服务质量做为免费条件的。

若是把这件事的所有细节写出来，恐怕还须要额外的5000字。因为本文的主要目的仍是分享技术选型的经验，因此这里点到为止，能把事情的大体通过说清楚就行了。等这件事尘埃落定之后，咱们也许还有机会再从新拿出来说一讲这个故事。

可是，这里你要记住的是，在你选择一家推送平台以前，必定要找人问清楚对方收费的模式，有没有隐性的消费陷阱。记住：没有人主动会告诉你哟。

你们也别问这家X-Push究竟是哪家了，你们本身去体会。这里能起到提醒的做用就够了。

你是否须要本身的端内推送？

对于小的创业团队来讲，本身实现端内的长链接推送系统，成本仍是不小的。

其实呢，各个第三方推送平台也是能够在端内使用的。并且，他们通常也对iOS的APNs推送也有封装。因此，在资源紧缺的状况下，小团队在初期也能够选择某家第三方推送平台作本身所有的推送服务，能快速地同时支持Android和iOS两个平台推送。等后边人手充裕了，再考虑进行优化，或加入新的推送渠道。

具体怎样选择，还在于你本身权衡。

使用通知栏消息仍是透传消息？

一般第三方推送平台都支持两种推送消息类型：通知栏消息和透传消息。

通知栏消息，在被送达用户的设备后，直接以系统通知的形式展现给用户。它不会继续被传递到App。

而透传消息，在被送达用户的设备后，还会继续路由到App，经过回调App的某个BroadcastReceiver的形式将消息传递到App内部。而后由App决定如何处理和显示这个消息。

这两类消息在送达率的保证上有所不一样，固然在提供的编程能力上也很是不一样。

透传消息在整个消息传递过程当中比通知栏消息多了一步，所以就增长一些被系统限制的几率。因此说，通知栏消息比透传消息应该能提供更好的送达率。

好比，小米推送的文档中就这样描述：

在一些 Android 系统(如 MIUI)中,受到系统自启动管理设置的限制,应用不能在后台自启动。在这类系统中,若是在发送消息的时候对应的应用没有被启动,透传类消息将不能顺利送达。所以,对于对送达率要求很高的消息,建议尽可能采用通知栏提醒的方式推送消息

若是App有本身的端内推送系统，那么这种通知栏推送消息就更合适一些。当端内推送的长链接失效时，咱们经过通知栏消息把提醒展现给用户，由用户唤起咱们的App，而后真正的消息数据再经由端内推送达到客户端。

实际上，咱们就是采用通知栏消息这种推送方式的。

而透传消息，提供了对消息数据的更灵活的操纵能力。App若是仅仅经过通知栏消息，是没法接触到消息数据自己的。

因此，若是App没有本身的端内推送系统，而是采用第三方推送做为端内推送通道，那么就只能使用透传消息。

另一个例子，若是App想自定义通知提醒的样式，以及提示声音，恐怕也只能经过透传消息来本身实现。通知栏消息一般提供不了那么灵活的配置。

这里有一点须要说明的是，当透传消息送达设备后，若是在试图路由到App内部的时候，发现App进程不在，那么理想状况下它应该“拉起”App进程。因此，照此推测，若是前面提到的那家X-Push关闭了“看护功能”的话，那么透传消息会受到多大的影响呢？结果可想而知。另外，X-Push那家的销售说了，关闭“看护功能”，对通知栏消息的“消息触达效果”也是有影响的。无语......

推送的初始化和推送token的同步

咱们使用第三方推送平台，最关键的地方在于前两个步骤：

在恰当的时机把推送SDK初始化起来。
初始化以后App会异步地收到一个推送token，那么接下来须要把这个推送token同步到App服务器。

这里的推送token，在不一样的推送平台上的叫法不太同样，好比在小米推送中被称为reg id，在华为推送中被称为token，在个推中被称为cid，在友盟推送被称为Device Token。总之，它是推送平台对设备的惟一标识。咱们这里统称它为“推送token”是为了方便讨论。

App的客户端拿到它以后，必需要同步到本身的服务器，并与本身的用户ID创建起对应关系。这样当咱们想推送消息给咱们的某个用户的时候，咱们才能查到对应的推送token。

前面说的初始化和推送token同步这两个步骤，看起来很简单，只是调用SDK的现成接口，再把它发送给服务器而已。可是，好的代码不只能在正常状况下工做，还应该充分考虑失败状况。有什么样的失败状况须要咱们考虑呢？咱们以小米推送为例来分析一下：

小米推送要求在Application对象的onCreate中执行初始化操做。咱们能够猜想一下，在这个初始化操做中小米推送的SDK可能须要在本地为咱们修改配置，还可能须要联系小米推送的服务器来申请reg id（即推送token）。这个初始化过程是可能失败的，本地操做可能会受到系统的限制，网络更是可能出错。试想，若是初始化出错了，咱们还会收到推送token吗？
假设咱们成功收到了推送token（一般在一个BroadcastReceiver中），接下来把推送token发送到咱们本身的服务器，这个工做须要咱们本身来完成了。咱们都知道在移动环境下网络极可能是弱网环境，此次同步若是失败了，那么下次要等到什么机会才能再次进行同步呢？

上述第一种初始化错误，理应由推送SDK来处理。若是失败，它应该会有重试机制，直到成功获取了推送token，它再从新调用App把推送token传过来。好比，小米推送平台也是这么宣称的，初始化可能出现的错误，App开发者不用考虑。若是你充分信任推送平台，那么这个错误实际上是能够不用去考虑的；不然，你能够在App里增长某些机会来检测初始化是否已经成功（能够经过检测是否已经拿到推送token来肯定），而后在恰当的时机从新调用初始化代码。固然，在作这个事情以前，你最好与推送平台沟通清楚，确保重复调用初始化代码不会产生什么反作用。

上述第二种错误，就必须靠App开发者本身处理了。这里咱们实际上须要在App客户端和服务器之间抽象出一条强的通讯通道，咱们把同步推送token的请求放进去，这条通讯通道可以在失败发生的时候自动重试。

这里的代码写得是否是足够健壮（robust），不一样level的程序员就高下立判了。

咱们能够说，恰当而全面地处理失败状况才能真正体现工程师的意义，这也是工程和理论研究的不一样点之一。

推送的送达率到底跟什么有关？

推送作得好很差，以及咱们选择推送平台选的好很差，关键在于送达率高不高。送达率这个概念，一直是个很混乱的概念，有些平台会宣称送达率能达到98%以上，而又有一些人说行业平均水平也就60%左右。

为何说法如此迥异呢？是由于你们在说的其实不是一个送达率。

友盟的消息推送业务线负责人陈漠沙曾专门写过一篇文章，来澄清送达率概念的一些误解，文章写得至关好，建议作推送业务的同窗必定要读一下：

blog.umeng.com/%E5%B7%A5%E…

关键是要分清此文中定义的“在线送达率”和“通用送达率”。

“在线送达率”，各个推送平台优化到最后，可能都差很少。估计都能达到98%以上。

而“通用送达率”才是真真正正把消息推送到你的App的最终的送达率，这个也才是用户最终能感觉到的送达率。App开发者须要真正关注的也是这个。

“通用送达率”大概来说，是最终到达App的消息数与开始发出的消息数的比率（在必定时间内监测）。跟这个比率直接有关的因素是两个：

业务类型。好比你的App是个IM，那么可能通用送达率会比较高，由于IM来的消息比较重要，且须要接收的人尽快去阅读处理。而若是你的App只是来推送一些系统消息，那么不少人可能压根不会打开你的App去看，这样通用送达率天然就低。
推送的调用方式。这个和开发有关。好比，你的推送逻辑总给已经卸载了App的用户发送消息，那么对方确定收不到了，形成通用送达率比较低。这种状况在群发的时候尤为显著。

因此，这么提及来，不一样的App因为业务不一样，推送调用方式也不一样，那么他们的通用送达率就没有实质的可比性。

那假如咱们推送作了某个优化，或者某天换了一个更好的第三方推送平台，咱们怎么知道这个改动是好仍是坏呢？答案是咱们能够本身跟本身比。持续监测通用送达率，比较改动先后的变化。

拥抱变化

GitHub上有一个讨论Android推送的帖子（由@Trinea建立）：

github.com/android-cn/…

这个帖子从2015年5月份开始讨论至今，仍然没有人给出一个完美的解决方案。

随着各个手机厂商的市场份额的变化，以及推送平台市场的变化，Android推送也是一个不断处于变化中的话题。今天的结论，换到明天，也许就未必再适用。

因此，推送服务的实现者们也固然要拥抱变化。必定要确保你的推送架构可以很容易地切换某个第三方的推送渠道。

多年的创业经验告诉咱们，不仅是推送服务，也包括众多其它的云服务，仅仅依赖一家平台的作法，都是极其愚蠢的。

因为国内的各大手机厂商对于安卓系统作了各类不一样的定制，增长了不少安全性的限制，致使推送成了一个很复杂的问题。而这个市场中又没有哪一家完美解决了全部手机设备的推送送达的问题。同时，微信因为其先发优点和规模优点，进入了各大厂商受保护的白名单，进一步拉开了与其余App在推送送达率上的距离。

最后不禁得感慨一句，若是谷歌一直在中国，还会有这种乱局出现吗？

（完）

其它精选文章：