Android_Push_开源方案解析.pdf

AndroidPush开源方案解析

在Android上，因为Google自己实现的Android标配的GCM(GoogleCloudMessaging，
原来叫C2DM)在国内基本不可用，所以，对于开发者来说，如果需要Push功能，怎么样选
择成为了一个问题。

到目前为止，国内尚没有完全向开发者免费、开放的Push服务可用。国外有几家第三方推送
服务，但一般都要收费。所以一般来说，国内的开发者不得不考虑自己来搭建Push服务。

自己构建Push服务时，一个比较自然的选择就是，基于开源的现在方案来做。

使用Google或者百度搜索"AndroidPush推送"等关键词，表明已经有不少人研究过。排在前
边的是这样几篇文章：

Android实现推送方式解决方案
用androidpn来实现推送
Android上实现Push
AndroidPushNotification实现信息推送使用

上面文章提及的方案里，基本上都提及了一个开源的AndroidPush实现:androidpn。

androidpn它本质上服务器端基于Openfire，客户端基于asmack，这二者都最XMPPIM开
源实现里的二个基本组件，应该说androidpn只是把二者更多地结合起来用于做Push的场景。

本人做过聊天App，愿意在这里，把基于XMPP开源系统做IM的实践经验分享给大家。

我们做聊天类App，比较自然地，刚开始时也是从研究开源的XMPPIM系统入手。

先说服务器端选择。Openfire是一个XMPP最古老的开源IMServer，几乎所有做IM的都
应该有研究过。但是，它也是最不合适运用到生产的IMServer，因为：单机并发很有限，集群
方案不成熟，代码古老而缺乏及时更新。举个具体的例子：Openfire的集群组件叫Connection
Manager，但是，你在Openfire官方网站可以看到，最近一个版本是2009年2月份发布的。
可见，基于Openfire实现的androidpn的根基是不够稳的。

还有另外二个其实相对好一点的选择：ejabberd,tigase。ejabberd是用Erlang语言实现的，
懂Erlang的用户很少，所以一般不会选。我们当时初步的聊天服务器端选择是tigase。

tigase作者维护很活跃，集群测试结果能够支撑比较大的容量，这是吸引我们的地方。但经过
实际生产运营情况来看，由于其集群方案实现的复杂性，以及单节点容量的有限，我们对支撑到
50万用户在集群节点上没有信心，所以在到达50万用户之前，赶快自己开发了替代方案。

再来说XMPP协议与客户端的问题：对于移动客户端来说，原始的XMPP有些复杂而且流量
消耗大。XMPP本质上协议体都在字符串的xml结构上，每个协议都量一堆的字符串，xml
里还有很多无意义的结构。另外，XMPP为了其灵活性，就登录这个事情都需要有N个来回。
对于手机客户端很在乎流量与电量来说，XMPP比较笨重。
我们的作法是：协议格式上改为二进制，协议内容上简化交互，但保留对原始XMPP的兼容。

androidpn是开源的Push实现，是基于XMPP开源组件集成的，它没有为手机应用场景做
必要的优化。另外，XMPP本质上双向IM协议，而直接基于XMPP来实现Push功能，也
是没有特别地为Push的特点优化的，比如客户端网络连接的策略等。

总结一下以androidpn为典型的开源AndroidPush方案会存在的问题：

１）容量大了开源服务器实现顶不住，还是需要自己去改进开源实现，或者完全重新用新方案，
开发投入与高成本是不可避免的。

２）协议与实现上如流量消耗、网络连接策略等，不是专门为移动Push优化过的，是不经济
的。

基于我们团队基于XMPP开源系统实现聊天App的实践经验，我们提出的结论是，在移动端的
IM场景里，开源方案不是个可用好用的方案。后来我们自己完全重新架构了整套系统。之后，
正是基于这套全新架构的IM系统，演变出来了极光推送。

极光推送专门为移动场景下的实时Push来研发，我们想要去解决国内Android开发者没有可
用好用的Push方案的问题，是免费的，完全向普通开发者开放。如果你也有这个AndroidPush
的需求，不妨到极光推送官方网站进一步地了解。