先说原理。
iOS 的推送：就是 Apple 官方的 APNs （Apple Push Notification service）。
Android 的推送：Google 官方的是 GCM (Google Cloud Messaging）。
本质上，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 没有本质的区别，但有一定的技术门槛。而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现。
其实，国外如 Urban Airship 自己实现了 Android 上的第三方提供的推送平台。近期国内如极光推送也实现了第三方的推送平台（技术与微信、GCM、APNs类似）。理论上，如果一个 Android 设备上多款应用都使用极光推送这种第三方推送平台的话，也可以如 APNs 一样达到节省电量、流量消耗的效果。
