在往期图文中，我（@Anm718）作了对Android系统后台机制的介绍。有个与后台机制关系密切的系统，就是推送系统，在那篇文章中没有详细提及，酷友在评论区中引起了讨论。 本期图文，将会介绍推送系统的工作原理，及推送服务的现状。
　　本文通篇讲人话，篇幅略长，但简单易懂。文章共7.7k字，自行准备充足的时间进行阅读

目录：
-推送的定义：推送形式，目的，运行方式。

-集中推送：系统级推送（FCM，APNs），第三方推送。

-推送服务的发展状况：统一推送联盟，推必达系统。

-附加篇：介绍FCM

一、推送的定义

Ⅰ. 推送形式：

　　推送有多种表现方式，通常是“通知”的形式

　　应用在通知栏里推出一条信息，即是通知。这种通知每个用户都见过，而且一天要见不少次吧。非常标准的通知形式，是本文重点介绍的推送方式。

------

Ⅱ. 推送系统的目的：

　　推送系统是一套庞大且复杂的系统，它被开发的目的是什么，做哪些服务，什么地方可以用到，是第一个问题。 分析一下用到推送的应用吧。

-1 资讯类。隔一段时间，推送较新的信息给用户，如 【今日头条】 ，以及各种带有资讯推送的国产浏览器。部分查天气的软件也类似。

-2 实时通讯类(IM)。为用户实时推送最新消息，如 【微信】 ，line，米聊，tg。

-3 游戏类。以随醒随推和定时推送为主。在各种联网手游中普遍存在。

-4 广告类。要恰饭的嘛。在部分定制系统的预装应用中较为常见，如MIUI。和一些广告收益较大的应用，以及各种应用市场。

Ⅲ. 推送系统的运行方式：

　　推送系统的目标已经明确，那么接下来就要实现目标，分别需要哪几种运行方式。

① pull，拉取法（轮询）。
　　用户的客户端，通过互联网连接软件的服务器，向服务器索取数据，拿到数据后通过通知等形式推送出来。适用于对消息的实时性不敏感的环境，只需要大概较新的信息即可，比如上文的资讯类应用。

优点是实现便捷，因为服务器是固定的，不可能自己跑掉，所以客户端只要知道了服务器的地址，联网时就能随时拉取信息。缺点就是消息延迟，延迟大小由客户端拉取频率决定。

② 本地推送（定时）
　　这种推送比较特殊，因为它是「离线」运行的，不需要联网。软件设下定时任务，在到达指定时间时，会自动推出通知消息。常用于一些与时间关联的游戏，比如崩坏3。还有闹钟类应用也是如此。因为它们是对应时间点，而不是时间段，所以不会因关机造成通知时间偏差。（如果是关机时漏掉了通知，那真没办法了）

③ SMS推送
　　相当于短信，在无IP网络的时候可以使用。但并不相当于完全离线，需要有运营商的信号📶，能收到短信才能使用。一般互联网平台不使用此种推送，因为价格略高一点。
　　

④ push，推送法（长连接）
　　前面讲的几种情形可能很多用户都没在意，但接下来的内容可能与很多人息息相关。

　　❗这里是重点内容❗

　　在连接网络的情况下，由客户端 向目标服务器发起连接请求，通过TCP建立“客户端-服务器”的持久连接，始终保持连接状态。此时由服务器通过连接，向客户端推送数据，客户端只负责接受数据，并推送通知到用户的设备。主动方在服务器，无需客户端自行拉取数据，消息及时性可以保证。

理论上来讲，过程应该如上图所示，但实际情况要复杂很多。
　　首先，服务器的位置不会变动，但客户端可是经常性变动的。抛开地理上的位置变动不谈，IP地址也是动态的。

--此处涉及一个知识，【Nat转发】，举个栗子🌰：家中的入户宽带是一根线，代表了一个IP，通常家中有多台设备需要上网，那么就需要路由器作为Nat节点，分出多条线路，给下面的每台设备都分配一个IP，此IP在自动分配下为动态地址，会出现变动。--家庭网络之上，宽带提供商可能在一个地区布置多次Nat转发，客户端可能要经过七八层转发才能连接到服务器。IP地址可能经常变换。

　　由此可知，维持一个长连接，层层的Nat是头号大敌。客户端都在内网中，在Nat点上很容易被断掉。Nat节点会自动清理空连接，想避免被清理，就要保持数据传输，就有了对应技术【心跳】💗。

--心跳：由客户端向服务器发送一个心跳包，服务器收到后传回一个应答，客户端收到应答，即一次完整心跳过程。用于保持长连接不被清理，以及判断连接是否中断。

　　为什么是由客户端发出心跳包呢？还是上面的Nat转发，客户端都在内网，服务器是没法主动连上的；服务器是完整暴露在公网，可由客户端直接连接。心跳以小包、高频为原则，小包是为降低流量消耗，高频是为保持连接。

二、集中推送服务

　　分析完推送服务的运行方式，大家能明白推送服务的问题了。如果每个应用都维持着一个长连接，无数应用在后台，那么结果是不堪设想的。而且很多小型软件公司，资本与技术 不足以维护一个长连接的推送服务器。为解决问题，集中推送服务应运而生。

--集中推送：多个应用使用同一项推送服务，只需这个集中推送服务在运行，那么这几个应用都可以正常推送。为保证消息的及时，集中推送采用的方案均为『push推送法』。

　　集中推送服务可分为两类：

　　1.系统级推送，由系统开发者提供的推送服务，集成于系统中，最稳定，最便捷。

　　2.第三方推送，由非开发系统的公司提供的推送平台，需要软件自行携带，功能更丰富。

------

Ⅰ. 系统级推送

　　① 财力雄厚、快速发展的谷歌推送。

　　Android系统的开发者，Google提供了两套推送系统（c2dm未正式广泛使用，就不提了）。

--Google Cloud Messaging（GCM），Google云端消息推送。于2012年发布，可用于向安装有Google服务框架的安卓设备推送信息。

--Firebase Cloud Messaging（FCM），Firebase 云信息传递。2014年，Google收购Firebase。2016年，Firebase推出FCM，取代了GCM。FCM可向Android、iOS、Web设备推送通知，实现数据跨平台（当然主要还是在Android）。
　　FCM一开始是向下兼容的，也就是说支持GCM的应用可以直接走FCM的通道。直至2018年Google弃用了GCM，2019年才彻底关闭了GCM，所有应用推送一律使用FCM。
　　FCM的优势相当明显，免费、稳定、跨平台，速率大，向同一设备推消息最高可达5000条/小时。

------

　　② 因iOS系统而诞生的推送服务：Apple Push Notification Service（APNs）

　　Apple🍎公司于2007年发布了iOS系统，因系统的推送问题，紧接着在2009年推出了APNs，可以说APNs就是为了iOS服务的。这体现了Apple对iOS的重视，也彰显了一种敢为人先的品质，开创了云服务集中推送的先河。直至如今，APNs仍然以“技术成熟、涵盖范围广、简洁易用”的优点成为行业的旗舰，许多推送服务都是向它看齐。

　　相对于Google的FCM，APNs的承载量就有些逊色了，支持最大单包大小就小了数倍

------

　　③ 成功，or败北？：Windows Push

　　Microsoft发布过一套推送系统，Microsoft Push Notification Service（MPNS），提供给Windows Phone 8平台的应用程序使用。2011年，又发布了Windows Push Notification Service（WNS），为win 8和Windows Phone 8.1服务，同时取代了MPNS。本文Anm718原创，
　　2015年，Microsoft将WNS扩展至Universal Windows Platform（uwp），并将win 10、win 10 mobile、xbox平台纳入推送支持。另外Microsoft似乎不允许开发者使用GCM替代WNS使用。
　　说到uwp，各位可能已经猜到了这个系统的结局。在Windows那残缺的生态下，最终WNS也没成气候，就当作win开发者的备选推送系统了。不过尽管如此，Microsoft还是始终尽心尽力地维护着这套推送系统，稳定性是可以保证的，实际效果也还不错。

----------

Ⅱ. 第三方推送

　　第三方推送再细分，还可以分为两类：手机厂商的推送服务，和推送平台。

--厂商推送：由手机厂商维护，只集成于「自家」的定制安卓系统上，「数据不跨平台 不互通」。
　　国内有MiPush（小米），华为推送服务（华为、荣耀），OPPO推送平台（OPPO、OnePlus），vivo消息推送（vivo），魅族消息推送（魅族）。

--推送平台：由专业负责推送系统的公司或部门维护，提供开放接口，应用可自由接入，「可跨平台，数据仅推送服务内部互通」。
　　主要有信鸽（腾讯），百度云推送（百度），阿里云推送（阿里），jpush（极光），umeng（友盟），igexin（个推）。

三.推送服务的现状

Ⅰ. 实现易，优化难

　　读到这里，大家可能也都发现了事情的不对。“集中推送服务”看似解决了推送到达的问题，实际又引发了新的问题，就是「推送平台」复杂且混乱。

　　理想状态下，app全部使用系统级推送，那么应用不留后台进程，消息推送高效，设备运行流畅。然而事实上有许多app不接入系统级推送，而是自己轮询或建立长连接。轮询还好一些，隔一段时间活动一次，对设备影响感知不强；长连接的话问题就很大了！

　　如果app不使用系统级推送，自建长连接，就需要持久运行在后台，建立进程保持自己推送服务运行；而几个应用使用了同一第三方推送服务，则会出现“链式启动”。应用疯狂建立后台常驻，耗电吃流量，使得用户苦不堪言，于是开启了一场用户、系统与软件之间的战争。这方面涉及系统后台管理，想详细了解的可以看我上一篇图文 查看链接 。

---------

Ⅱ. 统一推送联盟

　　为解决第三方推送的种种乱象，中国移动互联网企业的一些先进部门，于2017年10月成立统一推送联盟，试图通过建立统一的标准，改善中国大陆安卓用户的推送使用体验。此联盟的关键在于手机厂商。

　　截止到2020年8月，支持统一推送标准的📱品牌有{小米，红米，OPPO，vivo，iqoo，真我realme，中兴，三星，一加，坚果}。计划支持的品牌有{华为，荣耀}。不支持统一推送的品牌有{魅族，联想，努比亚，索尼}。目前统一推送仍在开发适配中，等到稳定后，可由各厂商推送逐步过渡到统一推送。

　　如此华丽的阵容，能看出希望安卓生态进步的人应该是多数的。各项适配工作还在紧锣密鼓地开展着，统一推送联盟应该是最有希望彻底改善安卓生态的方案，毕竟有影响力的互联网企业、组织基本都加入了，如果这都办不成事，那真就彻底无望了。

----------

Ⅲ. 推必达

　　统一推送联盟还提议了一项服务，名为推必达。这是何等的自信，取这样的名字？这就要提到他的技术了。参考上文 一.Ⅲ.③，SMS推送。

　　推必达与 移动、联通、电信 运营商合作，通过短信类似的通道，实现无需WiFi、移动网络的环境下推送。在偏远、地下地区，2g网络覆盖的环境，也一样能收到推送的通知。而且此通知与普通push实现的功能一样，也可以拉起应用。甚至将应用卸载后，不影响接收通知。

　　不过这项推送服务的费用肯定相对「昂贵」一些，而且要和通讯运营商合作，更麻烦。所以「不会」大规模使用。

----------------

Ⅳ. app不接入推送服务

　　尽管集中推送服务有那么多好处，但许多app还是不接入，而是自己轮询、长连接。这是什么原因呢？企业的发展依赖客户，不可能“故意损害用户体验”。那么我从以下几个角度具体分析。

1. 安全性。接入集中推送，那么说明你推送信息必然要经过对方的服务器。推送平台的隐私策略如何，数据加密的强度都有待考量。如果推送平台出现安全漏洞，那么可能导致用户的信息泄露；或者推送平台的管理人员有内鬼👻，窃取了用户的数据。这些都是安全性的问题。

2. 稳定性。推送的根本目的是 让用户收到推送通知。使用集中推送，那么推送的信息就要先到推送服务器，再到客户端。在网络中，数据包传输跳转越多，丢包的几率越大；更别说有些难以解决的玄学问题了。而且平台稳定性也很关键，有时推送平台抽风，那么使用此平台的应用推送全部瘫痪。比如“酷安”接入了mipush，一旦mipush失效，酷安就完全没法推送信息（上半年发生过一次，我还以为是酷安的优化问题）。

所以大型app通常会准备两套系统，自己的长连接服务器，和一套集中推送。推送平台崩溃了，app自建长连接能正常推送（但需要留后台）。还有极端情况，就是一个推送平台也不接入，只走自己的通道，腾讯有信鸽推送，但自家的QQ、微信都不接入，就是想做到最大的稳定性。

图为tg的设置界面，可以控制是否留后台服务，开启后可在没有FCM、但能连接tg服务器的环境推送信息。这就是既接推送平台，又有自己推送通道的代表。

3. 经济原因。推送服务也是要赚钱的，像Google那样免费开放给所有人的服务毕竟是少数（带善人）。目前低收费的推送服务有极光，mipush，阿里云推送，这几家是小型app 常用的推送平台了，比如酷安。可以理解，毕竟酷安的土豆服务器嘛。友盟、个推我没有查到大致收费，不过用的app不少，应该不会高。

但我也有一点疑问，为什么那么多应用接这接那，free的FCM不知道接入呢？又亏不了你的。

三年之期已过，推送服务呢？广告倒是接了不少。。

现在推送有多拉跨还不知道吗？消息不推送不说，时不时收到十天半月前的消息就十分离谱。咱现在也是国内安卓玩机、数码科技的高度知名论坛了，开发的app连个推送都做不好，不觉得尴尬吗。

特别篇：简单介绍FCM (・∀・)

　　FCM是谷歌的推送，是Android系统最正统的推送服务，也是开发Android App所接入的重要组件。

　　它集成在Google服务框架中，应用名为“Google Play 服务”，包名为“com .google .android .gms”。有着自己的日志界面，安卓手机可以在拨号盘中输入*#*#426#*#*即可调出FCM界面，大概是下面这个样子（受制于篇幅，把注释都放在图片里吧）

如果没有拨号器，比如虚拟系统、平板电脑等设备，可以用 【创建快捷方式】 ，点击右上角的菜单，将“搜索活动列表”和“显示系统应用”勾上，搜索gcm，也可以打开FCM诊断界面。

　　🛑FCM的工作是完全正常的，没有被屏蔽。但根据一些酷友的反馈，他们的FCM无法连接，或是需要hosts。我没遇见过这样的情况，可能与地区/运营商有关？沿海地区或许成功率高。山东移动，WiFi和移动数据，连网后FCM自动秒连。有特殊情况的，可以考虑评论区交流，或许统计数据量足够大，就能分析出问题所在了呢。

　　当连接上FCM后，打开诊断界面是这个样子的 （注释在图中）

看完连接状态，点击events按键，进入“记录”界面。

　　如果你的消息很少，频率很低，那么展现在眼前的应该都是这句话

FCM使用长连接作为推送方式，心跳肯定是不可或缺的。开头的数字代表着心跳的时间点，相邻两时间点的差为心跳的间隔。可以看出这台设备的间隔为29分钟。这个间隔越大越好（在不断开的前提下），因为心跳过于频繁会导致耗电上升📈。请避免使用ss等proxy，会导致心跳断线，Google服务不断重连。

　　接下来看一组FCM通道推送记录：

非常标准的推送步骤呢，实测消息也基本没有延迟。下面几组推送也是如此

　
　　🛑不过有一点要注意：如果应用被用户手动「强行停止」，那么是收不到FCM推送的。Google认为应用被用户停止，是用户用不到这个应用了，就不会让他发通知打扰用户。

----------

微信的FCM

　　又到了喜闻乐见的评测应用环节，有请我们的常客-微信 。大家都知道，微信的play版是接入了FCM的，有很多人为此好一番折腾，就为了让微信保持后台纯净，降低耗电，想尽办法让它走FCM。然而从7.0.12开始，却发现微信怎么都不走FCM了。

　　原因很简单，wechat加入了IP地址检测机制，并屏蔽了来自大陆地区的FCM连接。已知目前大陆直连微信，FCM不会有任何推送，也不会被诊断界面所记录。那么我尝试着，给他一个全局的海外网络，能否成功进行FCM推送。

-测试条件：微信，版本7.0.16，play商店全新安装；IP地址为TaiW，接管网络所有协议，无法绕过。

　　先登录微信帐号，接着在后台管理界面划掉微信的卡片，此时微信没有后台服务了。从另一个客户端发来信息，结果如下：

此时成功的收到了推送信息，过程也被FCM诊断界面记录下来。但延迟非常的高，界面显示为2s，但实际延迟七八秒（从按下发送键 到 通知消息弹出）。这个延迟引人深思啊😯 越想越不对，不行，要找原因！于是有了下图

前面提到，微信已经被清掉了后台，结果此时出现了微信的后台服务 打开微信时，没有那个加载界面，而是直接进入了主界面。

看来是微信通过FCM来拉起后台进程，再由进程和服务器建立连接，然后推送通知消息。相当于微信借助FCM来保活，根本不是走FCM服务器推消息！到头来还是微信自己在后台运行。

　　这是何等的鬼才啊，先是借FCM保活，又是屏蔽大陆IP。就好像在说：“别去折腾FCM了，全部木大，乖乖留好后台吧。”看样子真的教不会那个男人做微信了。

挺好奇怎么做到安装才十分钟，存储占用到1g的。

----------------

文章结尾

　　目前最需要推送的应用-微信，却没有接入推送平台。腾讯也是统一推送联盟的成员，为什么不去接入推送呢？这个问题我仔细思考过，想到「应用体量」这个概念。目前微信的用户量和日活跃都是一个难以想象的高度，没有第二个应用能做到如此。即便真有推送平台想接下微信的推送，还要掂量一下自己的推送服务器，能否承载这庞大的数据。
然后是到达率，哪怕有99.9%的到达率，剩下那一点也是数十万。所以，不要太急于求成，Android系统在越发完善，随着时间的推移，微信等应用会适配好推送服务，否则在Android迭代优化下，它是撑不住的。
　　
　　关于本文，我尝试了用修改过的排版来写，着力对大屏设备优化阅读体验。对那些用着小屏幕设备的读者，体验或许不太好，毕竟酷安没法自动排版。对，都怪酷安
　　原本打算6k字完结的，结果发现内容缺失，我也没精力再写一篇文章发，干脆一股劲，把所有内容全怼上去了。写到快9k字，太长了没人愿看，又砍了1k字（我太难
支持我的文章，麻烦 点赞、评论、收藏，更高的热度可以让更多的人看到。感谢你的支持

版权相关：本文可自由转载，需注明原作者Anm718。如转载到无法被搜索引擎直接抓取的平台（如头条、公众号），请在（酷安原文的）评论区或私信中告知（ 原作者 ）。

文章的消息来源和参考资料（From：https://www.coolapk.com/feed/21270390）
维基FCM： https://zh.wikipedia.org/zh/Firebase
维基APNs： https://zh.wikipedia.org/wiki/Apple推播通知服務
FCM官网介绍： https://firebase.google.com/docs/cloud-messaging
wns官网介绍： https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview
推必达官网： http://www.chinatuibida.com/
统一推送联盟官网： http://www.chinaupa.com/
极光推送官方简介： http://docs.jiguang.cn/jpush/guideline/intro/ （貌似被屏蔽了？）
接入SDK分析（可了解接入推送）： http://tool.bchun.com/#/

本文全文转载自酷安@Anm718，仅做部分排版调整和必要修改

原文地址：https://www.coolapk.com/feed/21190394 （需使用酷安APP查看）