统一推送联盟的成立对我们来说有哪些益处
不少人之所以不喜欢 Android 手机,热衷于 iOS,有一个原因是 Android 手机刚刚到手的时候挺好用,干什么都非常丝滑、流畅,但是只要用的时间一长、装的 App 一多,手机就变得卡顿了,续航就变差了。
很多媒体为了大多数人能够看懂文章,他们统一地将 Android 手机这种越用越卡,越用续航越差的问题归结给了后台程序。
如果是在很多年前那个 Android 4.x、Android 5.x 是主流的时候,确实 Android 手机的很多卡顿、掉电过快的问题是后台程序引起的,当时的 Android 并不能妥善地管理 App 在后台运行的服务,App 都非常流氓地在前台退出之后仍然保留了进程或者一些服务在后台,同时他们还会被频繁地自启,所以引起了这样的问题。
但是,不论是 Android 本身,还是国产定制的各种 UI,它们都是在进步的,目前来说只要你用的不是原生/类原生的 Android,即你使用的是国产的 MIUI、EMUI、Flyme 这样的深度定制 Android,且版本是 Android 8.x 及以上,App 的流氓行为实际上已经能得到非常合理的管控,你的后台平时并没有你想象的那么多进程或服务驻留。
这是因为在这些更加「现代」的 Android 里,App 的自启动、在后台的行为、唤醒其他 App 的能力都被非常严格地限制了,尤其是在国内几个大厂出品的定制 Android 里。
但是你还是能发现,现在的 Android 手机仍然存在着 App 安装一多,手机的续航还是会有一些下降,这是为什么呢?
说好的 App 在后台已经非常受限了呢?
我们都知道,Android 是 Google 旗下的产品,虽然它原本是一个开源项目,但是由于它是 Google 旗下的,所以 Android 本身有一些功能是需要依托于 Google 的服务才能正常运行的。
比如说,FCM。
FCM 的全称是 Firebase Cloud Messaging,其前身是 Google Cloud Messaging。它是一个内置在 Android 系统中的消息推送服务,它会一直运行在后台,帮你手机内的各个应用程序接收来自服务器推送的消息。
通常而言,需要实时呈现到用户眼前的消息就需要这样的推送服务,例如微信、QQ 这些即时通讯工具的新消息,以及微博、知乎等这些社交平台各种各样的通知、头条等资讯 App 给你推送的最新新闻等等。
当然,也有广告。
这些消息都是由服务器主动推送给用户的,他们需要借助这样的消息推送服务才能及时地把这些消息推送到用户的眼前,让用户可以实时地接收到这些 App 上的新消息。
对于开发者来说,他们要做的就是让自己的 App 接入这一套推送服务,由于 Google 在 Android 内就提供了这样的东西,开发者想要做消息推送自然是非常省事的。
然而,因为众所周知的原因,国内的用户并不能使用这一套 FCM 服务。这就尴尬了,没了这个系统级的消息推送服务,想要实现消息推送,那就得靠程序员们自己另起炉灶。
这个时候,有的 App 为了能够让用户及时地接收到服务器推送过来的消息,便在后台长期驻留,或是频繁地、周期性地自启,确保能够及时收到服务器推送过来的新消息并呈现给用户。
所以 App 一多,这手机不就开始卡了、开始掉电快了吗。
隔壁的 iPhone 由于系统是 iOS,苹果在 iOS 里做的那一套消息推送机制在国内是完全可用的,而且很重要的是苹果强制要求开发者使用这一套消息推送服务,否则这个 App 进不了苹果的生态,在这种情况下,iOS 的用户和开发者都不会遇到 Android 这类消息推送上的尴尬问题。
前文笔者有说到过,现在的 Android 对于程序后台的限制越来越严格,常驻后台以及频繁的、周期性的自启等接收消息推送的方式在今天已经不太给力了。
因为系统可能会随时把 App 的进程砍掉,或者禁止 App 的自启,这样一来,服务器推送过来消息,但 App 却接不到,那用户就不能及时地查收一些新消息了。
于是在国内,App 的消息推送逐渐分成了三派。
第一派是「土豪派」,这类厂商有钱,他们愿意花成本打造自己的消息推送渠道,例如腾讯。微信、QQ 这类应用便用的是他们自己的消息推送渠道,由于自己的渠道是 100% 可控的,所以他们可以最及时地向用户呈现新消息。对于即时通讯工具来说,这是非常重要的。
但是既然要实现消息推送,那么后台必定还是要驻留一个推送服务的,由于微信、QQ 这类应用用户量很大,所以手机厂商们基本上都在自家的定制系统里把这些 App 放进了白名单,允许它们的服务在后台长期驻留,以保证消息的推送。
这一类消息推送渠道在设计上就考虑过了手机的续航等问题,所以它对资源、对电量的消耗都是比较低的,一般来说这样的服务工作一天消耗的电量不会超过 5%。
第二派是「厂商派」,为了解决消息推送的问题,小米、华为这些出货量大的厂商在自己的定制 UI 里做了一套替代 Android 原生 FCM 的解决方案,在小米那这叫 MiPush,华为那这叫 HMS Agent,OPPO、vivo、魅族也都做了自己的消息推送平台。
这样的消息推送平台好是好,因为它和 FCM 一样,它有专门的服务器将来自各个应用的信息中转到用户手机上,用户手机的后台只需要运行这一个推送服务,就能收到无数应用的推送消息。
然而,Android 到目前都还是严重碎片化的,小米、华为、OPPO、vivo 等厂商每年手机的出货量都不小,这意味着开发者要是想调用这些厂商推出的系统级消息推送方案,那么他们需要接入非常多的 SDK,导致应用臃肿,后续的维护升级上也变得不那么便利。
显然厂商们考虑到了这一点,以小米的 MiPush 为例,开发者在接入之后,不单单搭载 MIUI 的手机可以收到消息推送,搭载其他深度定制 ROM 的 Android 手机一样可以。
可是要知道,其他厂商可并没有把 MiPush 内置到系统里,这意味着在非 MIUI 手机上,MiPush 只能用传统的后台保留服务的方式实现消息推送。
对于开发者来说,他们多数会只选择接入一家更易开发或用的人更多的推送平台。但是问题在于,不是所有的 App 都在用统一的推送服务,所以一些应用仍然还是会挂着一个后台服务进程接收消息,应用一多,该卡顿还是卡顿,还掉电还是掉电。
第三派是「第三方派」,有的个人开发者没有足够的精力给自己的 App 做消息推送,对他们来说,最方便的做法接入一个分享、消息推送等功能都有的 SDK,例如友盟。
这类 SDK 虽然能给开发者带来很大的便利,但是它们对用户并不是很友好。往往应用了这类 SDK 的 App 会相互唤醒其他应用了同个 SDK 的 App,由于他们并没有直接地得到各种手机厂商的支持,所以这类 SDK 的后台服务是很容易被杀的。
为了保证它们能够顺利进行消息推送,通常这些 SDK 会采用一些相对「流氓」一些的做法,例如利用多个系统广播机制疯狂地重启后台服务等,由于这类 SDK 接入的 App 多,所以他们的后台服务基本上能够保证在后台的常驻。
和厂商派一样,这类 SDK 市面上也有不少,用户安装的 App 数量一多,最终堆积在用户手机后台的推送服务也就会变多,进而带来对电量、对手机资源的消耗。
由于这类推送服务比较「顽固」,以至于它对你手机带来的影响可能会比前两派还要大一些,尤其是应用间的相互唤醒。
所以,归根结底,消息推送服务这个问题迟迟困扰着国内的 Android 用户,就是因为 Google 本身的 FCM 在国内不能使用,各家自起炉灶,最终把用户的手机弄得一团糟。
解铃还须系铃人,这么一个乱摊子还是该收拾一下的,于是乎,统一推送联盟成立了。
这是一个由工信部指导、挂靠电信终端产业协会的联盟,这个联盟存在的意义是彻底解决 Android 消息推送的乱象,给开发者带来最大的便利,同时还用户一个干净的体验。
有统一推送联盟开发的统一推送服务是目前 Android 消息推送的最佳解决方案,它也将得到加入的厂商,如小米、华为、OPPO、vivo、一加、魅族等几乎所有国内你能叫出名字的厂商的支持。
这意味着这个统一推送服务将会在标准确立、正式投入使用后在几乎所有国产定制 ROM 里取代 Google FCM 以及厂商自起炉灶建的消息推送服务,成为手机系统内唯一的系统级消息推送渠道。
由于各家厂商这一回用的是同一套服务,所以 MiPush 那样的尴尬情况不会再出现,在几乎所有的国产手机上,App 都能用上这一套系统级的消息推送服务,因为消息推送产生的手机顿卡、掉电都将不复存在。
统一推送联盟其实早在 2017 年 10 月就成立了,但是一年多来这个联盟一直都没什么动静,Android 的大版本都改了,各家的定制 ROM 都经历了不知道多少次的迭代,当年说好的统一推送服务至今还没个踪影。
不过,在 2019 年,这件事终于是有了个盼头。
统一推送联盟终于是公布了统一推送的时间表,在今年的 3 月 1 日,联盟会就统一推送的标准进行测试,而在今年年底,所有的国内厂商都会上线这个统一的推送服务,各家现有的推送业务也将兼容这一套标准。
届时,在国内的 Android 手机上,至少消息推送这么一个问题是得到了一个非常好的解决。
除了统一推送外,统一推送联盟还提出了 Android 绿色应用公约,这个公约对 App 提出了比较严格的权限、行为方面的要求。关于这个绿色公约到底怎么确保 App 的绿色,受限于本文的篇幅,这个我们之后文章再说。
Android 碎片化这个问题虽然难以解决,但是像是推送、链式启动这种在软件层可以限制住的、可以通过达成共识解决的问题,最终还是可以解决的。
对于开发者来说这是一种解放,对于用户来说这也是一种解放。在新春能看到这样的消息,也是颇让人开心的。