Android上怎么确保消息被推送到

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

　　1、轮询(Pull)方式：客户端定时向服务器发送询问消息，一旦服务器有变化则立即同步消息。但这种方式对服务器的压力太大，且比较费客户端的流量，就是不断地向服务器发送请求，但是这样开发很简单。

　　2、SMS(Push)方式：通过拦截SMS消息并且解析消息内容来了解服务器的命令，但这种方式一般用户在经济上很难承受。服务器的消息，通过发送短信的方式，一般很少采用这种方式，成本高。

　 3、持久连接(Push)方式：客户端和服务器之间建立长久连接，这样就可以实现消息的及时行和实时性。但是这种方式开发难度大，开发周期较长。这是最长使用的方式，目前主流的消息推送都是通过这种方式做的。

　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）服务，起初我就是准备采用这个服务来实现自己手机上的推送功能，并将其带入自己的项目中。 

要获取服务器上不定时更新的信息一般来说有两种方法，第一种是客户端使用Pull的方式，隔一段时间就去服务器上获取信息，看是否有更新的信息出现。第二种就是服务器使用Push的方式，当服务器端有新信息了，则把最新的信息Push到客户端上。 虽然Pull和Push两种方式都能实现获取服务器端更新信息的功能，但是明显来说Push方式更好。因为Pull方式更费客户端的网络流量，同时也耗费电量。 在开发Android和iPhone应用程序时，我们往往需要从服务器不定的向手机客户端即时推送各种通知消息，iPhone上已经有了比较简单的和完美的推送通知解决方案，可是Android平台上实现起来却相对比较麻烦。 在Android手机平台上，Google提供了C2DM（Cloudto Device Messaging）服务。Android Cloud to Device Messaging (C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。C2DM服务负责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这些消息。C2DM操作过程图: 但是这个服务存在一些问题：1）C2DM内置于Android的22系统上，无法兼容老的16到21系统;2）C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用，如果想要很好的使用，App Server必须也在国外，这个恐怕不是每个开发者都能够实现的。 如果C2DM无法满足你的要求，那么就需要自己来实现Android手机客户端与App Server之间的通信协议，保证在App Server向指定的Android设备发送消息时，Android设备能够及时的收到。下面介绍几种常见的方案： 1）轮询(Pull)：应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达，你必须自己实现与服务器之间的通信，例如消息排队等。而且你还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。 2）SMS(Push)：在Android平台上，你可以通过拦截SMS消息并且解析消息内容来了解服务器的意图。这是一个不错的想法，市场上有一些程序就是采用这个方案的。这个方案的好处是，可以实现完全的实时操作。但是问题是这个方案的成本相对比较高，你很难找到免费的短消息发送网关来部署这个方案。 3）持久连接(Push)：这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。Apple的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。不过这个方案也存在不足，就是我们很难在手机上实现一个可靠的服务。Android操作系统允许在低内存情况下杀死系统服务，所以你的通知服务很可能被操作系统Kill掉了。 三个方案都有不足，不过可以通过良好的设计来弥补，以便于让该方案可以有效的工作。毕竟，要知道GMail，GTalk以及GoogleVoice是都可以实现实时更新的。 采用MQTT协议实现Android推送 MQTT是一个轻量级的消息发布/订阅协议，它是实现基于手机客户端的消息推送服务器的理想解决方案。 wmqttjar 是IBM提供的MQTT协议的实现。你可以从如下站点下载它。

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

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

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

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

iOS 的推送iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 iOS 的推送

iOS 在系统级别有一个推送服务程序使用 5223 端口。使用这个端口的协议源于 Jabber 后来发展为 XMPP ，被用于 Gtalk 等 IM 软件中。所以， iOS 的推送，可以不严谨的理解为：

苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。

然后，系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事。

然后，系统分别通知这些 Apps 。应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。 因为：

1 使用久经考验的协议，技术风险小。

2 苹果勇于承担责任：

他需要维护一个代价不小的服务器集群，而且要为服务器的 down 机负责。

选择低风险的技术方案 Bug 更少，减轻了用户的痛苦，这是构架师的功劳。

苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。

这，只能说是公司决策者的功劳。

（从侧面说明有个懂技术的 VP 是多重要。。。而 Scott 走人了。。）

他们带给用户的好处也是实实在在的。

1 安全。

只有登录过的开发者可以通过苹果的服务器推送。

2 快速，稳定，可靠。

苹果掌控推送服务器和 OS 。

3 更省电。

4 让整个系统的体验更统一和简单。

不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。

也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）。

5 开发容易。

当然，开发者还是要做些事情，比如维护个服务器什么的： http://wwwifanrcom/3979。但是复杂度无疑降低很多了。

Android 的推送

Apps 挂后台一直是 Android 引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。

当然， Google 事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。

用户的电池？

Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。而 Google 不强制的结果就是：没人真正为用户的电池负责。

但是， Google 的方案也并非全是悲剧：

也因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。

像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。

最后的话

强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。

所以，如果说苹果的推送方案有何创新？

我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有 BB 的专用网络， Kindle 的全球 3G ）

个人相信，担负起这些“额外”的责任，是值得的。。。