android推送技术方案与原理
原文链接 http://blog.isming.me/2014/08/01/android-push/
注:以下为加速网络访问所做的原文缓存,经过重新格式化,可能存在格式方面的问题,或偶有遗漏信息,请以原文为准。
推送服务现在广泛的使用,几乎成了每个app的必备,现在呢,苹果上面有APNs,android上面游GCM(中国不可用)。我也是经常使用第三方的推送,比如百度云推送,个推等等。但是一直想知道推送的原理,想着自己也能做出来,到网上搜到一些推送的方案(大段内容来自网上)。
方案一:使用GCM服务(Google Cloud Messaging)
简介:Google在Android上标配了自己的推送GCM(Google Cloud Messageing),可以帮助开发人员给他们的Android应用程序发送数据。它是一个轻量级的消息,告诉Android应用程序有新的数据要获取从服务器,或者它可能是一个消息,其中包含了4KB的payload data(像即时通讯这类应用程序可以直接使用该payload消息)。GCM服务处理排队的消息,并把消息传递到目标设备上运行的Android应用程序。 <!--more--> 优点:Google提供的服务、原生、简单,无需实现和部署服务端。
缺点:
1.GCM要求Android系统必须是2.2以上的版本,所以对于不少2.2以前的系统没法推送
2.国内服务不稳定。而且不少国内的终端厂商纷纷把Google的服务去掉,替换上自己的。
3.需要用户绑定Google账号,但不少国内用户没有Google账号。
方案二:使用XMPP协议(Openfire + Spark + Smack)
简介:XMPP是一种基于XML的协议,它继承了在XML环境中灵活的发展性,有很强的可扩展性。包括上面讲的GCM服务器底层也是采用XMPP协议封装的。
优点:协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中,且已有开源的Java版的开发实例androidpn。
缺点:协议较复杂、冗余(基于XML)、费流量、费电,部署硬件成本高。
而androidpn(Android Push Notification)就是基于 XMPP 开源组件的一套整合方案,服务端基于Openfire、客户端基于Smack。到AndroidPN项目主页( http://sourceforge.net/projects/androidpn/ ) 下载2个文件: androidpn-server-0.5.0-bin.zip 和 androidpn-client-0.5.0.zip 分别是服务器和客户端的代码。详细的实现方式网上有不少文章。
androidpn有如下一些不足,开发的时候需要权衡:
1、androidpn服务端重启后客户端不会重连,这个非常悲剧
2、由于服务器不保存消息,造成了如果客户端当前离线就收不到消息。
3、androidpn发送完消息就不管了,所以没有消息回执报表之类,造成没法做应用后续的数据分析用户体验的改善,这对于企业级的应用是个致命伤。
XMPP协议比较费电费流量,这个对当前智能机的消耗太大,在窄带网络和不稳定的(手机)网络都不是最优的选择。但总体来说,XMPP协议还是比较成熟的。
方案三:使用MQTT协议(更多信息见: http://mqtt.org/)
简介:轻量级的、基于代理的“发布/订阅”模式的消息传输协议。
优点:协议简洁、小巧、可扩展性强、省流量、省电,目前已经应用到企业领域(参考: http://mqtt.org/software),且已有C++版的服务端组件rsmb。
缺点:不够成熟、实现较复杂、服务端组件rsmb不开源,部署硬件成本较高。
方案四:使用HTTP轮循方式
简介:定时向HTTP服务端接口(Web Service API)获取最新消息。
优点:实现简单、可控性强,部署硬件成本低。
缺点:实时性差。
方案五:采用第三方服务
目前有不少第三方提供了类似服务,客户端只需要嵌入第三方提供的lib库,由第三方建立长连接,负责消息的接收/发送。同时对于消息都有比较详细的报表数据,可以用于做数据分析挖掘和用户体验的改善。目前国内提供推送服务的有好几家,比较成熟的主要有百度云推送, 极光推送, 个推服务。
本文只是罗列现有的方案,文章内容大段来自网上,我希望有一天可以做出一个demo。