一、背景
如果要自己搭建，从零开始做或基于开源进行修改扩充，开源的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.0in un.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的二次开发不可行，如果公司有足够的人力物力和相关技术的经验积累，完全可以考虑自己做推送系统，或者使用第三方的平台。建议使用第三方推送平台。