手机消息推送方案综述

一、前言

        本文要分享的是消息推送是指手机APP被关闭或者处于后台时，还能收到消息的能力。这种消息已经广泛应用在以下场景。

IM即时通信应用，比如微信切后台了依然能收到消息。新闻资讯应用，安防APP的报警应用，比如萤石APP切后台后依然可以收到视频报警消息。等等其他应用。 二、原生消息推送

        目前移动端绝大部分都是基于两套系统，安卓和IOS。两者都有系统级的推送方式。IOS对应的是APNS，安卓对应的是FCM（之前是GCM，18年已废弃）。以APNS推送为例，消息的推送链路图2-1所示:移动端与APNS保持长连接，即使APP切后台了，推送服务端可以将消息推送到APNS服务器，APNS服务器再将消息推送到手机端。这样手机端不管装多少个app，有多少个app在后台，都只有一条长连接，但是却能收到各种消息，低功耗的同时也保障了功能性。

图2-1 APNS消息推送过程

三、国内消息推送现状 3.1 面临的挑战

        IOS和安卓在国外利用系统原生的推送机制就能满足需求（除了华为。由于贸易战，近两年部分华为手机在国外也不能使用FCM了）。但是到了国内，手机消息推送就受到了许多挑战。

        首先是IOS。如图3-1所示，APNS服务器全部在国外，所以国内的服务器向APSN推送消息的延时、带宽等就会受到很大的限制。而安卓这边就更惨了，由于众所周知的原因，FCM在国内直接无法使用。

图 3-1

3.2 解决方案 3.2.1 IOS

        由于IOS的封闭性，不管什么样的方案，都无法绕过APNS，所以IOS的推送方法相对比较纯粹。主要有以下几种。

1.推送服务直接与APNS通信

        应用的推送服务直接将消息推送到APNS，开发者自行对接APNS的API。

        缺点是推送服务器如果跟APNS服务器之间的网络不畅，可能会有性能问题。不过对小型应用来讲是够用的。

 2.推送服务建立与APNS的中间站点实现高速推送

        当推送消息比较多且频率比较高的时候，简单的推送服务器可能就难以满足需求了。此时就需要扩展推送服务器，或者将推送服务器部署到境外，建立一条消息高速通道。

         缺点是成本比较高，开发成本、维护成本以及服务器成本都比较高。适合应用已经有稳定的盈利能力且对消息推送要求较高的场景。比如微信这种IM应用。

3.使用第三方SDK

        方案1需要直接与APNS通信，开发者需要考虑各种实现细节以及处理略显复杂的网络环境，处理不好性能可能会有问题。方法2的性能较好，但是成本略高。

        集成第三方SDK的话一般会简化开发成本，拆箱即用，而且第三方服务一般会自建与APNS的高速通道，会比自己开发的推送性能更高一些，而且第三方服务一般还会提供一些有用的数据统计功能，比如消息到达率、打开率等，有利于运营自己的应用。这种方案适用于应用刚生产时能够快速迭代应用，或者对消息推送的需求比较弱，不想花费太多成本在这些功能。

        但是这种方案也有缺点：开箱即用意味着灵活性不佳，可能有一些特殊的推送需求无法满足。而且第三方服务一般免费的服务会进行限流、限制部分功能等，而且一旦出了问题由于涉及到许多方面，比较难排查。随着应用用户量的增长和功能的迭代，将会与第三方服务产生绑定，推送量一旦达到收费的阈值，成本会逐步增高。

3.2.2安卓

        安卓系统比较开放，而且厂商也比较多，所以安卓的推送方案相对来说还是比较多样的。

1.自建通道

        虽然国内FCM不可用，但是由于安卓开放性比较高，所以在市场初期的时候许多APP选择自建通道的方式来实现通信（这也是安卓初期续航不佳的原因之一）。即：APP守护一个后台服务push service，该服务始终与推送服务保持长连接。当有消息推送过来时由有台服务处理消息并展示。这种方法不经过第三方服务，相当于只是简单的客户端与服务端的通信，消息不经过第三方，安全的同时也更加自由灵活。

        但是这种方案的缺点也是明显的。首先是移动端常常是在弱网环境下，后台服务与推送服务之间的心跳保活面临很大的挑战。然后是这种实现方法非常的耗电，用户体验不加。另外随着安卓的权限控制越来越严格，而且用户对后台进程也越来越敏感，目前这种方法已经算是名存实亡了。

2.集成厂商通道

        由于FCM在国内不可用，目前比较大的手机厂商如华为、小米、oppo、vivo、魅族等都自建了自己的推送通道。比如用户用的是小米手机，那么一般使用小米推送就可以将消息推送给用户。其流程如下图所示：

        但是由于手机品牌比较多，意味着推送不同的手机需要走不同的推送通道，这会让推送服务的设计变得复杂，其交互流程如下图所示：

 

          移动端开启应用后，需要查询本机的信息并上报给服务端。当服务端需要给用户推送消息时，要查询用户使用的机器信息，然后匹配到对应的推送通道，再向该通道推送消息。由于各个厂商的API、证书、协议格式等不一样，甚至同一家厂商不同手机型号之间也会存在差异，所以维护这一套推送机制还是比较复杂的。

3.使用第三方SDK

        安卓推送使用第三方SDK的话可以很好地屏蔽掉不同厂商的差异，开发者只需要将各种厂商的认证信息上传到三方服务器的个人账户里即可，三方服务就会做好各个厂商的集成。开发者只需要关注业务本身，将消息推送给三方服务，由三方服务根据用户的特性走不同的推送通道。可以大大地减少开发成本。

 

       当然是用三方SDK也会存在一些缺点，已经在IOS推送的章节中做了讨论，此处不再赘述。

4、基于传统SMS通道完成推送

        这种方法是在有离线消息的时候发送一条短信给用户，APP在后台拦截并解析短信内容。这种方式随着安卓权限控制越来越严格，实际上也是名存实亡。但是统一推送联盟基于运营商通道进行离线消息推送，跟这种方法有着异曲同工之妙。

5、

四、第三方SDK原理

        目前做的比较好的手机推送三方SDK的厂商有极光推送、友盟推送、个推、腾讯信鸽等等许多家。各家的实现细节和功能存在小的差异，但整体上原理是大差不差的。

        根据上一章节的分析，第三方SDK的原理不言而明：主要就是集成了各种推送通道，然后向用户提供统一的推送接口，从而屏蔽不同厂商的差异性。第三方SDK不仅仅做到了这些，而且还可以进行统一的认证信息管理、推送数据分析等增值服务，可以说是对开发者非常友好了。

        除了集成各种推送通道外，三方SDK服务还会自建通道。自建通道的原理前文已有介绍，但是三方服务做自建通道相比应用开发者自己做的自建通道还是有一定优势的，原因在于自建通道在多个应用之间可以贡献。比如应用A、B、C都集成了某三方的自建通道。此时即使B和C都被强杀了，只要A的通道还处于活跃状态，那么B和C的消息依然可以通过该通道推送到手机上。这样当同一个手机安装了多个APP都集成了某一通道时，通道保活的概率就大大增强了。

五、消息推送系统技术选型

        前面分析了各种推送方案的原理和优缺点后，技术选型也就比较明朗了。

        如果产品初期比较赶工急于实现各种功能，那么选择一个靠谱的第三方SDK可以大大地减少工作量。如果产品一开始就立志高远想成为微信这样的巨无霸，不想随着推送量增长而修改方案，那么就一步到位直接自己做集成。还有一种情况是推送量虽然不大，但是推送的消息非常重要，对于安全性要求较高，此时也需要自行集成各种通道来避免信息泄露。

        总而言之，技术选项就是成本与收益的平衡。没有那种方案能够适合所有场景，选择适合自己产品的方案最重要。

六、参考实现方案

        当产品越做越大，甚至同一家公司会有多个产品，一个产品有多个版本，都需要用到手机推送业务。如果每个应用都重新设计、实现各种推送细节，就太浪费成本了。所以业界一般会开发一个统一的消息推送中间件，专注于消息推送，为各种业务提供服务，让业务与消息推送解耦，各自专注在自己的核心业务上。

        常见的推送服务具有以下特点：

【1】多点接入，可以同时接入多加第三方推送服务，多家厂商推送服务。

【2】服务端提供统一的推送接口，客户端提供统一的SDK。业务端只需要调用统一的接口即可实现推送功能。推送服务在内部根据发来的消息做具体的推送逻辑。

【3】消息持久化，方便追溯和查看。

【4】有失败重传机制，提高消息达到率。

【5】提供数据分析功能，可以分析推送的到达率，打开率等数据，方便运营和优化。

【6】提供推送配置平台，多种SDK，多种厂商，多种APP的认证信息可以统一管理。

参考的架构如下图所示:

        移动推送平台提供统一的服务，对于应用层屏蔽推送服务接口，且实现推送服务可动态轮替。推送平台将接收到的消息持久化到数据库中，方便进行消息推送失败后的重发，以及后续数据的统计分析。
        客户端 SDK 对 App 提供统一的使用接口，屏蔽推送服务 SDK 使用细节，且实现多种推送 SDK 可替换，隐藏 SDK 复杂的接入过程，方便使用。
        应用管理系统面向 App 开发人员，实现应用申请，推送服务配置，消息查询与管理，数据统计与分析。 

七、展望未来

       2018年，有政府背景的“统一推送联盟”成立了，致力于统一目前国内混乱的安卓推送现状，将各个厂商联合起来制定统一的标准规范。统一推送联盟由工信部牵头成立，主办方为工信部旗下的中国信息通信研究院泰尔终端实验室。也许在不久的将来，开发者不再为了各种不同的推送API而犯难了。

 

 

八、参考资料

【1】2021年了统一推送联盟烂尾了吗？

【2】使用Pushy进行APNs消息推送

【3】58同城高性能移动端消息推送技术架构演进之路

【4】喜马拉雅亿级用户量的离线消息推送系统架构设计实践

【5】iOS的推送服务APNs详解：设计思路、技术原理及缺陷等

【6】实践分享：如何构建一套高可用的移动端消息推送系统？

【7】统一推送联盟：OPPO 完成“推必达”能力适配