从极光推送的实现原理概括iOS和Andriod推送原理
因为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原生的推送机制上做了一层封装，简化了配置操作而已。