android Push 服务的消息

方案一：使用GCM服务（Google Cloud Messaging）

简介：Google在Android上标配了自己的推送GCM（Google Cloud Messageing），可以帮助开发人员给他们的Android应用程序发送数据。它是一个轻量级的消息，告诉Android应用程序有新的数据要获取从服务器，或者它可能是一个消息，其中包含了4KB的payload data（像即时通讯这类应用程序可以直接使用该payload消息）。GCM服务处理排队的消息，并把消息传递到目标设备上运行的Android应用程序。

优点：Google提供的服务、原生、简单，无需实现和部署服务端。 

缺点：

1.GCM要求Android系统必须是2.2以上的版本，所以对于不少2.2以前的系统没法推送

2.国内服务不稳定。而且不少国内的终端厂商纷纷把Google的服务去掉，替换上自己的。

3.需要用户绑定Google账号，但不少国内用户没有Google账号。

方案二：使用XMPP协议（Openfire + Spark + Smack）

简介：XMPP是一种基于XML的协议，它继承了在XML环境中灵活的发展性，有很强的可扩展性。包括上面讲的GCM服务器底层也是采用XMPP协议封装的。

优点：协议成熟、强大、可扩展性强、目前主要应用于许多聊天系统中，且已有开源的Java版的开发实例androidpn。 

缺点：协议较复杂、冗余（基于XML）、费流量、费电，部署硬件成本高。

而androidpn（Android Push Notification）就是基于 XMPP 开源组件的一套整合方案，服务端基于Openfire、客户端基于Smack。到AndroidPN项目主页( http://sourceforge.net/projects/androidpn/ ) 下载2个文件： androidpn-server-0.5.0-bin.zip 和 androidpn-client-0.5.0.zip 分别是服务器和客户端的代码。详细的实现方式网上有不少文章。

androidpn是韩国人放在sourceforge.net 的项目，已经有两年多没有更新了，项目应该是个人维护的，不是很成熟。有意思的是，网站上这个项目有82%的下载者的ip是中国的。androidpn有如下一些不足，开发的时候需要权衡：

1、androidpn服务端重启后客户端不会重连，这个非常悲剧

2、由于服务器不保存消息，造成了如果客户端当前离线就收不到消息。

3、androidpn发送完消息就不管了，所以没有消息回执报表之类，造成没法做应用后续的数据分析用户体验的改善，这对于企业级的应用是个致命伤。

XMPP协议比较费电费流量，这个对当前智能机的消耗太大，在窄带网络和不稳定的（手机）网络都不是最优的选择。但总体来说，XMPP协议还是比较成熟的。

方案三：使用MQTT协议（更多信息见： http://mqtt.org/）

简介：轻量级的、基于代理的“发布/订阅”模式的消息传输协议。 

优点：协议简洁、小巧、可扩展性强、省流量、省电，目前已经应用到企业领域（参考： http://mqtt.org/software），且已有C++版的服务端组件rsmb。 

缺点：不够成熟、实现较复杂、服务端组件rsmb不开源，部署硬件成本较高。

方案四：使用HTTP轮循方式

简介：定时向HTTP服务端接口（Web Service API）获取最新消息。 

优点：实现简单、可控性强，部署硬件成本低。 

缺点：实时性差。

方案五：采用第三方服务

目前有不少第三方提供了类似服务，客户端只需要嵌入第三方提供的lib库，由第三方建立长连接，负责消息的接收/发送。同时对于消息都有比较详细的报表数据，可以用于做数据分析挖掘和用户体验的改善。目前国内提供推送服务的有好几家，比较成熟的主要有百度云推送, 极光推送, 个推服务。

还是出于对大公司的信任吧，所以这次选择了百度的云推送，总的来说官方文档使用说明还是蛮详细的。百度的云推送共提供三种形式的推送：

1.顶部通知栏消息提醒，当然也是提供自定义；

2.消息，可以是无界面的，也可以是用户自己定义的消息处理方式；

3.富媒体推送，如图片，声音等。

值得说明的是第一种提醒方式是比较常见的，这次的app中也是这种方式，但是SDK提供的这种顶部通知栏消息点击事件每次都会重新打开一次app，哪怕之前你的app是打开过的。这种交互方法非常不友好，为了解决这个问题试了很久也没能找到相应的方法。

于是在第二种消息提醒方式时，才发现这种定制性更强，只是处理的时候有些麻烦。这里客户端拿到推送消息时手动处理使在顶部通知栏显示，并把这些提醒信息保存进客户端Sqlite文件里，从而使交互更加友好。

当然基于以后的推送新的需求可能会涉及到富媒体推送之类的，以后用到时再看下实现方式。当然以后有机会也会了解下其他的推送服务，来了解各自推送服务的优劣，从而能确定一个最优的服务。