文章首发于【博客园-陈树义】，点击跳转到原文《官方老爹之痛：为什么苹果能收到推送，而安卓不行？》
还记得上次我们做过的试验么？
我们在 iOS 设备杀掉进程后能收到推送，而 Android 设备却不行。这个问题可困惑了小树很长时间，这天趁着工作清闲，又跑到小黑工位上请教了。
小黑喝了口茶便开始说，我们现在所有推送消息都是通过第三方推送推出去的。所以了解一下第三方推送是如何实现的非常重要。
当我们的 App 启动的时候，同时会启动我们App中附带的第三方厂商的推送服务，这时候 App 进程中就有一个 Socket 长连接一直与第三方厂商的推送服务器保持着。当我们有消息需要推送到用户设备上时，我们通过调用第三方厂商的推送接口，传入对应的别名就可以了。
小树听到别名感觉有点困惑，什么是别名啊？
其实别名就是第三方厂商用来标记唯一用户的一个标识。
当我们的 App 启动的时候，厂商要求 App 方在合适的时候将别名和该设别的 DeviceToken 这两个参数传给厂商，从而建立起绑定关系。
所以从本质上来说，第三方厂商最后还是通过 DeviceToken 去识别要推送到哪个设备的哪个 App 的。
而这个别名，一般情况下也是要能唯一标识一个用户。所以很多时候我们都用用户ID来作为别名，将其和 DeviceToken 绑定在一起。
小树听完之后 发觉可以画一个流程图来梳理一下整个流程了。
App启动 -> 启动第三方推送服务 -> 注册别名和DeviceToken -> 等待推送消息画得很不错，非常清晰地表达了第三方推送的流程，小黑说道。
而对于后台开发小哥来说，如果要发送一条推送给用户，只需要将别名和推送内容作为参数调用第三方厂商的接口即可。
但这貌似还没回答之前的问题呢，为什么 iOS 设备在 App 进程被杀掉时能收到推送，而 Android 设备却不行呢？
小伙子果然穷追不舍，我这不是还没讲完嘛，别着急啊。小黑淡定地说。
我们上面说的这种情况，只在 App 进程还未被杀掉时适用。但当我们的 App 进程被杀掉时，第三方服务厂商的进程也会跟着被清除。
此时，如果我们还是通过设备与第三方厂商建立的 Socket 长连接进行推送消息接收，显然是无法正常进行的。所以，安卓设备就无法收到推送了。
而 iOS 设备能够在 App 进程死亡之后还接收到推送，那是因为第三方厂商在检测到自己与 iOS 设备的连接断开后，自动调用苹果官方的 APNS 服务进行消息推送。
而 iOS 设备的官方推送服务只要设备开机，则是永远存在的。所以我们的 iOS 设备就能够做到即使 App 进程被杀掉也能收到推送。虽然这推送推送功能很有限，但是能送达用户总比没送达好吧。
而 Android 设备不能在 App 进程死亡后收到推送，那是因为其没有官方推送的支持。
但现在也有一些情况下能够实现 Android 设备在 App 还未开启的时候，也可以接收到推送。
小树一听到还有这么一招，急忙问到底是什么方式啊？
这功能能否实现，这就依赖于第三方厂商的服务是否强大了。
假设我们手机上有两个 App，分别是「珍爱网」和「知乎」，它们都使用同一个推送厂商的推送服务。
当我们把两个 App 都启动，这时候进程上就会有两个关于推送的服务进程，一个归属于「珍爱网」App，一个归属于「知乎」这个 App。
当我们把「珍爱网」App 杀掉之后，珍爱网 App 对应的推送进程也就完蛋了。但是这时候不是有 知乎 App 里这个推送么。有些厂商就是利用了这一点，通过某些技术手段，使用「知乎」App的推送服务去唤醒「珍爱网」App 的推送服务，从而使得 珍爱网 App 的用户也能收到推送。
原来这还能这么玩啊，果然是自己的服务就可以有无限的想象空间啊。小树感慨道。如果我也能实现自己的一个推送服务就好了，这样我们就不用依赖第三方厂商，能够做更多定制化服务了。
自建推送服务虽然看似美好，但是开发成本和维护成本却是非常高的。如果公司业务规模不大，还是使用第三方推送服务比较靠谱。
不过我们公司规模其实也不小了，有将近上亿的用户，每天进行业务推送的量级也达到了百万级别。公司前阵子组织了开发团队里的开发精英，埋头干了2个月，终于搞出一个能用的推送服务了。
小树听到异常欣喜，觉得又有东西可以学习了。
不过今天还是不说那么多了吧，怕你学太多吸收不了。有机会我们下次来讲讲如何从零开始去设计一个推送系统，再如何一步步将其实现。
