Android P的最后一个开发者预览版（即DP5）已如期发布于2018年7月26日，根据上面这张发布路线图，相信Android P的正式版将很快到来。对于Andriod开发者来说，不管Andriod P有多少新功能或者特性（反正“我”用iPhone啊，哈哈），是否影响“我”撸的APP的运行才是最要紧的事。
自从Andriod 6.0以来，Android系统在省电管理这方面做的越来越好，对于开发者来说限制也越来越多，也直接导致了各种保活黑科技群魔乱舞（别笑，就的就是“你”！）。但Android P官方公开的开发者资料来看，此版加入或强化的多项设备电量管理新特性，使得需要后台消息推送、应用保活的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了），但众所周之的原因，谷哥的服务在国内都是用不了的（你懂的）——无奈啊！
搞Android端IM和消息推送服务的开发者都知道，Android P之前为了搞定客户的投诉：“为什么微信能收到消息而你们的IM却不能?”，为了解决这个“痛点”，广大的Android开发者们只能让各种黑科技轮番上场、各显神通，最典型的：比如曾今在手机QQ上的1像素保活（虽然QQ官方从没正面承认过）、后台无限播放无声音的音频、应用互相拉活等，大家都耳熟能详。
为了响应Android原版中对省电策略、用户体验等设计，也为了避免各种保活乱象，国内主流的Android手机厂商在阉割了谷歌原版的GCM(FCM)推送通道之后（悲剧！），依靠自身的技术力量构建起来各家自有的推送通道。
下面是国内主流Android厂商的推送服务开发者入口：
小米消息推送服务；
华为消息推送服务（Huawei Mobile Services）；
魅族消息推送服务；
OPPO消息推送服务；
vivo消息推送服务。
看到上面这串厂商系统级推送通道列表，相信你已经露出了你那排洁白的牙齿了 ^_^。。。
如果剧情都能像都市爱情小说那样——“男女主角从此过上了幸福美满的生活...”，那就完美了！
但是（这个但是真的很讨厌），不要高兴的太早，理想情况下对接厂商通道确实很爽，但现实很骨感。即时通讯聊天软件app开发可以加蔚可云咨询
对接厂商通道带来的麻烦，远比你想像的要多：
1）你得一家一家下载SDK、注册开发者账号、搞手机端对接、搞服务端对接；
2）各厂商的SDK都打包在一个APP里，可能存在各种兼容性问题；
3）因为ROOM版本问题，即使同一个厂商的手机的同一套SDK也存在新旧ROOM的兼容性问题；
4）这一堆的SDK，各种jar包让你的APP莫名变大了不少；
5）服务端要对接各种厂商的推送后台，各家的技术水平、SDK水准、服务稳定性参差不齐，对接起来难受吧；
6）有些手机小厂并没有自已的推送通道，你自建的推送能道还不能扔。
凡此种种，对接厂商通道并不轻松。
Android P中针对省是管理方面的改进，只会使得搞后台保活、消息推送越来越麻烦，作为Android开发者来说，了解这些新特性至少能让自已心里有底，从而在技术上做到有的放矢。
Android P中电量管理特性主要体现在以下四个方面：
1）应用待机分组：Android P 新增应用待机分组功能，让系统根据用户的使用情况而限制应用调用 CPU 或网络等设备资源；
2）应用后台限制：Android P新增后台限制功能，若应用出现 Android Vitals 内所描述的不良行为，系统将提醒用户限制该应用访问设备资源；
3）省电模式优化：Android P 优化了现有的省电助手功能，在启用该功能后，系统将对所有应用的后台运行实施加以限制；
4）低耗电模式：当用户一段时间没有使用设备时，设备将进入低耗电模式，所有应用都将受到影响。 Android P 并未针对低电耗模式作出任何更改。
*注意：不论应用程序的 target SDK 是否为 Android P ，所有应用都受限于以上行为变更。
Andriod P电量管理特性1：应用待机分组
应用待机分组是 Android P 新添加的一项电量管理功能，它能根据应用的使用频率或者最近一次使用时间，对其资源请求进行优先级排序。应用待机分组一共有五个分组，系统会根据每个应用的使用情况，将其划分至五个优先分组中的一个，而每个分组对设备资源的调度各有不同的限制。
优先分组
系统将动态分配各个应用至不同分组，并根据需求重新分配所在分组。系统或会通过利用机器学习预加载的应用，从而预测各个应用的使用概率，然后将它们编配至相应的群组中。若设备中没有安装此类系统应用，在默认情况下，系统会根据应用的近期使用情况进行等级划分。应用活跃度越高，所处分组的优先级就越高，也就相应地更容易获取设备资源。尤其是，应用所处的的群组决定了其所安排的任务 (job)，触发标准闹铃以及接受高优先级Firebase Cloud Messagesing信息的频率。这些限制仅在非充电状态下才有效；当设备充电时，应用并不会受到系统限制。
*注意：设备厂商可以自行规定非活跃应用的群组划分规则。请开发者不要试图篡改应用所处的群组，而是专注于改善应用行为，确保应用被划分至目标群组后，依旧能够顺利运行。您可以调用 UsageStatsManager.getAppStandbyBucket()，查看应用当下所处群组。
应用待机模式下共有以下五类群组：
1）活跃 (Active): 应用正在被使用；
2）工作 (Working set): 应用使用频率很高；
3）常用 (Frequent): 应用经常但不是每天被使用；
4）极少 (Rare): 应用偶尔被使用；
5）应用偶尔被使用 (App is not frequently used)。
此外，安装后一次都未被使用过的应用将被划分至 “从不” 这一特殊群组，并受到十分严格的系统限制。
*注意：应用待机群组限制不适用于低耗电模式白名单中的应用。
相关文章
