开发小哥的困惑：为何要用第三方推送？

在《测试妹子的呐喊：为什么总是收不到推送？》这篇文章中，小树解决了测试妹子收不到推送的反馈后，小树对推送就异常感兴趣，把项目里面所有有关推送的代码都阅读了一遍。

但细心的小树发现这里面并没有请求苹果 APNS 接口的代码，只有一些类似于极光推送，友盟推送，腾讯信鸽等推送的注释。

带着这些疑惑，小树又找到了小黑，希望能再次得到大神的指导。

极光推送、友盟推送、腾讯信鸽这些其实都是第三方推送服务商，小黑说道。

诶，有了官方推送那为什么还要用第三方推送呢，小树困惑地问道。

你这个问题倒是问对了，但要清楚地解释这个问题，就必须跟你讲一讲推送的历史了。小黑补充说。

其实互联网崛起也就在 2010 年左右，在这之前是没有推送这个概念的。而在互联网时代，最常用的几大平台就是：iOS、Android、Windows Phone。

在 iOS 平台上，苹果有其官方推送平台 APNS（Apple Push Notification service），开发者可以直接使用该推送服务，但是提供的功能非常有限。

说起官方推送服务，苹果可以说是很有自己的远见的。在 iOS 系统一推出的时候就退出了 APNS 服务，所有推送给用户的通知必须要通过 APNS 服务才可以送达。

「不就是一个服务嘛，这么大的公司应该没啥问题吧」，小树不屑地说。

可能一般人觉得这没啥啊，不就一个服务嘛。但对于一个提供硬件厂商的公司来说，让其来做一个软件服务提供商，还是有些难度的，并且还是一个高并发量、海量用户的一个服务。如果服务发生了异常，那么这个锅可就是要苹果背的。

你看，安卓平台可就做出了不一样的选择了。安卓平台在一开始推出的时候并没有考虑到统一推送平台的问题，所以在安卓平台上是没有一个统一的推送解决方案的。虽然后面安卓平台也推出了自己的 GCM (Google Cloud Messaging）推送平台，但开发者都习惯使用了自己的第三方推送服务，想改也很难了。再之，因为 Google 服务长期在国内处于不可用状态，所以开发者也就懒得改了。

因为以上许多原因，你可以看到苹果和安卓系统在设计推送系统上的不同。这其实直接就导致了用户在使用时的体验。对于苹果系统来说，因为 iOS 对推送做了严格的规范，所以在 iOS 系统上的推送代码都比较规范，不敢造次。而在安卓平台上，因为没有了具体的规范，所以经常会出现弹窗通知一大堆的情况，过度打扰了用户。

除了用户体验问题，与推送相关的还有另一个手机电量的问题。因为 iOS 对推送服务做了统一，所以在 iOS 手机上一般情况下就只会有一个「官方推送服务」的系统服务一直运行。而对于 Android 平台来说，因为每个 App 提供商都有自己喜好的第三方服务提供商，所以经常会出现一个 Android 设备上运行着数十个推送服务。这毋庸置疑就直接导致了 Android 设备的耗电量急剧上升，而 iOS 设备则因为良好的规范设计避免了这个问题。

说了这么多东西，觉得懂了挺多东西的，但发现并没有解决一开始提出的问题。

那到底为什么要用第三方推送而不是用官方推送呢？小树继续问。

其实这个问题只问对了一半，并不完全正确。

因为 Android 平台上的官方推送服务经常处于不可用的状态。所以如果我们使用 Android 平台的官方推送的话，就会使得我们的推送服务非常不安全。因为这个原因，我们只能抛弃 Android 平台的官方服务。那现在只有两条路可以走，一个是自建推送服务，另一个是使用第三方推送服务。

前面说到自建推送服务的难度是很高的，不仅要求开发人员有丰富的开发经验，还要求其对网络编程方面的知识有深入的了解。此外，对于运维人员也有很高的要求，其必须保证服务能长时间零差错地运行。

这样的要求对于中小型公司来收，成本是非常高的。所以很多时候，许多公司会选择第三方推送服务，就像我们公司一样。

小树这下终于明白了使用第三方推送的原因了。虽然饶了许多弯子，但知其然才能知其所依然嘛。了解多一些历史背景和原因，才能更好地理解现在所使用的技术。

这就是许多公司为什么选择第三方推送的原因了。而因为 Android 使用了第三方推送，一般情况下都会要求 iOS 端也使用第三方推送，这是为了保持移动端实现的统一。你想一想，如果 Android 用第三方推送，而 iOS 端使用官方推送，那后台代码岂不是要写两次实现？

对！保持一定的规范性是非常必要的。小树兴奋地说道。

除了技术实现难度低、统一移动端的推送之外，第三方推送平台的有点之一是能实现更多复杂的功能。

对于 APNS 官方推送服务来说，它只允许我们推送一个系统通知，用户点击之后跳转到 App 里的某个页面。但第三方推送服务则可以实现更多复杂的操作，比如用户点击通知后直接播放。

所以我们使用第三方推送的原因就是：

• Android 官方推送的缺陷，我们只能使用第三方推送服务。
• 使用第三方推送实现难度低，可以节省成本。
• 使用第三方推送能实现更多的复杂功能。

你的总结能力可真不错啊，小黑竖起了大拇指。

但你还没解释为什么我那个问题只问对了一半呢。（为什么要用第三方推送而不是用官方推送呢？）

你不仅总结能力不差，记性还很厉害嘛。

在回答你这个问题之前，我先问题几个问题。

在 iOS 设备上，我们的 App 使用了第三方推送。我们把 App 进程杀掉后，给该用户发送一条推送消息，你猜该 iOS 设备能否收到？

小树摸摸脑袋想，我们使用第三方推送服务，那这个推送服务必然是跟随我们的 App 进程的。既然 App 进程都被杀掉了，那应该是接收不到推送的了。

就在小树思考的那几分钟，小黑打开了一个小项目，模拟了一次简单的推送。接着小黑运行了一个 JUnit 测试用例，向旁边的测试机发送了一条推送。过了没几秒手机就响起了「叮叮」的推送提示声。

小树这下子可是丈二和尚摸不着头脑，但是小黑却不急着回答小树的问题。继续问第二个问题。

在 Android 设备上，我们的 App 使用了第三方推送。我们把 App 进程杀掉后，给该用户发送一条推送消息，你猜该 Android 设备能否收到？

小黑还是用原先的方式发送了一条测试推送，这次旁边的 Android 测试机却一点动静都没有。

小树这下可真的完全不知道所以然了，为什么 iOS 设备杀掉进程后能收到推送，而 Android 设备却不行？

小树急的像热锅上的蚂蚁，但小黑却悠然自得地拿起旁边的咖啡喝了起来。

今天还有紧急需求要做，下次我再给你讲讲这个问题，你先回去想一想吧。小黑这次卖了个关子。