一、什么是app消息推送？

所谓信息推送，是通过推送技术自动传送信息给用户，它根据用户的兴趣、偏好等定期推给用户，从而帮助产品运营人员更高效地实现运营目标，维持APP留存率。

目前的app消息推送可以在用户在移动设备处于锁屏状态或在通知栏收到应用的消息推送push，点击push去往相应页面。

消息推送分为自己开发和第三方工具，前者开发成本过高，所以大部分公司采用了第三方推送工具。目前市场上主流的第三方推送工具有腾讯信鸽、百度云推送、个推、极光推送、华为云推送。

各平台有个平台的优劣，有需要的可以自行选择。

二、app消息推送有什么优势？

1、提高产品活跃度和用户粘性。

app的消息推送是在用户点击推送消息后直接进入app对应页面，这种方式是除从移动端桌面应用图标进入app的另一种方法。运营人员为了提高产品活跃度和用户粘性可以设计消息推送，引导用户打开app激活使用。

当用户下载app后，可能只有在刚下载完时打开看一下，然后边待在手机内存里面，面临“吃灰”或者“待卸载”，这种状态被称为“休眠状态”，而恰当的推送则可以唤起这部分“休眠”的用户。推送的消息需要充分展现自己app能给这部分用户带来的价值。切记不要推送一些不痛不痒的信息通知。

3、介绍产品新功能和宣传新活动。

版本迭代后，产品推出新功能，而用户没发现或者休眠用户不知道，则需要通过消息推送告知用户，解决了用户主动发掘欲望低的痛点，提升用户体验。运营人员需要完成一个新活动的KPI，则需要通过消息推送告知用户新活动的内容，引起用户打开app查看活动的兴趣。

app消息推送有什么缺点？

1、对用户造成骚扰，提高卸载率。

如果一款产品没有特别吸引你的地方，或者你是一款产品的休眠用户，当你频繁接受到一些消息推送或者推送的消息并不能吸引用户时，大多数用户会选择卸载。为了避免这种悲剧的发生，合理选择好推送时间和推送内容。

三、app消息推送分类

1、IM类（即使通讯类）

谈到消息推送，首先想到的就是信息通知，也就是如微信、ＱＱ之类的即时通讯app，对于这类app来说，信息的推送并不是为了提高产品活跃度或者提高用户留存率，更主要的是信息推送是这类app的必要条件。如果没有这些功能，那么就不能保证消息能及时传递，失去了及时通讯的意义。

２、非IM类（新闻资讯类、活动推送类、产品推荐类、系统功能类）

①新闻资讯类：包括新闻客户端、资讯类app，目前市场上主流的今日头条、腾讯新闻等。

②活动推送类：这类主要是为了提高用户参与到一些营销活动中，如前文提到的宣传产品的活动。

③产品推荐类：通常情况下是相关联或者相辅的产品会有一些推送信息，部分产品依靠大数据研究用户行为后会向该部分用户推送信息。

④系统通知类：基本上是产品本身精准化的推送，做到了与用户在产品上发生的行为保持了一致性，比如用户使用支付宝支付了一笔订单，随后将会收到消息推送告知用户刚才发生了一笔交易。这类app替代了部分使用短信提醒功能的开发商，降低了短信推送的成本，也使用户的反感度降到了最低，反而有时候会提升用户对于该产品的信任和好感。

四、IM类APP消息推送方式

作为即时通讯，即时两个字显得尤为重要。但是IM在移动端和PC端上的使用也有一定的逻辑事项。

1、锁屏状态时消息内容是否隐藏。

考虑到用户的隐私，很多IM软件可以设置锁屏状态是否显示消息内容，例如微信和QQ就可以设置。这与非IM类的消息推送不同，非IM类的消息不能隐藏。

2、PC端和移动端同时在线时的消息推送逻辑

大部分人最早接触到的应该是QQ的推送机制了。当PC端和移动端都同时在线时，QQ则会优先推送PC端，如果PC端的QQ处于锁定状态时，则会推送的移动端。另外一种情况是，如果PC端收到消息但出于不活跃状态，则会优先推送到PC端，过一段时间再推送到移动端。微信是同样原理，不过可以设置PC端和移动端同时接受消息。

3、当同一IM推送不同类型消息时的推送逻辑

有时候QQ会收到一条消息推送，但打开后发现并不是聊天信息，而是新闻推送或者是QQ空间的特别关心的动态提醒，这难免会减少用户体验，对用户造成骚扰。国外的Slack可以支持用户消息设置优先级，减少对不相关信息对用户造成的骚扰。

五、非IM类产品消息推送的生命周期

消息的推送也是有一个推送、打开、转化、卸载的生命周期。

提高消息推送打开率的方式要把握两点，一点是推送消息的内容，另一点是掌握推送消息的时机。

①从内容上来讲，推送的内容应该遵循一个营销理论——AIDMA模型。该法则指出，消费者从接触到营销信息，到发生购买行为之间，大致要经历五个心理阶段：引起注意(Attention)，产生兴趣(Interest)，培养欲望(Desire)，形成记忆(Memory)，购买行动(Action)。

首先要让用户对你推送的消息产生兴趣，吸引用户的眼球，用户才会有欲望打开，从而提高转化率。让用户产生兴趣的方式有以下几种：

强营销类：直接把营销模式直接向用户展现出来，把握用户贪小便宜心理、好气心理，引导用户打开。

强关联性：有没有发现有时候QQ或者微信上的聊天框出现“＠”时有强烈的打开欲望，所以在推送消息内容时可以加上“＠”、“你”等字样。

用户产生兴趣和产生欲望基本是在同一秒中实现的，所以在内容上可以适当的加上对用户的赞美，让用户自己和这条信息产生强的相关性，减少排斥心理。

强热点性：对于新闻资讯类，热点话题从来都是最吸引用户眼球的。

强话题性：强烈的话题冲击，一般都会击中用户内心的某个感触，比如对社会的愤世嫉俗，对高房价的逆反心理，对旅游的文艺心等等。

最后，根据具体情况选择推送，但需要注意推送的形式，资讯app就不要推送理财文章，视频app就不要推送音频的内容。还有尽量每次能保持差不多的标题字数和内容字数，使用户形成视觉上的记忆。除此之外还可以在推送的声音上让用户立刻就能分辨出你的app，比如易道用车的push消息的声音就不是系统默认的叮咚，聚财猫理财的push是一声“喵”，所以在听到push消息声音的时候，就可以辨别出是哪个app。内容结尾部分也可以加上“点我揭晓”、“→”、“>>”这样的引导性文字&符号，引导用户进行点击操作，提高Action的转化率。

②从时机上来讲，不同的产品有不同用户人群自然也有不同的push时间，人一天的闲暇时间一般为上班路上及早餐时间（9-10点）、午休（12-14点）、下班路上（6-7点）、睡前（21-22点）四个时机。但不同的产品有不同的场景，比如新闻类app应该在新闻发生后根据时效性推送，像天气类app应该在用户早上出门前推送。

③push推送也应该做a/b测试，即抽取一部分用户推送，然后根据用户的打开率、屏蔽率、卸载率等，根据用户属性精确化的推送，为以后的推送做好准备。

④从用户属性或者用户生命周期管理来讲，可以根据当前活动的内容形式选取部分属性的用户推送，比如根据地域、年龄、性别等，比如只推送高消费人群就可以推送北上广等一线城市，根据大数据研究，发现某一属性人群转化率高，则可以对这部分人群做特别的push。

在用户生命周期管理中，可以根据用户不同阶段来push，比如当用户注册成功48小时没动作，便可以push一条消息，引导他使用app、对注册了未绑定手机号的可以push提示等，做到不同的自动化或者半自动化的消息push。

⑤push也分内容优先级，选取重要的内容push，主动发布push消息频次是一周3左右，在push上减少对用户骚扰，保持良好的用户体验，降低APP卸载率。

到达率=到达数量/发送数量，到达率低原因主要分两种，一种是技术通道的原因，第二种是用户主动关闭了消息推送，一方面在营销上你要审视自己是不是有太多骚扰用户端额行为，另外一方面在产品上可以通过一些技巧实现，比如简书上订阅某个用户后，就会出现这样的提示去打开push消息。

当用户打开push的相关链接页时，可以观察用户是看了一眼就退出软件了，还是在该页有所操作，通过push消息把用户吸引过来，提高了用户的打开率，随时要监测用户的转化率，比如一个营销类的活动push，用户进来了之后，用户直接退出了APP还是说在营销页面做了停留，然后转化成购买行为等等，整条链条数据监测好，看看哪个环节流失率最高，采取一定的产品策略和运营策略。

卸载率=该条推送1h后卸载人数/到达人数，降低卸载率首先得从用户场景出发，把握内容和时机，同时监测好推送数据，随时改变战略。

六、Push、短信、微信、E-mail推送组合协同以提高效率。

推送的话目前主要有push、短信、微信服务号推送三种形式，那么产品和运营在设计时候最好能够组合协同，提高工具的最大效率。短信成本是最高的，其余是免费的，设计到互联网金融的还是最好用短信，能够直接接触用户，触达率高，像功能介绍、活动营销等就用push、微信公众号和E-mail就行了。

七、当用户关闭消息提示时，可反复提示用户打开消息推送。

在请求获取推送权限之前要注意的是， 默认情况下，iOS会在用户启动新应用程序时向用户提供一系列系统提示。 这些提示包括APP需要访问用户的位置，联系人列表等等权限。当用户不知道该app是否有价值时，可能会选择关闭消息推送，此时我们可以在用户进行部分操作后提示用户是否打开消息推送，比如注册完成后或者一周以后用户打开时再次提示用户打开消息推送功能，这个时候我们的应用已经初步向用户证明了价值，相信可以使用户更容易接受推送通知的请求，如果有可能的话，可以通过应用内消息发送解释关于消息推送的信息，而不是通过的系统提示，这样的效果会更好。只不过现在国内许多的app都没有这个功能。

（部分资料、图片来源于网络侵者删）

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

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

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

为什么本文只讨论端外推送？

通常大厂的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推送平台有哪些可以选择呢？

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

• 华为推送（华为Push）

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

上面提到的各推送平台大体可以分为三大类：

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

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

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

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

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

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

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

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里的“看护功能”，是付费功能，如果不付费，技术那边就会通过一些操作关闭这一功能。这里他们提到的“看护功能”，大概就是本文前面提到的“保活”和“互拉”的能力。

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

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

如果把这件事的全部细节写出来，恐怕还需要额外的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%左右。

为什么说法如此迥异呢？是因为大家在说的其实不是一个送达率。

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

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

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

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

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

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

所以，这么说起来，不同的App由于业务不同，推送调用方式也不同，那么他们的通用送达率就没有实质的可比性。

那假如我们推送做了某个优化，或者某天换了一个更好的第三方推送平台，我们怎么知道这个改动是好还是坏呢？答案是我们可以自己跟自己比。持续监测通用送达率，比较改动前后的变化。

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

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

所以，推送服务的实现者们也当然要拥抱变化。一定要确保你的推送架构能够很容易地切换某个第三方的推送渠道。

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

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

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