Android 与 iOS 系统的消息推送机制
相信大家在使用 iPhone 版微信的时候都会有这样的经历，微信已经处于关闭状态了（后台进程运行一段时间就被系统杀掉），这时候我们收到了一个消息提醒，打开微信应用，微信显示“连接中…”和“收取中…”，然后再次显示一次刚才系统推送给我的消息通知。对这个现象比较好奇，于是去知乎上查一下资料，发现知乎上的热心人还真多，看了大家的回答之后，总结如下： [之所以去知乎查看技术问题，因为我并非技术人员，而知乎上很多开发人员是会用通俗易懂的方式解释好技术问题的，因为里面有不少大牛。] 先介绍一下两个重要的消息推送服务： iOS 的推送：Apple 官方的 APNs （Apple Push Notification service）。 Android 的推送：Google 官方的 GCM (Google Cloud Messaging）。 其实两个推送服务的机制是比较接近的，以苹果为例，用一个图示表示如下： 采用 APNs 或者 GCM 进行消息推送，消息都会经由苹果或者谷歌的服务器，然后再到用户设备上，这样做的好处主要有以下几点： 1）省电 这个是最直观的体验。由于这两套推送机制都是用户设备和苹果或谷歌的服务器保持一个长连接，而这个长连接是几乎不会耗损多少电量的，采用统一的连接来接收手机上所有应用的通知消息，耗电量少是显而易见的。 由于苹果采用封闭的策略，因此所有第三方应用都必须采取这种推送方式，因此 iPhone 设备即使电池电量比 Android 少也更耐用。但由于国内众所周知的原因，Google 服务的稳定性大受考验，而且 Google 对第三方应用推行 GCM 方式并不是强制性的，因此国内的应用开发者几乎都单独在后台常驻一个进程，来专门处理消息推送。 2）开发简单 这个是对应用开发者来说的，一般不使用上述的 APNs 或者 GCM 推送机制，就需要自己搭建一条推送服务，可以采用别人开发的成熟协议，或者自己单独开发（如腾讯），这对于开发者来说还是有门槛的。 3）利于统一管理 采用统一的方式来处理就使得系统可以更高效，不会出现多应用同时处理消息卡顿的情况。 当然坏处的话，一个就是稳定性和实效性依赖于苹果或者谷歌的消息服务器，当然这种机制目前正常情况下都能做到 5s 以内的延迟。如果是第三方应用单独放置一个常驻进程...