一、传统APP架构下的信息传送
APP主动向服务器请求数据，服务器被动的提供数据。
步骤如下：
然而，如果此时服务器又有了新的新闻，在用户没有主动刷新的情况下，服务器是不会主动推送给用户的。
推送解决了这个困境，它让服务器主动连接APP，通知APP有了新的新闻，可以再请求。收到推送的APP（即使已关闭）又去服务器请求最新的新闻，用户就能看到了。
二、实现推送的方法
实现一个推送系统需要服务器端和终端的配合。
方法一：轮询
即不停地向服务器发送请求（既然不知道什么时候会发生，那就一遍一遍的问吧）。
缺点：手机消耗电量、流量大；服务器也要处理大量的请求，压力大。
方法二：APP和服务器建立长时间连接通道
通过这个通道，APP可以向服务器请求数据，服务器也可以向APP发送数据。
android系统中，如果APP被关闭，APP可以启动一个后台服务来维持通道继续运行。（ios的解决方法见下）
如何维护这个长时间连接的通道？
APP会每隔段时间向服务器报告自己还活着，服务器收到后，即可知道这个通道可以继续使用。（代价是增加电量消耗）
如果手机中装了多个带有推送功能的APP，如何解决多个通道的问题？
android解决方案：GCM（系统提供）、开发各自的专用通道（国内方法）
Android系统提供的 GCM 只能在 Android2.2 以上才能使用，3.0 以下必须要安装 Googleplay 并登陆了 Google 账号才能支持。而国内发行的手机大多是阉割掉了 google 服务的。
因此，对于 Android 系统来说，各家 app 只能开发自己的专用长连接通道了。然而这时候他们遇到了 app 的天敌：管家和卫士们。前文说了，app 想要及时收到服务器推送的消息，关键在于自己与服务器的长连接通道不被关闭，也就是自己的后台服务可以一直在后台运行，而管家和卫士们的一键清理功能就是专治这种 “毒瘤” 的。道高一尺魔高一丈，app 在与管家和斗士们的长期斗争中，总结了一系列躲避被清理掉的方法，什么定时自启能力、什么相互唤醒、什么前台进程等等。
IOS解决方案：APNS
ios开通了一条系统级别的长连接通道，通道的一端是手机的所有APP，另一端是苹果的服务器。
APP的服务器如果有消息需要推送，先把消息发送到苹果服务器上，再利用苹果的服务器通过长连接通道发送到用户手机，最后通知具体的APP。这样，即使安装了100款APP，也只需要向一条通道里发送推送。
非原创，总结自微信文章。
