1. Push在产品运营的作用

定期的推送，可以让更多的用户看到并使用app，对于app运营是很有效果的。可提升产品活跃度、带动功能模块使用率、带来有效的订单以及增加产品粘性、唤醒沉睡用户等。

目的： 在用户未打开App时，App主动向用户推送服务器最新消息，如下图：

服务器如何先找到设备、再找到app？

每一个设备都有一个自己的设备号，而设备中的app又都有一个唯一的包名。所以服务器只需要找到设备号与包名就可以定位到某个设备的某个应用，而这设备号与包名会一起构成一个标识符，叫做device_token，因此问题就简化为把device_token与消息内容等信息交给服务器，服务器把内容发到唯一的device_token上。

1. iOS push原理

2.1 基本原理

iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器，如下图：

iOS的推送是通过苹果自己的APNs服务进行的，用户需要将device_token以及消息内容等推送信息交给APNs服务器，剩下的均由苹果自己来完成。iOS应用的推送大部分情况下都要依赖苹果生态提供的APNs（Apple Push Notification Service）服务。如下图：

首先，作为设备标识的device-token是由APNs颁发的，App开发者或者第三方推送平台（图中的Provider）做的工作是收集这个device-token，APNs的推送是要求基于APNs颁发的device-token来推送的。只有正确的device-token会被APNs接受，如果是一个错误的、或者无效的device-token(比如App已经卸载了)，APNs就不会接受。接着，开发者使用第三方推送平台（图中的Provider）在将推送内容与范围选定之后进行推送，第三方推送平台将信息提交给APNs，剩下的操作全部都由APNs来进行完成，整个过程第三方推送平台就不能控制了。例如，腾讯QQ 的服务器（Provider）会给苹果公司对应的服务器（APNs）发出通知，然后再中转传送到你的设备（Devices）之上。当你接收到通知，打开应用，才开始从腾讯服务器接收数据，跟你之前看到通知里内容一样，但却是经由两个不同的通道而来。

2.2优劣势分析

iOS 的推送，可以不严谨的理解为：
1）苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息；
2）系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事；
3）系统分别通知这些 Apps 。

优点：他们带给用户的好处是实实在在的：
1）安全：只有登录过的开发者可以通过苹果的服务器推送；
2）快速、稳定、可靠：苹果掌控推送服务器和 OS ；
3）更省电；
4）让整个系统的体验更统一和简单：不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）；
5）开发容易：当然，开发者还是要做些事情，比如维护个服务器什么的。但是复杂度无疑降低很多了。

缺点：既然iOS实现推送这么牛，为什么iOS还要使用jPush这种第三方服务呢?答案就是：iOS这套东西配置起来太繁琐了。（具体如何能让iOS实现推送功能，可参见博文：iOS 开发之实现 App 消息推送（最新）_HelloWord杰少的博客-CSDN博客_app消息推送）来回下载证书，上传证书就要设置半天，主要难点就是将自己的信息上传到APNs然后获得对应的唯一ID（一般叫deviceToken），

1. Android push原理

Andriod与iOS完全不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。虽然谷歌初期在Andriod系统中也是内置了用于推送用的服务程序，也搭建有类似于APNs的服务器，但是国内访问其服务器受限，很多手机生产厂商为了给手机减负，都把这些代码删掉了。导致现在Andriod手机只能通过与服务器长连接的方式，才能实现推送功能（当然还有其他的解决方案、由于成本和一些其他条件的限制无法落地）。还好有很多第三方的推送平台帮我们解决了一些技术难题。如极光推送。下边我们详细来说下。

3.1基本原理

Android平台在不使用GCM的情况下就需要将自己的服务器或是第三方推送服务提供商的服务器与设备建立一条长连接，通过长连接进行推送。如下图：

开发者通过第三方推送服务提供商将信息直接下发给需要的设备，第三方推送服务提供商与设备建立一条长连接通道，并且将消息路由到APP中（图中的设备1与设备2），对于像设备3这种无网络连接或是没有成功建立长连接通道的设备，会在设备3连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息，保证消息不会丢失。但是不建议自己设置服务器实现推送功能。一是因为成本太高（开发成本、维护成本），自己搭建的服务器无论是稳定性还是速度上都比不了第三方推送服务提供商的效果；另一个是因为自己的数据量较小，使用第三方推送服务提供商可以用他们的维度进行推送，实现精准推送。

3.2 优劣势分析

Apps 挂后台一直是 Android 引以为豪的特性，挂后台等待推送就成为技术选择；但是，没人真正为用户的电池负责。Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”。

优点在于 ，因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。

1. Android消息推送原理

4.1 操作系统有自身的消息推送功能（系统级别）

系统级别：任何时候都可以推送给用户，且不会被系统杀死

Android的消息推送服务称为：C2DM（Cloud to Device Messaging）

4.2 三种基本推送方式

本质： App将服务器更新的信息推送给用户，即App获取服务器信息，再推送给用户

App从服务器获取最新消息的基本方式（原理）有3种：Push、Pull 和 SMS，如图5

4.2.1 轮询(Pull)方式

应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达，你必须自己实现与服务器之间的通信，例如消息排队等。

要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池

4.2.2持久连接(Push)方式

这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。IOS平台的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。不过刚才也讲了，这个方案存在着很多的不足之处，就是我们很难在手机上实现一个可靠的服务，目前也无法与IOS平台的推送功能相比。

4.2.3 SMS(Push)方式

在Android平台上，可以通过拦截SMS消息并且解析消息内容来了解服务器的意图，并获取其显示内容进行处理。

优势： 可以实现完全的实时操作。
劣势：成本相对比较高，需要向移动公司缴纳相应的费用。我们目前很难找到免费的短消息发送网关来实现这种方案。

4.3 七种主流的Android消息推送方式

Original Link：Android实现推送方式解决方案 - Healtheon - 博客园

如图6

1. 极光push介绍

打开APP后注册极光ID，实现极光id和设备id的绑定。 注册登录的时候，实现userID，极光ID，设备id的绑定对应关系。一个userID可以绑定多个APP，退出产生解绑极光推。直接将证书上传到极光推送网站，手机APP安装后通过和极光服务器链接，极光服务器做好响应的处理后再和APNs链接，注册好这些deviceToken，分发出来，由极光服务器转发给手机APP，手机APP再传给服务器端，下次服务器想要推送消息的时候，直接调用极光API，就会将消息发送给APNs，APNs再将消息发送给手机端。其实在某种程度上说，也只是在iOS原生的推送机制上做了一层封装，简化了配置操作而已。如果APP离线，极光后台会把push推送发给厂商，由厂商代发。

更多信息参考极光官网：极光

1. 厂商push介绍

厂商push的解决方案类似于苹果的解决方案。由于厂商系统的优越性，华为push还支持基于LBS的电子围栏的推送，我们可以想象一下这个场景，如果你走入了一个商场，这个商场里正好有一个物美超市，恰巧你的手机上安装了多点APP，然后你会收到多点APP的push，push信息里说“尊敬的会员：您好，今天小龙虾半价，戳我领优惠券”，是不是感觉会更好？

更多信息参考：推送服务

参考文档：

1. https://blog.csdn.net/cyjbenyy/article/details/89676217?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight
2. 推送服务