前段时间,在工信部的牵头下,「统一推送联盟」 成立。该联盟将联合多家 Android 手机厂商、互联网公司等相关企业,打造一个 Android 平台的统一推送服务 Unified Push Service(UPS),有望遏制国内 Android 生态圈的各种乱象。

对于国内广大 Android 用户来说,这是一个振奋人心的好消息。如果一切进展顺利,在不久的将来,即使是中低端的 Android 手机,也将依靠这一统一推送服务获得相当不错的使用体验。借这个机会,我来给大家简单介绍一下 Android 推送服务的前世今生。

Apple 推送通知服务

在介绍 Android 推送之前,我们先用隔壁 Apple 的推送服务来谈谈消息的统一推送。许多人选择 iPhone 而非 Android 手机,很大的一个原因是他们认为 iOS 的系统更加流畅、用久了不卡(当然根据最近的消息 iOS 会降低手机性能以延长老化电池的供电寿命)。这种流畅感要归功于 iOS 相对激进的后台进程限制,而自 2009 年发布的 iOS 3.0 上就出现的「Apple 推送通知服务(Apple Push Notification Service)」在这之中起了举足轻重的作用。

Apple 推送通知服务的推送流程
Apple 推送通知服务的推送流程

在 iOS 上,Apple 推送通知服务托管了所有应用的消息通知需求,当某一应用的开发者(服务器)需要发送一则消息通知时,这一则消息会首先发给 Apple 服务器,然后经由 Apple 推送通知服务被推送到设备。在这一过程中,设备上的应用本身没有参与。这就是我们在国内也能收到 Instagram、YouTube 等国外应用消息推送的原因了——毕竟国内有 Apple 的服务器,这一连接的质量是很有保证的。

当然,Apple 后来也把这一服务集成到自家的 macOS 上,如今的 macOS 也能享受这样的推送服务。对于一台移动设备来说,这样统一的推送服务,使得应用无需常驻后台,资源占用能很好地得到控制,所以在同等配置下能做到更加流畅、省电。

Android 官方推送服务:从 C2DM 到 FCM

然而 Android 在统一推送方面其实并没有落后太多。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) 」,并 进一步简化了推送服务的相关开发工作

Firebase 云消息传递
Firebase 云消息传递

七八年一路走来,从 C2DM 到 FCM,从 Android 2.2 到 Android 8.1,统一的推送服务一路伴随着 Android 的成长。得益于此,对于国外 Android 用户的手机来说,卡顿、费电什么的几乎没有存在过。反观国内,由于 Google 服务在大陆地区的使用很不稳定,国行 Android 手机往往会为了更好的用户体验而精简掉 Google 服务,统一推送服务也同时被去除。由此,各大第三方推送服务应运而生。

Android 第三方推送服务

首先最具良心的应该是各大手机厂商自家的推送服务,比如华为的「华为推送平台」,小米的「MiPush」等。这些推送服务被集成在各家高度定制的 Android 系统中,享有系统级地位,推送的优先级比较高。如果你的小米手机内所有的应用都使用 MiPush,那相信它也可以像 iOS 一样流畅省电。

但这往往是不可能的,开发者不可能兼顾所有的厂商,为每个牌子的手机都适配对应的推送服务,能顾上华为和小米已经是很尽力了。另外虽然厂商推送服务也可以在其它牌子的手机上正常使用,但并不能像在自家系统上一样实现系统级的推送,推送服务的后台进程依旧要常驻。

华为推送平台
华为推送平台

其次,各大互联网公司也有自己的推送服务,比如腾讯信鸽推送、百度云推送、阿里云移动推送。使用这三家公司各类 Android 应用的朋友不少都知道他们的「企鹅全家桶」「百度全家桶」和「阿里全家桶」,「全家桶效应」调侃的就是 BAT 自家应用的相互唤醒,让系统变卡变慢。你打开一个淘宝,就会唤醒闲鱼、支付宝、天猫等等应用,这种相互唤醒,目的是让共用的推送通道保持活跃,而不被系统杀死,以便消息能及时送达。

除了以上提到的两种推送服务,另外还有一种专业的第三方平台提供推送服务,比如极光推送、友盟推送等等。这种第三方平台与互联网大厂的推送服务类似,所以使用同一推送通道的应用也会有相互唤醒的情况,以保持通道的活跃。

不同的开发者在面对以上众多的推送服务时,必然会做出不同的选择,这导致我们手机上的应用所使用的推送服务五花八门,极不统一。就算抛开多个推送服务本身占用的资源不看,应用之间为了保持推送通道的活跃而互相唤醒的情况常常使得 Android 手机满载运行,手机又卡又费电也就不难理解了。

如今工信部站出来,推进 Android 统一推送,无疑具有重要的意义。一旦统一推送服务普及,我们手上的 Android 手机会变得更流畅省电,开发者也无需为了配置各种推送服务而头疼,同时还要遭受用户的抱怨。更重要的是,此举有助于培养良好的国内 Android 应用生态,并把 《Android 绿色应用公约》 推进到更大的范围。

在当前生态下使用 Android 官方推送

那么在当前的生态下,我们可以使用 Google 官方的 FCM 推送吗?当然可以。只要你的手机装有 Google 服务,并且你的应用下载自 Play Store,那么即使身处国内,你也能通过 FCM 收到消息推送。下图就是我在国内网络下收到的 YouTube 通知。

在国内网络下收到 YouTube 通知
在国内网络下收到 YouTube 通知

针对一些大量占用系统资源的国内应用,我建议你使用 「黑域」 限制它们的后台活动,并开启「允许同步」来接收消息推送(仅支持部分应用)。以微信为例,它在黑域中显示支持 FCM,所以我们在黑域中「黑域」微信并开启同步后,即使微信应用被 Standby(开启同步的应用在黑域中不会被强行停止),也能及时通过 FCM 收到消息推送。

在黑域中开启微信的「允许同步」
在黑域中开启微信的「允许同步」

当然,还是因为 Google 服务器的部署问题,FCM 在国内依旧不太稳定。希望工信部牵头的统一推送服务能尽快到来,让 Android 用户早日摆脱手机用半天就没电的窘境。