苹果推送的原理
- app 向APNS发请求获取 device-token（是由APNs颁发的）
- APP 向Client 服务器注册当前用户的device-token（说明用户与device-token 映射关系）
- client 服务器向 APNS服务器发消息（device-token + Payload）.
- APNS 根据 device-token 将消息传递给手机，手机在根据bundle ID 传递给对应app.
苹果推送的过程
此图描述了真实消息推送的过程
App开发者或者第三方推送平台的服务器(图例中的Provider)向APNs发起推送指令的请求，推送指令包含了要下发设备的device-token和要下发的内容payload两部分。
由APNs根据device-token(device-token是APNs生成颁发的)将payload下发到设备上，再由设备路由给具体的App。
APNs要求Provider首先与APNs建立一条长连接，Provider通过长连接可以将单个或者一批device-token发送给APNs，这个过程中，只要有一个device-token是不合法的(错误或者失效)，那么APNs就会主动断掉Provider到APNs的长连接.
Provider探测到连接断掉之后，需要重新建立连接，跳过上次失败的device-token，从下一个device-token接着发送。这个过程循环往复，直至将本次要发送的所有的device-token都推送到APNs，那么这次推送任务就算完成了。
剩下的工作就是APNs将消息下发到具体设备了，APNs将消息下发给设备这个过程，不管是App开发者直接和APNs打交道、亦或是第三方推送服务器和APNs打交道，我们都是无法控制的了.
为什么隔了很久之后再去做推送，发送过程会变得非常慢
- 因为长时间不发送的话，会有很多设备上的device-token已经无效了，比如:设备卸载了App，或者系统版本升级过导致device-token变化了，或者是其它导致APNs认为device-token不合法的原因。总之，时间长了，不合法的device-token就会变多。
- 那么既然失效的device-token是导致发送变慢的主要原因，那么开发者朋友们肯定会想，能不能提前判断出失效的device-token，直接从发送列表中剔除掉这些失效的token。
- 其实APNs是提供这样的feedback接口的，调用这个接口会得到一批失效的device-token列表。那么是不是在一次发送之前去调用一下这个接口，获取到无效的device-token，在发送的过程中剔除掉这些无效的device-token就能加快发送速度呢？
- 其实不然，因为feedback接口是一个后验的接口，即只有一次推送任务结束之后，APNs才会把该次失效的device-token更新到feedback接口的返回结果里面。
- 如果你在一次推送任务前调用feedback接口，那么得到的失效device-token是基于上一次推送任务的结果的，两次推送任务之间发生的失效的device-token，是无法提前获取到的，只能等当次推送任务结束之后，才可以去获取新的失效token列表。
原文参考品：https://www.zhihu.com/question/33888020/answer/59658011
iOS和Android后台实时消息推送的原理和区别
iOS的实时消息推送
iOS 系统的推送（APNS）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器。
你的例子里面，腾讯 QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。
- Android的实时消息推送
而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。
Android实时消息推送
