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