基于AndroidPn二次开发的可行性

一、背景

如果要自己搭建，从零开始做或基于开源进行修改扩充，开源的push引擎，90%的博文首推AndroidPN，结合公司现状，最优解决方案就是进行AndroidPN的二次开发了。先看一下这个项目：

这是韩国人放在 sourceforge.net 上的一个开源项目，文档是韩文的。
最近的版本更新时间是 2010-11-05，也就是约二年之前。
来自中国的访问量，占其总访问量的 81%。统计链接：

http://sourceforge.net/projects/androidpn/files/stats/timeline

以上的基本信息表明，这不是一个很成熟的项目（貌似个人维护的），但是确有大量的中国人有兴趣，因为谷歌的服务国内用不了，开源项目里，明确地为 Android Push来生的，也就 androidpn了。

二、配置AndroidPN

AndroidPN全称 Android Push Notification，特点是：

快速集成:提供一种比C2DM更加快捷的使用方式,避免各种限制.
无需架设服务器:通过使用"云服务",减少额外服务器负担.
可以同时推送消息到网站页面,android 手机
耗电少,占用流量少.

具体配置过程：

首先，需要下载androidpn-client-0.5.0.zip和androidpn-server-0.5.0-bin.zip。

下载地址：http://sourceforge.net/projects/androidpn/

解压两个包，Eclipse导入client，配置好目标平台，打开raw/androidpn.properties文件，配置客户端程序。

1. 如果是模拟器来运行客户端程序,把xmppHost配置成10.0.2.2[模拟器把10.0.2.2认为是所在主机的地址，127.0.0.1是模拟器本身的回环地址，10.0.2.1表示网关地址，10.0.2.3表示DNS地址，10.0.2.15表示目标设备的网络地址]，关于模拟器的详细信息，大家可参阅相关资料，这里不再详述.

xmppPort=5222 是服务器的xmpp服务监听端口

运行androidpn-server-0.5.0\bin\run.bat启动服务器，从浏览器访问http://127.0.0.1:7070/index.do (androidPN Server有个轻量级的web服务器，在7070端口监听请求，接受用户输入的文本消息)

运行客户端，客户端会向服务器发起连接请求，注册成功后，服务器能识别客户端，并维护和客户端的IP长连接。

2. 如果是在同一个局域网内的其他机器的模拟器测试(或者使用同一无线路由器wifi上网的真机) ，则需要把这个值设置为服务器机器的局域网ip.

　　例如你的电脑和android手机都通过同一个无线路由器wifi上网, 电脑的ip地址为 192.168.1.2 而手机的ip地址为 192.168.1.3, 这个时候需要把这个值修改为 xmppHost=192.168.1.1 或是电脑的IP地址，就可以在手机上使用了.

　　3. 如果是不在同一个局域网的真机测试，我们需要将这个值设置为服务器的IP地址。

具体配置如下图所示：

我的电脑IP是：192.168.8.107

服务器运行主界面：

推送信息如下界面所示：

测试结果如下图所示：

局域网模拟器已测试通过！

三、AndroidPN存在的问题

下列问题均是众博主提到过的，未做详细具体的测试：

1. 比如时间过长时，就再也收不到推送的信息了。

这点我用虚拟机测试没有发生，测试时长10h。

2. 性能上也不够稳定。

需经过详细测试。

3. 如果将消息从服务器上推送出去，就不再管理了，不管消息是否成功到达客户端手机上。

可以解决,但需要大量的服务器工作。

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

androidpn 客户端没有去做这些细节，需要自己解决。

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

重要。androidpn 背后的 Openfire，是 XMPP IM服务器，消息内容是不会落地的，即只在内存里保存一下离线消息，需要考虑改造这里。

6. 考虑到大范围改造技术上更不可控，团队初期用XMPP开源方案，后来完全切到自己实现的技术方案的案例：http://www.oschina.net/question/861681_79887

四、AndroidPN二次开发可行性

二次开发，归结为一点就是，读懂源码然后修改扩充优化。

先看客户端的源码：

分两个包：client和demoapp

显然demoapp只是一个功能演示，里面只实现了一个核心功能：

// Start the service

ServiceManager serviceManager = new ServiceManager(this);

serviceManager.setNotificationIcon(R.drawable.notification);

serviceManager.startService();

鉴于该引擎的不完善，简要估计下改造成本,先看客户端几个主要类代码量：

XmppManager 478

NotificationService 298

ServiceManager 198

其余14个类代码量均小于200行，从客户端代码量看，客户端的大规模改造可行。

对服务器不是很了解，没有具体深入研究，看一下代码包吧，服务器端仅jar包数就53个，除了工具包外，估计需要改造的包很有可能超过10个，而且这只实现了基本功能，存在众多问题而且还有很多的功能要添加，如果要做到第三方推送的完成程度，其工作量相比于完全自己搭建几乎无差别。

综上，要实现相对完整的推送系统，基于AndroidPN的二次开发不可行，如果公司有足够的人力物力和相关技术的经验积累，完全可以考虑自己做推送系统，或者使用第三方的平台。建议使用第三方推送平台。