androidpn 作为Android推送方案存在的问题

cyd 2014-10-28

如果百度或者Google搜索“android推送”关键字,相当一部分文章都在说到androidpn。也可以看到有人说用起来了,有人在吐槽说不稳定、功能缺失,维护工作量大。本文尝试对androidpn的前世今生做个汇总分析。

访问androidpn官方网站,我们可以了解到如下的基本信息:

androidpn全称是AndroidPushNotification。

这是韩国人开源放在sourceforge.net上的一个开源项目,文档是韩文的。

最近的版本更新时间是2010-11-05,也就是约二年之前。

来自中国的访问量,占其总访问量的81%。请点击本链接再看当前的统计。

以上的基本信息表明,这不是一个很成熟的项目(貌似个人维护的),但是确有大量的中国人有兴趣。

相信有不少同学知道为什么国人对androidpn这么感兴趣,这是国情啊:因为Google官方的GCM(之前叫C2DM)在国内使用不了。另外,国内之前又没有可用好用的第三方推送服务。所以,大家不得已而为之:自己搞。从头开始?工作量太大,太不划算了。所以从开源的开始。而也恰好,开源项目里,明确地为AndroidPush来生的,也就androidpn了。mqtt里没有整合这么好可以快速跑起来的。

但androidpn搭建起来后,情况如何呢?CSDN上一个美女程序员的文章androidpn推送初探比较热。这篇文章里作者提出来几个问题:

androidpn服务器收到消息后如何知道要发给哪个用户?

一旦服务器重启了,客户端似乎不会自动重连,需要用户自己中断后台Service再重启应用。

androidpn服务器不保存消息。就是说它一有消息就会发出去,即使客户端根本不在线,它也不会重发。

作者赞在于,不只是满足于把环境搭建起来,而且针对业务需求做了思考。解析下她提出的问题:

第一个问题相对简单,要去定制下用户体系,业务部分的用户体系需要与androidpn对应起来。

第二个问题,是个小细节,androidpn客户端没有去做这些细节。

第三个问题,是最重要的。androidpn背后的Openfire,是XMPPIM服务器,消息内容是不会落地的,即只在内存里保存一下离线消息。如果要生产用,需要考虑改造这里。

以下从androidpn的技术基础来个深入的剖析。

androidpn是一个整合方案,它是基于XMPP开源组件的。即服务器端基于Openfire,客户端基于Smack,这二个是XMPP开源组件里最常见的两个。androidpn使用Spring框架做了个Web层,把XMPPIM组件集成起来,以实现AndroidPush功能。因此,androidpn的可用性来自于如下几个方面:

其依赖的XMPPIM协议与通讯机制,是否适合用于AndroidPush场景。

其是否为AndroidPush需求做了必要的定制。

第一个方面,XMPP协议与开源组件。XMPP是个成熟的IM(即时通讯)协议,基于XML文本方式实现,灵活强大。国外大多数聊天服务都是基于XMPP的,比如:Gtalk,FacebookChat,iMessage等。正因为如此,所以XMPP的一些开源组件可用性还不错,国内很多新兴的聊天工具刚开始完全基于XMPP开源组件来开发,比如米聊。

但是,以笔者曾经实现过移动聊天App的类似经历来说,XMPP开源组件有其问题,需要大范围改造:

XMPP协议复杂冗余,客户端费流量、费电;

开源的XMPP服务器(androidpn选择的是Openfire)单点容量有限,集群方案复杂、不成熟。

基于这些原因,并考虑到大范围改造技术上更不可控,所以笔者所在的团队刚开始用XMPP开源方案,后来完全切到自己实现的技术方案上了。

第二个方面,AndroidPush的需求场景,除了消息能够及时地推送到客户端,还有什么其他的基本需求呢?这里试举两个例子:其一,确保消息能够到达。即是否能有机制确保消息不会丢失,不管什么原因。其二,向指定的一群人推送消息。anroidpn的基础XMPPIM组件是没有考虑这些的,需要做大量的定制改造。

总结起来,使用androidpn可以简单地做到:把消息推送到客户端。但是,要使其适合开发者需要,并在生产环境上运行,则可能需要做很多定制开发工作。从笔者与多个开发者交流得到的反馈来看,在生产环境里运行起来问题很多。

相关推荐