Android第三方推送引擎比较

所了解的第三方推送引擎有极光推送（JPush）, 百度, 个推，腾讯信鸽等。根据了解，最专业的据说是极光推送，先看极光推送。

一、极光推送

https://www.jpush.cn/

配置：

1.JPush网站创建相应包名的应用，然后网站会生成自动配置好的demo.

2.创建完毕后点击相应应用的"下载Android Example"，导入Eclipse运行

3.网站管理台发送消息，测试成功

经过测试，极光推送的文档是很完善的，而且集成很容易，快速，而且有很多合作商家，同类引擎中应该可以考虑使用。

极光的合作小伙伴：

跟腾讯信鸽、百度云推送相比是最多的。

百度云推送的经典案例：

同时安装两个JPush引擎的软件测试完全正常，但是后台运行的service数目却是线性增加的，也就是有10个用了JPush的应用就会有10个service在运行，下图是测试分别运行1个和2个不同JPush应用的后台程序截图：

IOS平台的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，从这点上来看，极光推送没有做到。

极光推送，个推，腾讯信鸽主要功能大体相似，没有深入比较的必要，要选一个的话肯定选极光推送。

关于个推有人评论：

首先个推是个垃圾，有N多东西要配置，后台有4个服务要跑，Manifest里要配一些meta数据，命名是appid appkey appsecret....名字非常不专业，再看看个推配置的几个service和broadcastreceiver，名字都是sdk.download.**打头的，命名相当不规范。
    还有，新浪微博官方客户端好像用的就是个推，还有他的微友好像也用的是，好像新浪和个信有什么关系。

腾讯信鸽：http://xg.qq.com/

腾讯信鸽测试通过，未做深入比较探讨，截图中运行的XGPushDemoV2就是腾讯信鸽的服务。

评论2;之前一个项目用，从个推否掉以后，看极光文档最专业就用了，基本都还不错，就是偶尔高峰期，连接服务器特别慢，HTTP请求基本3-4秒才返回，担心量大了出问题，就换了百度。

二、百度云推送

http://developer.baidu.com/cloud/push

单数说一下百度是因为百度云推送特意指出了其单通道的特点：单播消息推送，开发者可以向应用的特定终端或特定用户推送消息。特定终端既是安装了某应用的一台具体的设备。特定用户可能有多个终端，应用在给特定用户发送消息时，他的多个终端都可以收到消息。单一终端多个应用共享一个服务进程和一条 TCP 长连接，从而有效降低手机的耗电量和数据流量。

个人使用经验，经常手机装几个软件后即使什么都不开也会卡，运行慢，因此不得不卸掉几个，因此共享一个服务进程的特点值得考虑一下。

另外，百度还有个测试中的新功能：基于地理位置的推送（或"LBS推送"），有了LBS推送，开发者可以根据用户所在的地理位置，有针对性的推送消息，更好的契合用户的信息消费需求。比如，向全北京的用户推送一条暴雨预警通知，向上海的用户推送地铁故障信息，等。

LBS推送是在现有的三种推送模式上的增强，无论是推送通知，透传消息，还是富媒体消息，都可以加上LBS定向这个选项。目前支持省、直辖市、市、区级别的行政区域，后续会增加商圈及自定义地理围栏等功能（仅限Android平台）。

百度的后台管理相当难用，花了半个小时没搞懂怎么创建应用，而且文档跟管理台还是不匹配的，提示的操作找不到：

最后换IE浏览器才看到东西（万能的chrome竟然打不开百度推送的管理页面）

点击快速实例，下载设置好的应用demo，导入Eclipse，运行，安装：

默认会弹出百度账号的登录页面，注释掉LoginActivity的跳转后就不会出现了。

测试安装1个和2个百度推送应用后后台运行截图分别如下：

点开后进程信息如下：

注意第二张截图中通知栏里的两个百度推送图标，是分别给两个不同的应该发送的通知。只有第一个运行的应用的process和service运行，而且两个应用都能收到推送的通知，确实共用了一个推送服务。（截图中有意思的是百度地图竟然没有使用自家的推送服务）

而且卸载掉第一个app后第二个app的推送服务会自动启动：

然后再安装下百度提到的经典案例，看看后台的服务进程，以糗事百科为例。

先安装BaiduPushDemo2，再安装糗事百科:

截图1可以看出仍然启动了一个服务，截图2是点开该服务后的信息，名字为：VersionCheckService，版本检查服务(话说如果这个服务真的只是检查版本的功能的话那这个程序太二了)，然后卸载掉先安装的BaiduPushDemo2,在看一下后台服务运行情况，仍然糗事百科的1个process和1个service。

先运行糗事百科，再运行PushDemo1，会发现PushDemo1的推送服务完全没有启动，后台只有糗事百科的推送服务：

但是PushDemo1的消息第一次发送时过了5分钟收到，不知道是服务器慢了还是中间我触发了某个东西才能收到，后来发送的都很快。

安装糗事百科新版本（2.7）后，无论先安装PushDemo还是先安装糗事百科，只有糗事百科的service在运行，而且PushDemo可以收到通知，也就是糗事百科的push service完全替代了PushDemo的push service。

以上分析可以得出结论，百度云推送确实实现了单通道的特点，至于是否真的能减少耗电和内存消耗，暂时没有明确的标准可以来衡量和探讨。

富媒体消息方面，百度的测试通过，而极光推送的是收费的，但是从这方面来说百度将来关闭推送服务的可能性要比极光推送大一些。

三、极光推送vs百度推送

1、后台管理页面上，显然是极光推送的好用

2、极光支持按Alias和Tag发送，可以定时发送，而百度推送仅支持按Tag发送；

Tag：发给特定用户群,多个。

Alias：发给特定用户，一个。

3、极光推送可以记录API调用发送的消息，而百度仅可以记录通过界面发送的消息；

4、统计同表方面，有细小的不同，但总体功能区别不大，百度终端统计较详细一些（包括设备型号、系统版本、分辨率、运营商、联网方式、应用版本、渠道分布）；

百度sdk可以集成的服务：

总体上来看，极光主要关注的是消息的推送，而百度还关注app运行的整个环境，考虑到数据分析的需求，推荐使用百度推送。