Android P正式版即将到来：后台应用保活、消息推送的真正噩梦

1、前言

对于广大Android开发者来说，Android O（即Android 8.0）还没玩热，Andriod P（即Andriod 9.0）又要来了。



下图为谷歌官方公布的Android P的2018年发布路线图：


Android P的最后一个开发者预览版（即DP5）已如期发布于2018年7月26日，根据上面这张发布路线图，相信Android P的正式版将很快到来。对于Andriod开发者来说，不管Andriod P有多少新功能或者特性（反正“我”用iPhone啊，哈哈），是否影响“我”撸的APP的运行才是最要紧的事。

自从Andriod 6.0以来，Android系统在省电管理这方面做的越来越好，对于开发者来说限制也越来越多，也直接导致了各种保活黑科技群魔乱舞（别笑，就的就是“你”！）。但Android P官方公开的开发者资料来看，此版加入或强化的多项设备电量管理新特性，使得需要后台消息推送、应用保活的APP变的越来越困难，黑科技恐将成为历史。

2、原先的APP为什么要搞各种保活黑科技？

其实搞保活的目的倒不是为了干什么见不得人的坏事（但不排除动机不纯的开发者），主要是像IM即时通讯应用和资讯类应用等需要搞后台消息推送、运动类应用需要在后台实时监测用户的运动数据等，因为现在越来越多的手机厂商为了省电策略考虑，基本上如果你的应用没有被加入白名单，一旦处于后台就会被系统限制甚至干掉，但使用APP的用户才不听你这些解释——反正“我”就要你的APP能如期正常运行，开发者也是不得已而为之。

以消息推送为例，当APP处于后台或关闭时，消息推送对于某些应用来说非常有用，比如：

• 1）IM即时通讯聊天应用：聊天消息通知、音视频聊天呼叫等，典型代表有：微信、QQ、易信、米聊、钉钉、Whatsup、Line；
• 2）新闻资讯应用：最新资讯通知等，典型代表有：网易新闻客户端、腾讯新闻客户端；
• 3）SNS社交应用：转发/关注/赞等通知，典型代表有：微博、知乎；
• 4）邮箱客户端：新邮件通知等，典型代表有：QQ邮箱客户端、Foxmail客户端、网易邮箱大师；
• 5）金融支付应用：收款通知、转账通知等，典型代表有：支付宝、各大银行的手机银行等；
•   .... ....
  

在上述的各种应用中，尤其对于用户接触最多、最平常的IM聊天应用或新闻资讯来说，保活和消息推送简直事关APP的“生死”，消息推送这种能力已经被越来越多的APP作为基础能力之一，因为移动互联网时代下，用户的“全时在线”能力非常诱人和强大，能随时随地即时地将各种重要信息推送给用户，无疑是非常有意义的。

题外话：实际上，对于后台消息推送能力，Android原版系统早就内置了系统级推送服务（跟iOS上的APNs服务是一个东西），它就是GCM服务（现在升级为FCM了），但众所周之的原因，谷哥的服务在国内都是用不了的（你懂的）——无奈啊！

（有关GCM的介绍详见：《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》、《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》、《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》）。

3、针对以往Android版本的各种保活技术回顾

搞Android端IM和消息推送服务的开发者都知道，Android P之前为了搞定客户的投诉：“为什么微信能收到消息而你们的IM却不能?”，为了解决这个“痛点”，广大的Android开发者们只能让各种黑科技轮番上场、各显神通，最典型的：比如曾今在手机QQ上的1像素保活（虽然QQ官方从没正面承认过）、后台无限播放无声音的音频、应用互相拉活等，大家都耳熟能详。

下面就是即时通讯网整理过的各种典型保活需求和思路，可以回顾学习一下：

• 《应用保活终极总结(一)：Android6.0以下的双进程守护保活实践》
• 《应用保活终极总结(二)：Android6.0及以上的保活实践(进程防杀篇)》
• 《应用保活终极总结(三)：Android6.0及以上的保活实践(被杀复活篇)》
• 《Android进程保活详解：一篇文章解决你的所有疑问》
• 《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
• 《深入的聊聊Android消息推送这件小事》
• 《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
• 《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
• 《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
• 《移动端IM实践：实现Android版微信的智能心跳机制》
• 《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
• 《全面盘点当前Android后台保活方案的真实运行效果（截止2019年前）》
• 《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》
• 《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》
• 《正确理解IM长连接的心跳及重连机制，并动手实现（有完整IM源码）》
• 《2020年了，Android后台保活还有戏吗？看我如何优雅的实现！》
• 《史上最强Android保活思路：深入剖析腾讯TIM的进程永生技术》
  

4、国内各种Android厂商级推送通道出现了

为了响应Android原版中对省电策略、用户体验等设计，也为了避免各种保活乱象，国内主流的Android手机厂商在阉割了谷歌原版的GCM(FCM)推送通道之后（悲剧！），依靠自身的技术力量构建起来各家自有的推送通道。

下面是国内主流Android厂商的推送服务开发者入口：

• 小米消息推送服务；
• 华为消息推送服务（Huawei Mobile Services）；
• 魅族消息推送服务；
• OPPO消息推送服务；
• vivo消息推送服务。
  

看到上面这串厂商系统级推送通道列表，相信你已经露出了你那排洁白的牙齿了 ^_^。。。

如果剧情都能像都市爱情小说那样——“男女主角从此过上了幸福美满的生活...”，那就完美了！

但是（这个但是真的很讨厌），不要高兴的太早，理想情况下对接厂商通道确实很爽，但现实很骨感。

对接厂商通道带来的麻烦，远比你想像的要多：

• 1）你得一家一家下载SDK、注册开发者账号、搞手机端对接、搞服务端对接；
• 2）各厂商的SDK都打包在一个APP里，可能存在各种兼容性问题；
• 3）因为ROOM版本问题，即使同一个厂商的手机的同一套SDK也存在新旧ROOM的兼容性问题；
• 4）这一堆的SDK，各种jar包让你的APP莫名变大了不少；
• 5）服务端要对接各种厂商的推送后台，各家的技术水平、SDK水准、服务稳定性参差不齐，对接起来难受吧；
• 6）有些手机小厂并没有自已的推送通道，你自建的推送能道还不能扔。
  

凡此种种，对接厂商通道并不轻松。

而且，你忘了国内的Android机型有多杂吗？看下面这张图：


不过：如果公司不排斥使用第3方通送方案的话，现阶段这种混乱状况下，可以考虑直接用第3方的服务，比腾讯的信鸽推送为例（首先申明，我没收信鸽的好处费，只是举个例子！），信鸽推送的方案也是一家一家对接第3方的厂商通道道+自有通道（《[资讯] 信鸽新版上线：号称Android首家统一推送服务》），对于开发者来说信鸽的实现思路其实跟我们想的是一样的。但好处是：别人有专门的团队死磕这件破事，比你自已一个人带来的效果要好多了。

5、万众瞩目的“统一推送联盟”上场了

为了解决这些乱象，好消息是去年有政府背景的“统一推送联盟”成立了（详见《[资讯] 统一推送联盟在京成立：结束国内安卓生态混乱》），广大Android开发者真是翘首以盼。

但坏消息是好像进展并不顺利（大家心知肚明啊，各厂商的利益不好均衡嘛），最近一次跟消息推送服务有关的活动还是3个月前的《[资讯] 统一推送联盟2018成员大会如期召开》。虽然进展不大，但总算还是有希望，Android同行们再等等，总有Android端消息推送一统江湖的方案出现的那天。

** 20180805最新进展：统一推送联盟于2018年8月初对外公开了《统一推送通道层接口规范》。梦想离现实又近了一步！

6、Andriod P要来了，噩梦仍将继续！

Android P中针对省是管理方面的改进，只会使得搞后台保活、消息推送越来越麻烦，作为Android开发者来说，了解这些新特性至少能让自已心里有底，从而在技术上做到有的放矢。

Android P中电量管理特性主要体现在以下四个方面：

• 1）应用待机分组：Android P 新增应用待机分组功能，让系统根据用户的使用情况而限制应用调用 CPU 或网络等设备资源；
• 2）应用后台限制：Android P新增后台限制功能，若应用出现 Android Vitals 内所描述的不良行为，系统将提醒用户限制该应用访问设备资源；
• 3）省电模式优化：Android P 优化了现有的省电助手功能，在启用该功能后，系统将对所有应用的后台运行实施加以限制；
• 4）低耗电模式：当用户一段时间没有使用设备时，设备将进入低耗电模式，所有应用都将受到影响。 Android P 并未针对低电耗模式作出任何更改。
  

*注意：不论应用程序的 target SDK 是否为 Android P ，所有应用都受限于以上行为变更。

接下来将逐一介绍这几个特性。

7、Andriod P电量管理特性1：应用待机分组

应用待机分组是 Android P 新添加的一项电量管理功能，它能根据应用的使用频率或者最近一次使用时间，对其资源请求进行优先级排序。应用待机分组一共有五个分组，系统会根据每个应用的使用情况，将其划分至五个优先分组中的一个，而每个分组对设备资源的调度各有不同的限制。

7.1优先分组

系统将动态分配各个应用至不同分组，并根据需求重新分配所在分组。系统或会通过利用机器学习预加载的应用，从而预测各个应用的使用概率，然后将它们编配至相应的群组中。若设备中没有安装此类系统应用，在默认情况下，系统会根据应用的近期使用情况进行等级划分。应用活跃度越高，所处分组的优先级就越高，也就相应地更容易获取设备资源。尤其是，应用所处的的群组决定了其所安排的任务 (job)，触发标准闹铃以及接受高优先级Firebase Cloud Messagesing信息的频率。这些限制仅在非充电状态下才有效；当设备充电时，应用并不会受到系统限制。

*注意：设备厂商可以自行规定非活跃应用的群组划分规则。请开发者不要试图篡改应用所处的群组，而是专注于改善应用行为，确保应用被划分至目标群组后，依旧能够顺利运行。您可以调用 UsageStatsManager.getAppStandbyBucket()，查看应用当下所处群组。

应用待机模式下共有以下五类群组：

• 1）活跃 (Active): 应用正在被使用；
• 2）工作 (Working set): 应用使用频率很高；
• 3）常用 (Frequent): 应用经常但不是每天被使用；
• 4）极少 (Rare): 应用偶尔被使用；
• 5）应用偶尔被使用 (App is not frequently used)。
  

此外，安装后一次都未被使用过的应用将被划分至 “从不” 这一特殊群组，并受到十分严格的系统限制。

*注意：应用待机群组限制不适用于低耗电模式白名单中的应用。

7.2活跃 (Active)

活跃应用指用户正在使用的应用，例如：

• 1）应用启动了一个Activity；
• 2）应用正在运行前台服务；
• 3）另一个前台应用已关联至该应用 (通过同步适配器与前台应用的内容提供器相关联)；
• 4）用户点击了应用的推送。
  

在任务、标准闹铃以及FCM信息的资源调用上，活跃群组应用免受任何系统限制。

7.3工作 (Working set)

若应用的运行频率很高，但目前并未处于“活跃”状态，它就会被划分至工作群组，例如用户常用的社交媒体应用。此外，该群组还包括了那些被间接使用的应用。

工作分组内的应用会在任务 (job) 运行和闹铃触发方面受到部分系统限制，详情请查阅《附件: 电量管理限制》。

7.4常用 (Frequent)

常用应用指用户经常使用但不是每天使用的应用，比如用户在健身房使用的打卡应用可能就属于这一群组。

系统对常用分组采用的限制更强，应用运行任务(job)和触发闹铃的能力都会受到影响，而且接受的高优先性FCM消息也有数量上限，详情请查阅《附件：电量管理限制》。

7.5极少 (Rare)

若应用的使用频率很低，它就会被划分至该分组，酒店应用就是一个很好的例子——用户只有在下榻这个酒店的时候才会打开此应用。

该群组下的应用在任务 (job)、闹铃和高优先性FCM消息的资源调用上都会受到严格的限制。此外，网络访问能力也会受到影响。详情请阅读《附件：电量管理限制》。

7.6最佳实践建议

如果您已经根据低耗电模式和应用待机模式的最佳实践对您的应用进行过相关优化，您应该能够轻松应对新的电量管理特性。不过，部分应用行为可能会受到此次特性变更的影响，无法继续正常运作。

• 1）请勿尝试操控系统将您的应用分配至某一特定群组。系统的分组规则可能会发生变化，而且设备厂商也可以根据自己的算法自行开发分组应用。开发者需要确保自己的应用在任何群组内都能够继续流畅运行。
• 2）如果应用没有 Launcher Activity，它可能永远都不会切换至活跃分组。开发者可能需要重新设计应用并添加此类activity。
• 3）如果应用的推送不具备可操作性，用户将无法借助与推送的交互将应用切换至活跃群组。在这种情况下，开发者可考虑重新设计推送功能，允许用户响应。具体操作指南，请参照 Material Design 中有关推送设计的章节。
• 4）若应用在接受高优先级的 FCM 消息之后未能发送推送，用户将无法与应用产生互动并将其优先级提升至 “活跃” 等级。其实，高优先级 FCM 消息的唯一用途就是向用户发送推送，因此这种情况绝对不应该出现。如果您错误的将没有与用户进行互动的 FCM 消息设置为高优先级，这种标记不当的行为可能会导致其他不良后果，比如：在应用耗尽高优先级消息额度之后，系统会把真正紧急的 FCM 消息当做“普通优先级”消息来处理。
  

*注意：如果用户多次忽略某条推送，系统会询问用户是否不再接受此推送。请开发者不要只是为了将应用保留在活跃群组，而向用户不断发送推送。如果一个应用下面有多个包，这些包可能分别属于不同分组，各自的访问权限也有所不同。在测试环节时，请开发者先将包划分至不同分组，然后进行多次测试，确保应用行为无异常。

8、Andriod P电量管理特性2：后台限制

当系统监测到应用消耗过多资源时，系统会通知并询问用户是否需要限制该应用的后台活动。

目前有以下两种情况会触发系统发送此通知：

• 1）频繁使用唤醒锁 (wake locks)：屏幕关闭后，局部唤醒锁 (Partial wake lock) 连续开启 1 小时；
• 2）过多的后台服务：当应用目标 API 等级低于 26，且运行过多后台服务。
  

设备厂商可自行决定具体采用的限制，比如：在 AOSP 构建上，除非受限应用运行在前台，否则它将无法运行任务 (job)，触发闹铃或者访问网络。(请查阅《后台服务限制》了解如何判断应用是否为前台运行。) 详细限制列表，请查阅《附件：电量管理限制》。

9、Andriod P电量管理特性3：省电助手优化

Android P 进一步提升了省电模式的性能，由设备厂商来决定其采用的具体限制。

比如：在AOSP构建上存在以下系统限制：

• 1）应用将更容易进入待机模式，系统不会一直等到应用处于“空闲”状态才采取行行动；
• 2）不论目标API等级为何，所有应用都会受到后台执行限制；
• 3）屏幕关闭后，位置服务可能被禁用；
• 4）处于后台的应用不能访问网络。
  

除此以外，Android P 还引入了多项针对设备的电量管理的优化，请阅读《附件：电量管理限制》获取进一步信息。

建议开发者在开启省电模式的情况下测试应用，您可在 Settings > Battery Saver 内手动开启省电模式：

10、Andriod P电量管理特性4：低耗电模式

在低耗电模式下，应用对高耗电资源的使用权限将被推迟至下一个维护时段。具体限制请参照《附件：电量管理限制》。

进一步信息，请查阅《对低耗电模式和应用待机模式进行针对性优化》。

11、本文小结

对于开发者来说，Android平台向来以“乱”著称，后台保活和消息推送从各种黑科技，到厂商纷纷自建通道，再到统一推送联盟。时至今日，该面对的问题依然没有改观，随着Android P正式版的发布，对于IM、消息推送服务等开发者来说，个人英雄主义式的技术黑科技越来越没有发挥的空间，从长远来讲这是好事。

随着时间的推进，分久必合的局面终将出现，Android平台也必将越来越规范，Android P这样版本只是这前进过程中的阵痛，希望广大Android开发者在Android技术进步的福利下能越来越轻松，再也不用“开大招”琢磨各种非主流黑科技了。走经路，做正经APP才有未来。。。

附录：更多相关技术文章

《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《IBM技术经理访谈：MQTT协议的制定历程、发展现状等》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
《极光推送系统大规模高并发架构的技术实践分享》
《从HTTP到MQTT：一个基于位置服务的APP数据通信实践概述》
《魅族2500万长连接的实时消息推送架构的技术实践分享》
《专访魅族架构师：海量长连接的实时消息推送系统的心得体会》
《深入的聊聊Android消息推送这件小事》
《基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)》
《一个基于长连接的安全可扩展的订阅/推送服务实现思路》
《实践分享：如何构建一套高可用的移动端消息推送系统？》
《Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《百万在线的美拍直播弹幕系统的实时推送技术实践之路》
《京东京麦商家开放平台的消息推送架构演进之路》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《基于APNs最新HTTP/2接口实现iOS的高性能消息推送(服务端篇)》
>> 更多同类文章 ……

双手点赞 six! six! six!

生活不易 转方向跑路。。。

引用：CodeBoy 发表于 2018-08-02 16:11
生活不易 转方向跑路。。。

android从入门到跑路，哈哈

Google还需努力。

引用：cv0cv0 发表于 2018-08-03 16:46
Google还需努力。

很难再回来了

已经画了红线，完美

引用：瞿亮帅 发表于 2018-08-10 18:24
已经画了红线，完美

多谢指正，错误已修正！  你处女座吧...

啦啦啦啦啦

直说了吧，黑科技保活慢慢不行了，标准保活还没出来，现在商务保活是最有效的手段。

面向VPN网的项目才难。。。各种推送SDK都在互联网，很多机型有白名单，但白名单一点用都没有。

感觉Android系统如果能弄个保活区就好了，只允许后台Svervice加入，这些Service不会被干死，网络不会被掐断，5分钟的Alarm能保证。出厂时加了几个，比如微信啥的，用户可以手动添加，程序不能自己把自己加进去。保活区的Service的行为、流量、耗电量都有统计。这样，皆大欢喜啊，非得搞这么多灰色区域，似活非活的，又原生白名单又系统管家，七七八八的，整的现在这么恶心。

引用：qyc898 发表于 2019-04-21 15:33
直说了吧，黑科技保活慢慢不行了，标准保活还没出来，现在商务保活是最有效的手段。

面向VPN网的项目才 ...

其实学ios就好了，所有应用退到后台直接干死，只允许用统一的系统级通道。不过，android里其实也有这个东西，但可惜不是一开始就有，而且国内厂商ROOM阉割的厉害，就搞成了现在这乱取八糟的样子了。。

每次更新，保活确实太难了

引用：hc111 发表于 2019-09-24 16:49
每次更新，保活确实太难了

以后越来越不可能了