Android推送原理

推送的本质

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

Android的推送实现方式

1. PULL
   应用程序开启定时的轮询，不停地向服务器请求数据
   缺点：
   a. 轮询频率过高，则太过消耗性能（CPU资源、网络流量、系统电量）轮询频率低，则数据显示不及时
   b. 依托于app
2. SMS
   服务器有新内容的时候发送一条类似短信的信令给客户端，客户端通过拦截sms消息做一些响应处理
   优点：可实现完全的实时操作，不依赖于网络
   缺点：成本相对较高，目前很难找到免费的短信发送网关来实现这种方案，只能通过运营商缴纳短信费用

推必达就是基于信令通道的电信级推送服务，可以实现在无数据网络、无wifi的情况下，实现消息传输，且无需开发者添加sdk，不过目前还没有到商用阶段

3. PUSH
   服务主动与客户端建立持久化连接并发送数据，当客户端和服务器建立连接后不再断开，这样服务器随时有新消息都可以发送给客户端

推送的解决方案

由于目前为止还未出现基于SMS可商用的推送方案，所以对比pull和push方式，明显push的方式在满足需求的情况下更省资源（CUP、网络流量、系统电量），所以以下都是基于push的方式提出的解决方案

1. FCM（Firebase Cloud Messaging）
   Android系统级别的消息推送服务-Google出品
   优点：简单、轻量级的机制，属于系统级别不易杀死，没有消息配额限制、更好的节省电量
   缺点：由于 Google 服务在大陆地区的使用很不稳定，国行 Android 手机往往会为了更好的用户体验而精简掉 Google 服务，统一推送服务也同时被去除。

Android 官方推送服务：从 C2DM 到 FCM
2010 年，在 Apple 推送通知服务发布后没多久，Android 2.2 上便推出了「云端至设备消息传递（Cloud to Device Messaging，即 C2DM）」，它的原理与 Apple 推送通知服务类似，消息从应用服务器被发送到统一服务器，然后发送到设备。
这一服务在 2012 年被「Google 云消息传递（Google Cloud Messaging，即 GCM）」替代。相比 C2DM，GCM 的 主要优点 是没有消息配额限制，且对于开发者更友好，同时能更好地节省电量。
2014 年 Google 收购 Firebase 后，将 GCM 改名为「Firebase 云消息传递（Firebase Cloud Messaging，即 FCM） 」，并 进一步简化了推送服务的相关开发工作。

2. 第三方平台
   也是如今主流的推送方式，一类是主流平台推送，一类是厂商平台推送。
   主流平台：友盟推送、个推、极光推送、信鸽推送、阿里云推送、百度推送等

以信鸽推送举例的流程原理介绍
简单说明Android客户端实现推送流程的步骤
1. 客户端App启动的时候会启动一个信鸽主Service，信鸽主Service全局唯一，一台设备共享一个信鸽主service
2. 信鸽主Service在接入信鸽的应用中随机启动一个备份的Service，2个Service互相拉活，互相备份
3. 信鸽主Service建立一个信鸽服务器的Socket长连接，并通过心跳等机制维持长连接一直存在
4. 客户端主Service通过Socket长连接请求向信鸽服务器请求Token
5. 信鸽服务器通过Socket长连接推送消息到客户端主Service
6. 主Service把Push消息转发到对应的客户端App上

厂商平台：华为推送、小米推送、vivo推送、oppo推送、魅族推送等

简单说明Android客户端实现厂商通道推送流程的步骤
1. 发送注册请求到厂商服务请求Token
2. 获取厂商的token
3. 保存厂商返回的 Token 并同步到服务器
4. 服务器将厂商生成的 Token 和账号等信息建立映射关系并保存
5. 将需要推送的内容等信息告知给服务器
6. 服务器根据 Token 关系调用厂商推送的 API ，推送消息到厂商服务器
7. 厂商服务器再推送消息到客户端 APP

优点：
a. 成本低，目前市面上大部分的推送是免费的
b. 消息到达率高，如果一个手机里有多个App使用了同一家推送服务，那么这些App将共用一条消息通道，即使你家的App推送服务被杀死了，那么只要用户打开了其他集成该推送服务的App，你家的推送就能到达用户
缺点：
a. 安全性低，别人的服务器
b. 服务会被杀死，由于Android系统的机制，后台推送Service会被各种主动的或是被动的行为给杀死，而服务一旦被杀死就意味着收不到消息了

针对缺点b而言，手机厂商的推送不存在这种情况，目前大部分厂商都是对系统都是高度定制，目的为了提供更人性化的服务或者更适合自家的硬件，那么推送服务也是，所以请记住一个潜规则：操作系统是不会杀死属于自己品牌的推送服务的。不过目前并不是所有手机厂商都有自己的推送平台，并且自家推送平台支持的自家机型也是有限的，所以目前大多数的做法就是厂商平台推送和主流推送平台结合的方式。

3. 基于主流协议搭建
   XMPP、MQTT等
   XMPP的定义（Extensible Messaging And Presence protocol）：可扩展消息与存在协议，是基于可扩展标记语言（XML）的协议，是目前主流的四种协议之一
   原理：XMPP定义三种角色，分别是客户端、服务器和网关
   客户端
   通过TCP/IP与XMPP服务器连接，然后在之上传输与即时通讯相关的指令（XML）；
   解析组织好的XML信息包
   理解消息数据类型

XMPP的核心：XML流传输协议（在网络上分片断发送XML的流协议），也是即时通讯指令的传递基础，即XMPP用TCP传的是XML流
与即时通讯相关的指令，在以前要么用2进制的形式发送（比如QQ），要么用纯文本指令加空格加参数加换行符的方式发送（比如MSN）。
XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。

服务器

监听客户端连接，并直接与客户端应用程序通信（客户端信息记录）
与其他 XMPP 服务器通信；
网关：与异构即时通信系统进行通信（异构系统包括SMS（短信），MSN，ICQ等）

通信能够在这三者的任意两个之间双向发生。

优点：

开源：可通过修改其源代码来适应我们的应用程序。

简单：XML易于解析和阅读；将复杂性从客户端转移到了服务器端

可拓展性强：继承了在XML环境中灵活的发展性，可进一步对协议进行扩展，实现更为完善的功能。

GTalk、QQ、包括google的C2DM等都用这个协议

缺点：如果将消息从服务器上推送出去，则不管消息是否成功到达客户端手机上。

xmpp是一个应用层协议，其底层依然是Socket通信。换句话说，xmpp是建立在Socket通信基础上的。socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用已实现进程在网络中通信。在设计模式中，socket其实就是一个外观模式，它把复杂的TCP/IP 协议族隐藏在了socket接口后面，对于用户来说，一组简单的接口就是全部，让socket去组织数据，以符合指定的协议。