因为iOS有强大的产品生态体系,APP从研发到审核上架,再到最后在手机端运行,都有严格的把关。所以推送功能在它这里实现起来比较简单。每个设备只要保持一个与APNs的常链接,服务器将要推送的消息发送给APNs,APNs再将消息转发到响应的手机,手机内置的程序再进行分发,到响应的APP,就能很好的实现推送功能。由于手机APP所有的推送功能有统一的长连接和通知分发的机制,手机的运行效率不会受到特别大的影响。
而Andriod却完全不同了,虽然谷歌初期在Andriod系统中也是内置了用于推送用的服务程序,也搭建有类似于APNs的服务器,但是国内访问其服务器受限,很多手机生产厂商为了给手机减负,都把这些代码删掉了。导致现在Andriod手机只能通过与服务器长连接的方式,才能实现推送功能(当然还有其他的解决方案、由于成本和一些其他条件的限制无法落地)。还好有很多第三方的推送平台帮我们解决了一些技术难题。如极光推送。下边我们详细来说下。
先来说说没用极光推送的情况下iOS的推送原理。
下面这张图很能说明问题:
Provider一般只服务器(当然如果只是为了测试,命令行也可以),反正就是发起推送的一方,首先将要发送的消息发送给APNs,然后APNs负责将消息发送给对应的设备。设备中有内置的系统程序再把消息分发给客户端App。当然,要想完成上边的这个流程,Provider必须知道他要发送的对象是谁,唯一ID是什么?这就需要,APP在安装的时候,在APNs上注册一个唯一ID然后再把这个ID传送给Provider保存了。具体的注册过程,可以参见下图:
根据上图的逻辑我来给大家解释一下:
1.你的IOS应用需要去注册APNS消息推送功能。
2.当苹果APNS推送服收到来自你应用的注册消息就会返回一串device token给你(很重要)
3.将应用收到的device Token传给你本地的Push服务器。
4.当你需要为应用推送消息的时候,你本地的推送服务器会将消息,以及Device Token打包发送到苹果的APNS服
5.APNS再将消息推送给目的iphone
可是,Andriod就没有向APNs这样的好东西了,怎么办?好,极光推送可以解决。详细的请看下图:
Conn负责与手机端保持一个长连接,具体长连接的实现细节咱们暂且不说(通过系统时钟降低CPU消耗、利用多核优势增加链接数量什么的。具体可见博文:http://www.cnblogs.com/manuosex/p/3660727.html),我们很容易发现,其实JPush的核心实现实际上就是模仿了一个APNs。
好,既然iOS实现推送这么牛,为什么iOS还要使用jPUSh这种第三方服务呢?
答案就是:iOS这套东西配置起来太繁琐了。(具体如何能让iOS实现推送功能,可参见博文:http://blog.csdn.net/shenjie12345678/article/details/41120637)来回下载证书,上传证书就要设置半天,主要难点就是将自己的信息上传到APNs然后获得对应的唯一ID(一般叫deviceToken),所以极光推送做的其实也就是在上边说的这样一部简化了一下。直接将证书上传到极光推送网站,手机APP安装后通过和极光服务器链接,极光服务器做好响应的处理后再和APNs链接,注册好这些deviceToken,分发出来,由极光服务器转发给手机APP,手机APP再传给服务器端,下次服务器想要推送消息的时候,直接调用极光API,就会将消息发送给APNs,APNs再将消息发送给手机端。其实在某种程度上说,也只是在iOS原生的推送机制上做了一层封装,简化了配置操作而已。