市面上Android推送方案存在的问题
市面上Android推送方案存在的问题
关于服务端向Android客户端的推送，主要有三种方式：
轮询：应用程序应当阶段性的与服务器进行连接并查询是否有新消息的到达，你必须自己实现与服务器之间的通信，例如消息排队等。而且你还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗流量和电量。
SMS：通过发送短信并解析短信内容来获取服务器端的指令，这个里面的问题是很难找到免费的网管来发送短信。
Socket：socket通讯，保持持久连接
以上是基于推送的三种方案，现在市面上的推送也都是基于第三种方案的。
如果有兴趣的可以在Google,百度搜索“android 推送”关键字，相当多的文章是说的androidpn，以及极光推送服务，关于这两个推送方案，本文在此做个分析。
首先是androidpn：
androidpn全称是Android Push Notification,这是韩国人的一个开源项目，放在sourceforge.net ，这个开源项目貌似是个人在维护的，不同的人对这个项目有不同的见解。
人们对于未知的事物总是充满了好奇，正是因为人们的好奇心，才促使整个社会的进步。相信有不少同学知道为什么对androidpn这么感兴趣，这是源于国家伟大的GWF，因为google官方的GCM（Google Cloud Message,之前叫C2DM）在国内使用不了。另外，国内之前又没有可用的推送服务。如果是自己搞，从头开始，工作量太大，维护成本太高。在开源的项目里，androidpn应运而生。
虽然androidpn搭建起来后，情况如何呢？请看下面的分解
l androidpn服务器收到消息后如何知道要发给哪个用户？
l 一旦服务器重启了，客户端似乎不会自动重连，需要用户自己在service进行重连
l androidpn服务器不支持离线消息的发送
观看了以上的问题，你会发现，如果你想要使用androidpn，你需要修改其中的源码，这样对于用户来说，是非常不方便的。
以下从 androidpn 的技术基础来个深入的剖析。
androidpn 是一个整合方案，它是基于 XMPP 开源组件的 。即服务器端基于 Openfire，客户端基于 Smack ，这二个是 XMPP 开源组件里最常见的两个。androidpn使用Spring框架做了个Web层，把XMPP IM组件集成起来，以实现Android Push功能。因此，androidpn的可用性来自于如下几个方面：
1. 其依赖的XMPP IM协议与通讯机制，是否适合用于Android Push场景。
2. 其是否为Android Push需求做了必要的定制。
第一个方面，XMPP协议与开源组件。XMPP是个成熟的IM（即时通讯）协议，基于XML文本方式实现，灵活强大。国外大多数聊天服务都是基于XMPP的，比如：Gtalk，Facebook Chat，iMessage等。正因为如此，所以XMPP的一些开源组件可用性还不错，国内很多新兴的聊天工具刚开始完全基于XMPP开源组件来开发，比如米聊。
但是，以笔者曾经实现过移动聊天App的类似经历来说，XMPP开源组件有其问题，需要大范围改造：
1. XMPP协议复杂冗余，客户端费流量、费电；
2. 开源的XMPP服务器（androidpn选择的是Openfire）单点容量有限，集群方案复杂、不成熟。
基于这些原因，并考虑到大范围改造技术上更不可控。
第二个方面，Android Push的需求场景，除了消息能够及时地推送到客户端，还有什么其他的基本需求呢？这里试举两个例子：其一，确保消息能够到达。即是否能有机制确保消息不会丢失，不管什么原因。其二，向指定的一群人推送消息。anroidpn的基础XMPP IM组件是没有考虑这些的，需要做大量的定制改造。
总结起来，使用androidpn可以简单地做到：把消息推送到客户端。但是，要使其适合开发者需要，并在生产环境上运行，则可能需要做很多定制开发工作。从笔者与多个开发者交流得到的反馈来看，在生产环境里运行起来问题很多。
