Android推送总结

来源:互联网 发布:linux 重启oracle监听 编辑:程序博客网 时间:2024/06/05 06:47

http://blog.csdn.net/baidu_26352053/article/details/54135107

  最近Android开发当中推送技术是热点。互联网上不同的博客关于推送的介绍也非常的多,大致上关于推送技术,我们可以有使用第三方平台和自己建立推送平台两种方案可行。

        第一种使用第三方推送平台,其中国内做的比较早,而且比较活跃的就是“极光推送”,在此期间也下载过其SDK,做过一些简单的推送Demo,其推送的效果还可以。在反编译其jar包之后,发现其底层的Socket通信层使用了JNI方式实现,这种方式可能是为了保护其关键代码的实现,也有可能是为了安全,但是使用这种方式的效率还有待研究。

        第二个第三方推送平台就是最近才推出的百度推送。因为百度推送的推出,当初还为之高兴一番,因为毕竟程序员有福了(博主不太看好小公司的产品,尤其是国内的小公司,一方面是技术层面,另外一方面是平台更新跟不上等等原因),自己的应用可以用上一个大公司推出的技术,根据其文章的介绍,博主兴奋的下载了SDK,安装了Demo,小心翼翼的点下了“发布”的按钮,十分钟过去了,消息没到客户端,再次检查应用,重新部署,二十分钟过去了,还是没有收到消息,最终我失望了,不知道是程序没写好,还是百度推送的问题,不过在多次发送之后,只有几条是成功的不知原因何在。为了更好的研究推送技术,研究IM,反编译了jar文件,百度的推送客户端完全使用Java编写,没有使用JNI,同时,百度的推送可以做到在安装程序中有一个已经使用了百度推送,那么这部手机之上的多个应用共享这个推送服务即单一终端多个应用共享一个服务进程和一条TCP长连接。另外百度推送号称实现了业界最小的心跳包,由于反编译的jar包无法看到其内容,也就无法判断其发送的内容。


        第二种方式就是自己建立推送服务器,自己编写编写客户端,但是鉴于1.Safe(安全) 2. Stable(稳定) 3.Save(省电省流量省成本) 4.Slim(体积小)这几个要素,尤其是服务端稳定性,因为使用长连接方案,对服务器的开销和要求很大,推送方案对服务器开发要求很高,海量线程连接下的服务器稳定性是非常具有挑战性的,因此这种方案在小规模应用是可以的,但是如果是大规模应用,建议使用第三方应用。这种方式有两种方案,一种是使用XMPP协议,另外一种就是使用MQTT协议。

        方案1、使用XMPP协议(Openfire + Spark + Smack)
        简介:基于XML协议的通讯协议,前身是Jabber,目前已由IETF国际标准化组织完成了标准化工作。
        优点:协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中,且已有开源的Java版的开发实例androidpn。
        缺点:协议较复杂、冗余(基于XML)、费流量、费电,部署硬件成本高。

        XMPP协议是一种IM协议,其主要面向的是即时聊天,XMPP 获得 Jabber、苹果、惠普、Oracle、Google 和法国电信等的支持,GTalk 就是符合 XMPP 规范的即时通讯软件之一。XMPP协议的一种Java实现就是Smack,其联通了Server和Client,在Android开发领域Smack的一种实现就是aSmack,同时有基于aSmack的Android开源XMPP客户端Beem。


        XMPP作为一种IM协议,拿来做推送可以实现,但是由于其IM原先IM协议的缘故,需要做些改动,改变其冗余的XML,以达到节省电量和流量的作用,同时有AndroidPn这一开源的实现可以参考。其实现Smack的源码org.jivesoftware.smack包下的内容还是有必要一读的。

        方案2、使用MQTT协议
        简介:轻量级的、基于代理的“发布/订阅”模式的消息传输协议。
        优点:协议简洁、小巧、可扩展性强、省流量、省电,目前已经应用到企业领域,且已有C++版的服务端组件rsmb。
        缺点:不够成熟、实现较复杂、服务端组件 rsmb 不开源,部署硬件成本较高。

        MQTT是IBM推出的一种发布/订阅”模式的消息传输协议,其原本是用于传感器和服务器之间的通信,在协议发布出来之后,因为开源的原因,有很多版本的实现,具体看其官网,其中客户端和服务器端都有非常多的版本,服务器端Moquette的实现仅不到10M。但是其服务器端支持的连接数量有限,大约有个五万连接数的限制。但是其比XMPP协议更加的灵活,更省电省流量,心跳包仅仅一个byte+几个byte的头部。小规模企业应用可以使用,博主在做的一个企业应用就是使用这种方案,但是大规模应用需要考虑第三方推送。

        总结:目前推送普遍使用Socket长连接实现,在Android客户端使用AlarmManager定时发送心跳包以维持长连接的连通性,同时其不是IM协议,发送的数据包格式并不是很多,但是在大规模客户端连接时,对服务器开发要求很高,海量线程连接下的服务器稳定性是非常具有挑战性的,可以考虑采用nginx/Node.js方案做服务器端。

        本文纯属对不久之前对IM协议和推送服务学习的一次总结,如有不足之处,还望包涵。


0 0
原创粉丝点击