移动手机消息推送机制.docx
《移动手机消息推送机制.docx》由会员分享，可在线阅读，更多相关《移动手机消息推送机制.docx（9页珍藏版）》请在冰点文库上搜索。
移动手机消息推送机制
移动消息推送机制
由于公司要做一个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〞。
即使用户当前处在离线状态，用户收到消息之后激活程序，再通过程序链接应用效劳器下载邮件或者录音。
WP7〔Microsoft〕的Push机制如下列图：
WP7的也有相应的推送效劳，无论程序是否开启都可以界面顶部推送ToastNotification，并显示10秒。
WP7的PushClient负责于效劳器交互，接受到消息时再传送给相应的应用程序，而不需要应用程序各自维护一个进程。
如果程序被钉在首页，效劳器推送瓦片通知〔TileNotification〕，改变瓦片的背景图片、数字和标题属性。
而弹出框式的原生推送〔RawNotification〕只能应用在程序开启时，容许实时更新界面
WebOS（BlackBerry）的推送机制如下如所示：
从示意图中可以看到在BlackBerry应用平台上的数据推送从整体上可以分为六步，按时间顺序分别为：
第一步：
应用效劳器向MDS/BES效劳器发送推送请求，所发送的请求为格式的请求。
第二步：
MDS/BES效劳器查询相关配置数据库，确定应用效劳器所发送的请求是否为合法的请求。
此外，MDS/BES效劳器还会根据资源情况确定是否接收该请求。
对于是否接收请求的判断在下一节内容中也有详细讨论
第三步：
MDS/BES效劳器向应用效劳器返回消息，通知应用效劳器是否接受该请求。
返回消息以答复的方式返回给应用效劳器
第四步：
MDS/BES效劳器将数据推送到手持设备端
第五步：
手持设备端对数据进行处理后向MDS/BES效劳器返回确认消息
第六步：
MDS/BES根据手持设备端返回的消息决定向应用效劳器返回什么异步消息，这一步并不是必然发生的，根据推送请求的不同有可能不发生。
黑莓的推送是最早的，最早应用在邮件上，而且黑莓的推送机制也是加密最好的，最平安的机制。
下面我们来详细的介绍一下android的推送机制：
Android〔Google〕：
首先介绍一下google官方应用的push：
1〕如果你有新的Gmail邮件，可以马上收到邮件通知，这个中间可能有2，3秒的延迟，一般感觉还是很及时的；
2〕如果你的联系人和GoogleContanct是关联的话，你用桌面浏览器访问Gmail，修改联系人信息，很快新的联系人信息就会同步到你上。
在GoogleI/O2021介绍了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@google
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〔基于长连接的“效劳器推〞技术〕长连接也可以实现。
详细可以参照:
//ibm/developerworks/cn/web/wa-lo-comet/，但是这并不是最有的一种方式，
在Android下最有的方式应该采取XMPP协议推送Android信息：
首先介绍一下XMPP基于可扩展标记语言〔XML〕的协议，它用于即时消息〔IM〕以及在线探测。
这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。
详细参考：
:
//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效劳器，采用一个轻量级的效劳器，负责接收用户的Web请求。
效劳器架构如下：
最上层包含四个组成局部，分别是SessionManager，AuthManager，PresenceManager以及NotificationManager。
SessionManager负责管理客户端与效劳器之间的会话，AuthManager负责客户端用户认证管理，PresenceManager负责管理客户端用户的登录状态，NotificationManager负责实现效劳器向客户端推送消息功能。
效劳器端界面如下，分别对应了上述的几个功能模块：
发送以后，我们可以在端看到接收的消息：
这个解决方案的最大优势就是简单，我们不需要象C2DM那样依赖操作系统版本，也不会担忧某一天Google效劳器不可用。
利用XMPP协议我们还可以进一步的对协议进行扩展，实现更为完善的功能。
采用这个方案，目前只能发送文字消息，不过对于推送来说一般足够了，因为我们不能指望通过推送得到所有的数据，一般情况下，利用推送只是告诉端效劳器发生了某些改变，当客户端收到通知以后，应该主动到效劳器获取最新的数据，这样才是推送效劳的完整实现。
升级会员 