Android消息推送机制调研
技术选型
轮询（PULL）
简介：循环主动定时获取服务器消息
优点：实现简单，可控性强，部署成本低。
缺点：需要客户端定时或者周期性的服务器接口，太慢则造成消息延迟，太快则消耗电量、流量，实时性差。
适用情形：更新不是很频繁的应用，比如手电筒、天气之类的功能性应用。
长连接（PUSH）
简介：客户端与服务器端建立一个基于TCP/IP的长连接，服务器就可以向客户端发送消息。
优点：实时性好，协议成熟，强大，可扩展性好，多用于聊天系统，有开源的方案androidpn。
缺点：协议较复杂，部署成本高。
基于长连接的实现方案
基于MQTT协议实现消息推送方案
基于IBM的MQTT协议实现，服务器端没有开源，需要收费，资料文档也很少。
参考：MQTT简单例子
基于XMPP协议实现的消息推送方案
1) 谷歌的GCM实现消息推送
壮哉我大天朝，地球人都知道，特色国情，服务时断时续不稳定
使用教程：https://developers.google.com/android/c2dm/
2) 开源的androidpn实现
源代码网址：http://sourceforge.net/projects/androidpn
使用教程：http://blog.csdn.net/berber78/article/details/7638673
代码笨重，需要结合自身应用做二次开发，米聊采用的是这种方案。
3) 国内消息推送服务提供商
个推：官方说法和百度、新浪都有合作案例，不知真假。文档、技术支持都很全。
参见其网页介绍：http://www.igetui.com/home.htm
激光推送：有很好的文档、及入门案例
网页介绍：http://www.jpush.cn/
参考实现
实时性要求低：
可以采用轮询机制，客户端向服务器端拉取数据，判断是否有更新并向用户提示，当用户点击应用时，在向服务器接口获取最新的应用详情。
实时性要求高：
采用长连接机制，推拉相结合，再根据产品具体需求，判断是通过自己搭建长连接服务，还是采用服务商方案。