iOS和Android的后台推送工作原理各是如何？

iOS的推送： 就是Apple官方的APNs（ApplePushNotificationservice）。 Android的推送： Google官方的是GCM(GoogleCloudMessaging）。

本质上，APNs与GCM是类似的技术实现原理：即系统层有一个常驻的TCP长连接，一直保持的长连接，即使手机休眠的时候也在保持的长连接。这里对于大部分人来说，最不理解的就是，休眠时候都保持在那里的TCP长连接，不会耗电很厉害么？

答案是：不会。这是手机的设计来做到的。TCP长连接有个心跳的时间，在国外可以很长比如30分钟，在国内则因为网络环境复杂一般10分钟。客户端发起的心跳，会短暂地消耗手机电能，但在这个心跳间隔期间，则消耗电能是很少的。当在心跳期间服务器端有推送信息过来时，客户端可以收到并做处理。
这里有篇文章以Android为例做原理解释：http://blog.jpush.cn/index.php/jpush_wireless_push_principle/...

再说APNs的设计成功处
iOS为了真正地为用户体验负责，不允许应用在后台活动。有了这个限制，但是对于终端设备，应用又是有必要"通知"到达用户的，随时与用户主动沟通起来的（典型的如聊天应用）。

这就是APNs的逻辑所在：iOS自己做个长驻后台保持连接。所有应用，有必要（申请）并且被允许（用户可以改设置）的话，可以通过APNs中转到达用户。这样就完善了！

有可能很多人没有真正地体会到iOS不允许后台应用的好处。我是Android开发人员，Android手机上一般只保留几个常用的应用，不常用就卸载。但是我的iPhone/iPad上则是，除非空间不足，一般不会删除应用。

Android就像Windows，你要真的很费心去维护：有软件在干背后干坏事么？设备又给拖慢了，要清理。要考虑杀毒了......

Android因为后台可以长驻，尤其是国内的Android的手机上Google自家的推送服务GCM处于基本不可用的状态。所以，各App各显神通。聊天类应用的话，大多数直接借用XMPP规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与APNs/GCM没有本质的区别，但有一定的技术门槛。而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现。

其实，国外如UrbanAirship自己实现了Android上的第三方提供的推送平台。近期国内如极光推送也实现了第三方的推送平台（技术与微信、GCM、APNs类似）。理论上，如果一个Android设备上多款应用都使用极光推送这种第三方推送平台的话，也可以如APNs一样达到节省电量、流量消耗的效果。

------------方家文，Oldcodingman