大家好，又见面了，我是你们的朋友全栈君。
文章目录
1. 基本概念
-
目的： 在用户未打开App时，App主动向用户推送服务器最新消息
-
基本原理： 服务器如何先找到设备、再找到app？
每一个设备都有一个自己的设备号，而设备中的app又都有一个唯一的包名。所以服务器只需要找到设备号与包名就可以定位到某个设备的某个应用，而这设备号与包名会一起构成一个标识符，叫做device_token，因此问题就简化为把device_token与消息内容等信息交给服务器，服务器把内容发到唯一的device_token上。 -
作用： 功能需要，如：资讯类产品的新闻推送、工具类产品的公告推送等等；活动运营需要，如：电商类产品的促销活动；召回用户 / 提高活跃度等等。
2. iOS和Android消息推送原理对比
iOS 的消息推送机制面世之时是一种全新的解决方案（堪称平台中的平台），应用本身不能有常驻的后台进程，系统的开销少，内存使用更少，电量也更少（把更多的运算和资源开销放在云端，非设备端）。而 Android 的特点，虽然开销大，优点是更稳定快速，但不明显。
（更多请参见以下文章：《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》、《Android端做消息推送有没有比较好的方案？》、《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》，以及即时通讯网精选的《推送技术好文专辑》）
2.1 iOS
2.1.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.1.2 优劣势
所以， iOS 的推送，可以不严谨的理解为：
1）苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息；
2）系统根据该 IM 消息识别告诉哪个 Apps 具体发生了什么事；
3）系统分别通知这些 Apps ；
他们带给用户的好处是实实在在的：
1）安全：只有登录过的开发者可以通过苹果的服务器推送；
2）快速、稳定、可靠：苹果掌控推送服务器和 OS ；
3）更省电；
4）让整个系统的体验更统一和简单：不会出现杀后台这种脑残事。（不用大量 Apps / Apps 的服务为了推送挂后台）。也不会出现 Apps 被杀就收不到推送这种脑残事（早一点的新浪微博 Android 版仍然如此）；
5）开发容易：当然，开发者还是要做些事情，比如维护个服务器什么的。但是复杂度无疑降低很多了。
2.2 Android
而 Android，就不同，更像是传统桌面电脑系统做法。每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。另外其实 Android 也有类似 APNS 的 GCM（Google Cloud Message），属于开发者可选，非强制。
2.2.1 基本原理
Android平台在不使用GCM的情况下就需要将自己的服务器或是第三方推送服务提供商的服务器与设备建立一条长连接，通过长连接进行推送。
开发者通过第三方推送服务提供商将信息直接下发给需要的设备，第三方推送服务提供商与设备建立一条长连接通道，并且将消息路由到APP中（图中的设备1与设备2），对于像设备3这种无网络连接或是没有成功建立长连接通道的设备，会在设备3连网且推送消息没有过期的情况下自动收到由第三方推送服务提供商推送过来的消息，保证消息不会丢失。
但是不建议自己设置服务器实现推送功能。
一是因为成本太高（开发成本、维护成本），自己搭建的服务器无论是稳定性还是速度上都比不了第三方推送服务提供商的效果；
另一个是因为自己的数据量较小，使用第三方推送服务提供商可以用他们的维度进行推送，实现精准推送。
2.2.2 优劣势
Apps 挂后台一直是 Android 引以为豪的特性，挂后台等待推送就成为技术选择；
但是，没人真正为用户的电池负责。Apps 的开发者不会站在系统层面考虑的。他会假设其他 Apps 没有那么“不自觉”；
优点在于 ，因为整个技术方案非强制， Android 的 Apps 在接收到推送后的表现更为灵活。像 Line 的 Android 版本可以在推送通知的 Popup 上直接回复， iOS 就需要越狱才能做到了。
3. Android消息推送原理
3.1 操作系统有自身的消息推送功能（系统级别）
- 系统级别：任何时候都可以推送给用户，且不会被系统杀死
- Android的消息推送服务称为：C2DM（Cloud to Device Messaging）
3.2 三种基本的推送方式：Push、Pull 和 SMS
- 本质： App将服务器更新的信息推送给用户，即App获取服务器信息，再推送给用户
- App从服务器获取最新消息的基本方式（原理）有3种：Push、Pull 和 SMS
3.2.1 轮询(Pull)方式
应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达，你必须自己实现与服务器之间的通信，例如消息排队等。
要考虑轮询的频率，如果太慢可能导致某些消息的延迟，如果太快，则会大量消耗网络带宽和电池
3.2.2持久连接(Push)方式
这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。IOS平台的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。不过刚才也讲了，这个方案存在着很多的不足之处，就是我们很难在手机上实现一个可靠的服务，目前也无法与IOS平台的推送功能相比。
3.2.3 SMS(Push)方式
在Android平台上，可以通过拦截SMS消息并且解析消息内容来了解服务器的意图，并获取其显示内容进行处理。
优势： 可以实现完全的实时操作。
劣势：成本相对比较高，需要向移动公司缴纳相应的费用。我们目前很难找到免费的短消息发送网关来实现这种方案。
3.3 七种主流的Android消息推送方式
**Original Link：**https://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378971.html
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/137297.html原文链接：https://javaforall.net
