Android客户端消息推送原理简介

首先简单介绍一下Android消息推送的主要三种方式，如果你已经看过类似的文章，请直接忽略三种介绍。
1.使用SMS服务，即服务器端发送短信，然后手机客户端监听短信的广播，然后对数据进行一定的处理，达到消息推送的目的。好处就是省电，省流量，但是运营商会很费钱。毕竟发送短信都是需要金钱支持的，并且会有环境的限制。平板、或者用户停机的情况下，就没有办法使用推送了。所以这种解决方案，仅仅是在某些及其特殊的情况下(移动、联通、电信这种公司)才会使用。
2.使用轮询的方式来从网络中主动获取数据。费电、费流量。这种方式方便理解，实现也较为简单（我们的近乎客户端1.0就是这么实现推送的）。如果只是做个Demo的情况下还是可以使用。但是作为正在运行的应用，不论你怎么优化，一般是会比较耗费流量的，毕竟一直在获取网络中的数据。
3.使用长连接的方式，一般来说，推送的主要数据，都是依赖于这种方式进行数据推送的。省流量、费电。简单介绍一下原理，原理就是跟服务器端建立一条长时间的数据流连接，手机客户端一直在等待手机客户端中的数据。因为连接是持续的，并且没有数据流操作，所以网络中的流量还是相对较为节省的。但是因为一直保持网络中的连接，所以这种消息推送，肯定是比较费电的。很多软件就是这样制作的。像苹果、Android推荐使用的C2DM都是使用的这种模式（苹果处理的比较好的地方，是整个手机只是用一个连接，原本Android也想使用这种模式，无奈Google的服务器在美国，介于天朝防火墙的问题，这种推送会不稳定）。但是这种模式下也会有一定的缺陷，在网络不稳定的情况下（火车、公交车、开车都会造成网络不稳定），Socket比较容易断开。连接不稳定的情况下。推送数据容易失败。还是有不少推送的组件都是基于这种模式做的。
然后简单介绍一下，近乎客户端的消息推送的规划。在近乎客户端中，应用到推送的功能模块并不是很多，有私信、通知、请求、即时聊天功能（正在规划中）。其中私信、通知、请求属于非即时性需求，简单的延迟个几分钟关系也不是很大（比如说，你的同学在站点中AT了你，你在五分钟之后才对他的这个动作处理，也没有什么太大的问题），即时聊天属于即时性功能（想想一下，你的老婆跟你说,想你了，你过了二十分钟之后才回一句，……）。这两种是完全不同的两种需求。本次我们只介绍前面那种。

分别介绍一下手机客户端和服务器端要进行的处理，请一边看图一边理解。
手机客户端要先询问服务器是否允许Socket连接，不允许处理很简单，直接使用轮询的方式获取数据。如果服务器端允许连接，那么就尝试连接，并且检测 Socket是否可用。如果长时间网络不稳定，则侧向与轮询，并且检测网络环境是否稳定。等到网络稳定的时候再使用Socket进行数据推送。
服务器端，首先检测是否启用了Socket，如果启用了。就等待手机连接客户端，等到客户端连接之后将数据推送给手机。
这样数据就可以较为正常的推送给手机客户端了。