开发小哥的困惑:为何要用第三方推送?
在《测试妹子的呐喊:为什么总是收不到推送?》这篇文章中,小树解决了测试妹子收不到推送的反馈后,小树对推送就异常感兴趣,把项目里面所有有关推送的代码都阅读了一遍。
但细心的小树发现这里面并没有请求苹果 APNS 接口的代码,只有一些类似于极光推送,友盟推送,腾讯信鸽等推送的注释。
带着这些疑惑,小树又找到了小黑,希望能再次得到大神的指导。
极光推送、友盟推送、腾讯信鸽这些其实都是第三方推送服务商,小黑说道。
诶,有了官方推送那为什么还要用第三方推送呢,小树困惑地问道。
你这个问题倒是问对了,但要清楚地解释这个问题,就必须跟你讲一讲推送的历史了。小黑补充说。
苹果的远见: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 设备却不行?
小树急的像热锅上的蚂蚁,但小黑却悠然自得地拿起旁边的咖啡喝了起来。
今天还有紧急需求要做,下次我再给你讲讲这个问题,你先回去想一想吧。小黑这次卖了个关子。
你所看到是推送系列文章中的一篇,更多关于推送的文章: