android消息推送怎么实现

　1推送方式基础知识：

　　在移动互联网时代以前的手机，如果有事情发生需要通知用户，则会有一个窗口弹出，将告诉用户正在发生什么事情。可能是未接电话的提示，日历的提醒，或是一封新的彩信。推送功能最早是被用于Email中，用来提示我们新的信息。由于时代的发展和移动互联网的热潮，推送功能更加地普及，已经不再仅仅用在推送邮件了，更多地用在我们的APP中了。

　　当我们开发需要和服务器交互的应用程序时，基本上都需要获取服务器端的数据，比如《地震应急通》就需要及时获取服务器上最新的地震信息。要获取服务器上不定时更新的信息，一般来说有两种方法：第一种是客户端使用Pull（拉）的方式，就是隔一段时间就去服务器上获取一下信息，看是否有更新的信息出现。第二种就是 服务器使用Push（推送）的方式，当服务器端有新信息了，则把最新的信息Push到客户端上。这样，客户端就能自动的接收到消息。 

　　虽然Pull和Push两种方式都能实现获取服务器端更新信息的功能，但是明显来说Push方式比Pull方式更优越。因为Pull方式更费客户端的网络流量，更主要的是费电量，还需要我们的程序不停地去监测服务端的变化。  

　　在开发Android和iPhone应用程序时，我们往往需要从服务器不定的向手机客户端即时推送各种通知消息。我们只需要在Android或IPhone的通知栏处向下一拉，就展开了Notification Panel，可以集中一览各种各样通知消息。目前IOS平台上已经有了比较简单的和完美的推送通知解决方案，我会在以后详细介绍IPhone中的解决方案，可是Android平台上实现起来却相对比较麻烦。

　　最近利用几天的时间对Android的推送通知服务进行初步的研究，也希望能和大家共同探讨一下。

　　2 几种常见的解决方案实现原理：

　　1）轮询(Pull)方式：应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达，你必须自己实现与服务器之间的通信，例如消息排队等。而且你还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。

　　2）SMS(Push)方式：在Android平台上，你可以通过拦截SMS消息并且解析消息内容来了解服务器的意图，并获取其显示内容进行处理。这是一个不错的想法，我就见过采用这个方案的应用程序。这个方案的好处是，可以实现完全的实时操作。但是问题是这个方案的成本相对比较高，我们需要向移动公司缴纳相应的费用。我们目前很难找到免费的短消息发送网关来实现这种方案。

　　3）持久连接(Push)方式：这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。IOS平台的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。不过刚才也讲了，这个方案存在着很多的不足之处，就是我们很难在手机上实现一个可靠的服务，目前也无法与IOS平台的推送功能相比。

　　Android操作系统允许在低内存情况下杀死系统服务，所以我们的推送通知服务很有可能就被操作系统Kill掉了。 轮询(Pull)方式和SMS(Push)方式这两个方案也存在明显的不足。至于持久连接(Push)方案也有不足，不过我们可以通过良好的设计来弥补，以便于让该方案可以有效的工作。毕竟，我们要知道GMail，GTalk以及GoogleVoice都可以实现实时更新的。

　　3第一种解决方案：C2DM云端推送功能。

　　在Android手机平台上，Google提供了C2DM（Cloudto Device Messaging）服务，起初我就是准备采用这个服务来实现自己手机上的推送功能，并将其带入自己的项目中。 

参考文章：

http://blogcsdnnet/carson_ho/article/details/52862418

1 主流的第三方推送平台分类

手机厂商类：小米推送、华为推送。

第三方平台类：友盟推送、极光推送、云巴（基于MQTT）

BAT大厂的平台推送：阿里云移动推送、腾讯信鸽推送、百度云推送

2 对比其他推送方式的特点

其他推送方式还有：C2DM、轮询、SMS、MQTT协议、XMPP协议等等，相对于这些推送方式，第三方推送方式的特点分别是：

优点：

成本低

上述的推送大多数是免费的，假如自己实现则消耗过多资源（开发成本和后台管理、统计成本）

消息到达率高

如果一个手机里有多个App使用了同一家推送服务，那么这些App将共用一条消息通道，即使你家的App推送服务被杀死了，那么只要用户打开了其他集成该推送服务的App，你家的推送就能到达用户

缺点

安全性低

使用别人的服务器，所以你懂的。

服务会被杀死

由于Android系统的机制，后台推送 Service 会被各种主动的或是被动的行为给杀死，而服务一旦被杀死，意味着就接收不到推送消息。

3 第三方推送服务方式的特点

第三方服务基本都具备免费、和到达率高的特点

那么应该如何选择呢？我们来分别看一下第三方推送各种方式的优点：

31 手机厂商推送

请记住一个潜规则：操作系统是不会杀死属于自己品牌的推送服务。

手机厂商的推送服务在自家的手机上属于系统级别的服务，这意味着系统不会杀死自家的推送服务

比如说，Android原生系统是不会杀死C2DM消息推送服务，MIUI系统是不会杀死小米的推送服务。

当今市场上的Android手机系统份额最高是MIUI系统，即小米（具体排名请看http://wwwumindexcom/）

因为：免费、到达率高且在Android系统市场份额第一的MIUI系统上不被杀死。所以，如果要选择手机厂商的推送服务，请选择小米推送作为第三方平台实现推送服务

下面一些应用可以从侧面来证明我的推断：

腾讯新闻使用的小米推送，没有使用自己家的信鸽推送

淘宝使用了自家的阿里云推送，同时还集成了小米推送

百度视频和爱奇艺使用的是小米推送，没有用自家的百度推送

官网截图 - 集成应用：

如果希望进一步提高推送的效果，其实可以集成多个手机厂商的推送服务

比如小米渠道用小米推送，华为渠道用华为推送，但这样的实现成本会大一些

32 第三方平台类

请记住一个规则：推送系统会共享一条推送渠道

这意味着假设你接入了友盟推送，而恰好今日头条也接入了友盟。

有一天你的App被杀死了，但这时用户启动了今日头条，那么推送系统也就会通过共享的推送通道顺便把你推送消息送达到手机上，然后还可能把你的进程也唤醒（被“保活”了）。

所以说，关于如何选择第三方平台类的推送，推送平台的规模效应就很重要了。

那如何得知他们的规模和市场份额呢？按个人经验，主要看两点：

问内部的朋友。

看推送平台的合作客户里有哪些大的app - 参考对应官网的合作案例

33 BAT大厂的推送

BAT大厂其实并没有什么优势，同时谨记：

不要以为用了腾讯信鸽推送，就能占上微信的光保证你的App永远内部被杀死。

说个题外话，手机淘宝除了自家的阿里云的移动推送，同时也使用其它的第三方推送平台啊（比如友盟推送）。

4 如何选择第三方平台推送服务？

主要从用户类别+实现成本+渠道来选择不同的使用场景

1 如果用户群体精准（使用小米手机或华为手机居多），可以考虑只集成对应手机厂商的推送；

注意：单一的手机厂商也能工作，比如小米推送在非小米手机上当然也能工作，只不过不是系统级别的服务了，容易被杀死。

如果用户群体广泛、希望实现成本低，可以考虑只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）

如果用户群体广泛、不在意实现成本，个人建议：

对于小米手机，使用小米推送；

对于华为手机，使用华为推送；

对于其他手机，只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）

让不同的推送运行在各自擅长的环境里，最大化实现推送的到达率和产品的存活率

大家可以根据自己的使用场景来进行消息推送平台的选择。

5 推送消息类别的选择

51 推送消息的类别

通常第三方推送平台都支持两种推送消息类型：通知栏消息和透传消息。

通知栏消息：该类消息在被送达用户的设备后，直接以系统通知栏的形式展示给用户

不会继续被传递到App

透传消息：该类消息在被送达用户的设备后，还会继续传递到App

通过回调App的某个BroadcastReceiver的形式将消息传递到App内部。然后由App决定如何处理和显示这个消息。

所以透传消息不一定会以系统通知栏的形式进行推送，由程序猿自定义

52 消息类别的区别与特点

二者的区别在于：透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App

通知栏消息的优点：送达率高

因为透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App，因此透传消息就增加一些被系统限制的概率，给系统杀死的概率就高一些，所以说，通知栏消息比透传消息应该能提供更好的送达率。

我们来看下小米推送的官方文档描述：

在一些 Android 系统(如 MIUI)中，受到系统自启动管理设置的限制,应用不能在后台自启动

在这类系统中，如果在发送消息的时候对应的应用没有被启动，透传类消息将不能顺利送达。

因此,对于对送达率要求很高的消息,建议尽量采用通知栏提醒的方式推送消息

透传消息的优点：对消息操作程度高 & 自定义程度高

提供了对消息数据的更灵活的操纵能力。

App如果仅仅通过通知栏消息，是无法接触到消息数据本身的。

可自定义通知提醒的样式（包括提示样式、提示形式如声音等等）

所以大家可以根据不同的使用场景来对推送消息类别进行选择了。

所谓的消息推送就是从服务器端向移动终端发送连接，传输一定的信息。比如一些新闻客户端，每隔一段时间收到一条或者多条通知，这就是从服务器端传来的推送消息；还比如常用的一些IM软件如微信、GTalk等，都具有服务器推送功能。

推送方法如下：

　　1)通过SMS进行服务器端和客户端的交流通信。

　　在Android平台上，你可以通过拦截SMS消息并且解析消息内容来了解服务器的意图，可以实现完全的实时操作。但是问题是这个方案的成本相对比较高，且依赖于运营商。

　　2)循环主动定时获取

　　这种方法需要客户端来做一个定时或者周期性的访问服务器端接口，以获得最新的消息。轮询的频率太慢可能导致某些消息的延迟，太快则会大量消耗网络带宽和电池。

　　3)持久连接

　　这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。我们需要开一个服务来保持和服务器端的持久连接（苹果就和谷歌的C2DM是这种机制）。但是对于Android系统，当系统可用资源较低，系统会强制关闭我们的服务或者是应用，这种情况下连接会强制中断。（Apple的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。即所有的推送服务都是经由一个代理服务器完成的，这种情况下只需要和一台服务器保持持久连接即可。C2DM=Cloud to Device Messaging）。

Thank you for your help!问题补充：laorer 写道应该是客户端主动定时去连服务器端，这种操作最好要让用户知道第二个问题应该是不是在用户连接到手机时，存到一个地方，或者内存中，或者数据库中但是现在的需求是当数据库有更新时就要主动发送一个更新通知给所有的客户端，然后客户端接到这个通知后才到服务器端取数据。你说的那是轮询，暂时还不想用这种方法，呵呵。问题补充：laorer 写道如果你只是想把消息发给现在在线的用户的话，那么客户端肯定需要一个监听程序，来监听来自服务器的消息，而服务端则在有新数据时，检查在线的用户并获取相关信息，然后发个消息给客户端的监听端口android是linux内核的，而且能连网络，那么肯定是要端口来连接的，这是我的推测，没有去找相关的资料如果是手机的话，是不是会发条短信给手机，毕竟这样不需要知道IP之类的东西浏览器请求服务时，肯定是浏览器定时去服务器请求的，才可能知道有没有新的内容关于在Android手机端开放监听端口，我再研究一下，值得借鉴。问题补充：laorer 写道如果你是自己来管理这些的话，那么当用户连接到服务器时，你需要把用户的这些内容写到服务器的文本或者数据库或者直接保存到内存中，然后用户断开后，把相应的用户信息删掉这样当数据库有新消息时，你可以从保存用户信息的地方得到所有的连线用户，发消息给用户的话，就是把消息发给用户的IP和监听端口,如果客户端有http服务的话，你也可以直接发送http信息到这个客户端的http服务上这只是我的想法，你做个参考吧

1、打开应用时向服务器发申请

2、如果应用一直打开，或者有后台服务，可以定时向服务器发申请

Google本身就有一个推送demo可以用，Google Cloud Message，你可以参考一下，不过国内用Google推送不太稳定，但是我测试的时候基本上都能推送成功。详细的搭建你可以参考我的微博，有什么问题你再问吧