说Android端外推送比较烦，实际有两层意思：首先是说实现上比较麻烦，至今业界也没有找到一种完美的解决方案，Android程序员通常需要同时集成多家推送平台（如果有自己的端内推送，还要考虑与端内推送的配合）；其次是说Android推送的市场现状比较混乱，无论选择哪一家，都让人纠结万分，难免心情烦躁。无论是你花费了多少功夫，做了多少优化，仍然可能存在推送不到或推送延迟的情况。网上已经有很多关于Android推送的讨论，但很少有站在App开发者（特别是开发App的创业团队）的角度来进行介绍的文章。本文的目的，就是站在一个App开发团队的角度，集中讨论两方面的问题：
通常大厂的App都会区分端内推送和端外推送（端指的是客户端），具体说来：
当App在前台运行的时候，这时的推送称为端内推送。端内推送一般是走App自己实现的一套推送系统：推送服务器是自己的，客户端维护一条长连接连到自己的推送服务器，不依赖任何第三方的推送系统。
当App从前台退到后台，在短时间内App未被杀死前，App自己的长连接仍然有效。这时的推送可以仍然走App自己的推送系统。所谓的“Android进程保活”，就是为了尽量延长这段在后台存活的时间。
当App在后台运行足够长的时间后，App进程由于被清理或者其它原因，App自己的长连接断开。这时的推送就称为端外推送了，只能走某个第三方推送平台了。
从这个过程来看，大厂的App的推送策略可以概括为：优先使用自己的推送，实在不行再走第三方推送平台。为什么这样呢？因为自己的推送系统更快、更有保障：
更快，是因为你交给第三方推送平台的推送消息要跟很多其它家App的消息一起排队。如果某家App突然在短时间内发送大量推送消息给推送平台（推广活动，或者程序bug），那么这个推送平台上的其它App就有可能受到牵连，推送延迟变得很大。这样的情况是很可能会发生的。比如，在某个推送平台的技术交流群里，不定期地就会看到有人在喊：“是不是推送又堵了啊......”
更有保障。大厂通常有专门的队伍维护推送相关的服务，有问题可以快速推进优化。
我们虽然算不上大厂，但我们维护的微爱App也是有自己独立的端内推送的，而端外采用另外几家推送平台，后面我们再详细讲。
那为什么本文只讨论端外推送呢？因为讨论端内推送和讨论端外推送是完全不同的两个话题。讨论端外推送，我们主要是在讨论怎么对各家的推送平台进行选择，以及集成各家SDK的时候我们应该重点注意哪些问题。这通常是很多初创团队更需要的。
而讨论端内推送，主要应该讨论一个推送系统的具体实现，这是一个比较复杂的问题，并不是一篇文章就能讨论清楚的。在这里，我们只是浮光掠影地浏览一下这个话题可能涉及到的内容，但不做展开讨论：
采用什么协议？XMPP还是MQTT还是自定义二进制协议？是否像微信一样，需要推送二进制数据（比如短语音和缩略图数据）？
如何保证后台长连接不死？涉及到“保活”的问题。
如何做才能真正保证不丢数据？涉及到系统的方方面面，比如消息的确认，客户端和服务器的数据同步，客户端的数据存储的事务保证，后台消息队列如何设计保证不丢数据。如果是IM，离线数据如何处理？
长连接的Keep Alive和连接状态的检测与维护。比如XMPP相当于一个永远解析不完的XML流，使用一个空格作为Keep Alive消息。
长连接的安全性。验证以及加密。
综上，本文要讨论的重点是端外推送。
端外推送我们必须依赖第三方的推送平台了。
这个情况其实本来跟iOS上类似。在端内推送系统的长连接失效的时候，我们就只能通过其它的推送平台来完成。在iOS上我们只用使用APNs就行了。
而在Android上，跟APNS对应的服务是谷歌的GCM (Google Cloud Messaging)，但很可惜它在国内的可用性不高（主要原因是手机厂商对Android系统的定制化，可能会将GCM服务裁减掉，以及国内运营商的一些限制）。如果我们做的是一个海外的应用，那么端外推送基本只用考虑GCM就可以了。
那国内的Android推送平台有哪些可以选择呢？
根据我个人了解到的信息，我列出了下面这些（排名不分先后）：
上面提到的各推送平台大体可以分为三大类：
要对这些推送平台进行选择，我们首先要知道各类推送平台的优势分别是什么。
首先，对于手机厂商的推送，他们的推送服务在他们自己生产的手机上属于系统级别的服务，理论上来说，手机系统对他们自家的推送限制最小。
比如，在小米手机上，不在系统自启动名单里的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这家推送的时候，使用的是免费版服务。但是，我们用了一段时间之后，他们的销售找了过来。宣称他们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，在不同的推送平台上的叫法不太一样，比如在小米推送中被称为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%左右。
为什么说法如此迥异呢？是因为大家在说的其实不是一个送达率。
友盟的消息推送业务线负责人陈漠沙曾专门写过一篇文章，来澄清送达率概念的一些误解，文章写得相当好，建议做推送业务的同学一定要读一下：
关键是要分清此文中定义的“在线送达率”和“通用送达率”。
“在线送达率”，各个推送平台优化到最后，可能都差不多。估计都能达到98%以上。
而“通用送达率”才是真真正正把消息推送到你的App的最终的送达率，这个也才是用户最终能感受到的送达率。App开发者需要真正关注的也是这个。
“通用送达率”大概来讲，是最终到达App的消息数与开始发出的消息数的比率（在一定时间内监测）。跟这个比率直接有关的因素是两个：
所以，这么说起来，不同的App由于业务不同，推送调用方式也不同，那么他们的通用送达率就没有实质的可比性。
那假如我们推送做了某个优化，或者某天换了一个更好的第三方推送平台，我们怎么知道这个改动是好还是坏呢？答案是我们可以自己跟自己比。持续监测通用送达率，比较改动前后的变化。
GitHub上有一个讨论Android推送的帖子（由@Trinea创建）：
这个帖子从2015年5月份开始讨论至今，仍然没有人给出一个完美的解决方案。
随着各个手机厂商的市场份额的变化，以及推送平台市场的变化，Android推送也是一个不断处于变化中的话题。今天的结论，换到明天，也许就未必再适用。
所以，推送服务的实现者们也当然要拥抱变化。一定要确保你的推送架构能够很容易地切换某个第三方的推送渠道。
多年的创业经验告诉我们，不只是推送服务，也包括众多其它的云服务，仅仅依赖一家平台的做法，都是极其愚蠢的。
由于国内的各大手机厂商对于安卓系统做了各种不同的定制，增加了很多安全性的限制，导致推送成了一个很复杂的问题。而这个市场中又没有哪一家完美解决了所有手机设备的推送送达的问题。同时，微信由于其先发优势和规模优势，进入了各大厂商受保护的白名单，进一步拉开了与其他App在推送送达率上的距离。
最后不由得感慨一句，如果谷歌一直在中国，还会有这种乱局出现吗？
其它精选文章：
用树型模型管理App数字和红点提示
Redis内部数据结构详解(5)——quicklist
宇宙尽头的描述符（下）
程序员的宇宙时间线
女儿和她的图画书
小孩子的魔法
Redis内部数据结构详解(1)——dict
扫码或长按关注微信公众号：张铁蕾。
![]()
有时候写点技术干货，有时候写点有趣的文章。
这个公众号有点科幻。