移动手机消息推送机制.docx
《移动手机消息推送机制.docx》由会员分享，可在线阅读，更多相关《移动手机消息推送机制.docx（7页珍藏版）》请在冰豆网上搜索。
移动手机消息推送机制
移动手机消息推送机制
移动手机消息推送机制
由于公司要做一个android的消息推送功能，让我进行了一个调研，发现网上没有一个集中说明的地方，自己在网上搜罗了一些资料并且自己总结了一下。
对于消息的提醒方式可以分为四种：
固定窗口、弹出窗口、手机短信和Push信息。
下面的针对于push信息的机制和技术实现向大家介绍一下。
首先，我们要知道什么是Push信息？
所谓信息推送，就是"web广播"，是通过一定的技术标准或协议，在互联网上通过定期传送用户需要的信息来减少信息过载的一项新技术。
推送技术通过自动传送信息给用户，来减少用于网络上搜索的时间。
它根据用户的兴趣来搜索、过滤信息，并将其定期推给用户，帮助用户高效率地发掘有价值的信息。
简单的来说，信息推送就是服务器端主动向客户端发送信息，客户端进行接收信息。
如下图：
使用推送信息的好处:
1、节省用户的电池电量。
2、你可以通过推送通知来告知你的用户在程序中发生了一些有趣的事，即使程序没有运行。
现在很多应用程序都是用的推送的机制：
包括新浪微博，推送最新的朋友消息；墨迹天气推送最新的天气状况；网易新闻，推送重要的新闻；同花顺手机炒股推送最新的股票资讯；微信，推送最新的语音最新。
Gmail、Gtalk推送最新的Mail信息和IM信息。
下面，我们了解一下现在主流手机的push机制。
IPhone（APPLE）的工作机制可以简单的概括为下图：
iPhone自3.0之后推出消息推送机制，原理是消息由服务器统一处理。
图中，Provider是指某个iPhone软件的Push服务器，这篇文章我将使用Java作为Provider。
APNS是ApplePushNotificationService（ApplePush服务器）的缩写，是苹果的服务器。
上图可以分为三个阶段。
第一阶段：
Java应用程序把要发送的消息、目的iPhone的标识打包，发给APNS。
第二阶段：
APNS在自身的已注册Push服务的iPhone列表中，查找有相应标识的iPhone，并把消息发到iPhone。
第三阶段：
iPhone把发来的消息传递给相应的应用程序，并且按照设定弹出Push通知。
从上图我们可以看到。
1、首先是应用程序注册消息推送。
2、IOS跟APNSServer要deviceToken。
应用程序接受deviceToken。
3、应用程序将deviceToken发送给PUSH服务端程序。
4、服务端程序向APNS服务发送消息。
5、APNS服务将消息发送给iPhone应用程序。
APNs和iPhone保持15分钟的心跳式长连接，维护手机和服务器的联系正常，否则手机会不停发起连接，直到连接到服务器为止。
程序不必实时开启和主动检查更新，当收到APNs消息时，iPhone会弹出对话框Push消息并伴随着声音，用户可以选择“view”或者“close”。
从示意图中可以看到在BlackBerry应用平台上的数据推送从整体上可以分为六步，按时间顺序分别为：
第一步：
应用服务器向MDS/BES服务器发送推送请求，所发送的请求为HTTP格式的请求。
第二步：
MDS/BES服务器查询相关配置数据库，确定应用服务器所发送的请求是否为合法的请求。
此外，MDS/BES服务器还会根据资源情况确定是否接收该请求。
对于是否接收请求的判断在下一节内容中也有详细讨论
第三步：
MDS/BES服务器向应用服务器返回消息，通知应用服务器是否接受该请求。
返回消息以HTTP答复的方式返回给应用服务器
第四步：
MDS/BES服务器将数据推送到手持设备端
第五步：
手持设备端对数据进行处理后向MDS/BES服务器返回确认消息
第六步：
MDS/BES根据手持设备端返回的消息决定向应用服务器返回什么异步消息，这一步并不是必然发生的，根据推送请求的不同有可能不发生。
黑莓的推送是最早的，最早应用在邮件上，而且黑莓的推送机制也是加密最好的，最安全的机制。
下面我们来详细的介绍一下android的推送机制：
Android（Google）：
首先介绍一下google官方应用的push：
1）如果你有新的Gmail邮件，手机可以马上收到邮件通知，这个中间可能有2，3秒的延迟，一般感觉还是很及时的；
2）如果你的联系人和GoogleContanct是关联的话，你用桌面浏览器访问Gmail，修改联系人信息，很快新的联系人信息就会同步到你手机上。
在GoogleI/O2010介绍了Android2.2导入的 AndroidCloudtoDeviceMessaging（C2DM） 服务，C2DM）作为Android2.2的一部分已经发布了。
C2DM允许第三方开发者开发相关的应用来推送少量数据消息到用户的手机上，其机制如下图：
AndroidCloudtoDeviceMessaging（C2DM）是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。
该服务提供了一个简单的、轻量级的机制，允许服务器可以通知移动应用程序直接与服务器进行通信，以便于从服务器获取应用程序更新和用户数据。
C2DM服务负责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这些消息。
启用C2DM的过程：
1，移动设备：
必须运行android，并且安装Market，至少有一个登录的google账号。
2，服务器：
自己的服务器
3，C2DM服务器：
google的服务器
授权机制：
1， SenderID：
一个google账号，用于标示开发者的身份，比如hxzhoupeng@
2，ApplicationID：
Manifest.xml里面的pacakagename。
用于标示应用程序
3，RegistrationID：
当应用程序向C2DM服务器注册时，C2DM服务器会返回这个ID，当应用程序获得这个ID之后，应该告诉自己的服务器，自己的服务器把这个ID存在数据库里面，用于告诉C2DM服务器标示客户端。
4，GoogleUserAccount：
要使用C2DM服务，必须有一个google账号。
5，SenderAuthToken：
自己的服务器与C2DM服务器通信的认证。
应用程序发送Intent，com.google.android.c2dm.intent.REGISTER，附上自己的SenderID和AppId，就可以向C2DM服务器进行注册，注册成功之后，可以收到REGISTRATIONIntent，获得RegistrationID，这个RegistrationID是会被C2DM改变的，所以这个REGISTRATIONIntent可能会收到多次，要记得存储和发送给自己的服务器
通过对比研究发现C2DM机制存在以下缺点：
1、C2DM内置于Android的2.2系统上，无法兼容老的1.6到2.1系统;
2、C2DM需要依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用，如果想要很好的使用，我们的AppServer必须也在国外，这个恐怕不是每个开发者都能够实现的;。
除了C2DM在实现Android消息推送机制的方案还有以下几种：
1、轮询（polling）：
应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达，你必须自己实现与服务器之间的通信，例如消息排队等。
而且你还要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池。
2、长连接：
这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。
Apple的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。
不过这个方案也存在不足，就是我们很难在手机上实现一个可靠的服务。
Android操作系统允许在低内存情况下杀死系统服务，所以你的通知服务很可能被操作系统Kill掉了。
这种方法通过come（基于HTTP长连接的“服务器推”技术）长连接也可以实现。
详细可以参照
在Android下最有的方式应该采取XMPP协议推送Android信息：
首先介绍一下XMPP基于可扩展标记语言（XML）的协议，它用于即时消息（IM）以及在线探测。
这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
详细参考：
http:
//zh.wikipedia.org/zh-cn/XMPP
Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。
androidpn是一个基于XMPP协议的java开源Androidpushnotification实现。
它包含了完整的客户端和服务器端。
该服务器端基本是在另外一个开源工程openfire基础上修改实现的。
它的实现示意图如下：
androidpn客户端需要用到一个基于java的开源XMPP协议包asmack，这个包同样也是基于openfire下的另外一个开源项目smack，不过我们不需要自己编译，可以直接把androidpn客户端里面的asmack.jar拿来使用。
客户端利用asmack中提供的XMPPConnection类与服务器建立持久连接，并通过该连接进行用户注册和登录认证，同样也是通过这条连接，接收服务器发送的通知。
androidpn服务器端也是java语言实现的，基于openfire开源工程，不过它的Web部分采用的是spring框架，这一点与openfire是不同的。
Androidpn服务器包含两个部分，一个是侦听在5222端口上的XMPP服务，负责与客户端的XMPPConnection类进行通信，作用是用户注册和身份认证，并发送推送通知消息。
另外一部分是Web服务器，采用一个轻量级的HTTP服务器，负责接收用户的Web请求。
服务器架构如下：
最上层包含四个组成部分，分别是SessionManager，AuthManager，PresenceManager以及NotificationManager。
SessionManager负责管理客户端与服务器之间的会话，AuthManager负责客户端用户认证管理，PresenceManager负责管理客户端用户的登录状态，NotificationManager负责实现服务器向客户端推送消息功能。
服务器端界面如下，分别对应了上述的几个功能模块：
发送以后，我们可以在手机端看到接收的消息：
这个解决方案的最大优势就是简单，我们不需要象C2DM那样依赖操作系统版本，也不会担心某一天Google服务器不可用。
利用XMPP协议我们还可以进一步的对协议进行扩展，实现更为完善的功能。
采用这个方案，目前只能发送文字消息，不过对于推送来说一般足够了，因为我们不能指望通过推送得到所有的数据，一般情况下，利用推送只是告诉手机端服务器发生了某些改变，当客户端收到通知以后，应该主动到服务器获取最新的数据，这样才是推送服务的完整实现。
升级会员 