Android 9.0 正式版已经推送了两月有余，尽管这一次很多非 Google 机型都借助 Project Treble 第一时间吃上了「派」，但 9.0 的诸多 改动和新特性 对部分用户而言还是有着不小的上手门槛和适应难度，比如更加强力、但也略显复杂的通知系统与勿扰模式，再比如拥有受限应用、后台检查、待机应用等多层机制的电源管理模式。
如果你想要拥有最佳的续航时间却不知该从何下手进行应用管理，今天这篇文章应该能够帮到你。
你可能不知道的是，谷歌自 Android 6.0 时代就已经为 Android 系统引入了待机（Standby）机制，这个机制通过推迟后台网络活动（比如获取你不关心的资讯动态）来尽可能地降低那些我们使用频率较低的应用的后台电量消耗。
但这个待机机制长期一来却被诟病为「鸡肋」。
一方面，Android 系统并未向我们提供一个可交互的界面来对这个「使用频率」进行自定义，而这个待机机制本身对于「使用频率较低」这个条件的判定规则过于宽松，待机机制的后台活动限制可以轻松地被 BAT 三家的「毒瘤」应用们破除；另一方面，和 Android 系统的其他省电机制（如 Doze）比起来，待机机制的限制力度也较低，最终达到的效果微乎其微。
Android 9.0 对待机机制进行了优化和改进：首先，待机机制从「使用频率较低」这个较为模糊的概念范围中跳了出来，进而适用于所有应用。
其次，新的待机机制引入了一个新的概念——应用待机桶（App Standby Buckets），基于 AI 对我们日常应用使用习惯的观察和学习，手机中的所有应用都会被分配到不同的「桶」当中去，这些「桶」包括：
这里需要大家额外注意的有这样几点。
其一，上面出现的应用仅作为方便大家理解的例子，在实际使用中，哪些应用该进入哪个「桶」，都会根据个体的使用习惯而变——比如你的主要移动支付工具是微信，偶尔打开看看理财收益的支付宝，也许就会被放入「频繁」甚至是「罕用」应用当中。
其二，如果你想进一步了解「哪些『桶』有哪些具体的限制」这个问题，不妨参考下面这份由谷歌给出的示例表格：
其三，针对 9.0 之前用户无法根据自身使用情况手动干预应用待机机制的问题，谷歌在引入机器学习的同时，也允许用户在 开发者选项->待机应用 设置中手动为每个应用设定待机「桶」。
其四，考虑到某些应用也许会通过频繁发送通知与用户进行互动的方式来「保活」，破坏「应用待机桶」机制的设计目标，谷歌会在用户频繁消除某个应用的通知时给出一键阻止该类通知的快捷操作，确保应用活跃度判定的真实有效。
最后，设备制造商可以在「应用待机桶」这个机制的基础上自行定制应用的分配标准，理想情况下，国内定制 UI 中各类「省电精灵」和「安全助手」可以针对中国大陆特有的应用生态环境对这个机制进行适当加强；另外，原生 Android 9.0 默认不会在手机充电时施加任何限制。
如何在「绿色守护」和「黑阈」这类应用中做出抉择，几乎是每个刚刚转入 Android 阵营的用户都会纠结的一个问题，而每次向 @Clyde 问起类似的问题，他总会跟我瞎吹说「『奥利奥』集成了一个『黑阈』，还要什么优化应用？」
这句话其实有一定道理：谷歌自 Android Oreo 开始引入了一个名为「后台检查」的功能，可以在部分应用的 应用信息->电池 中手动开启，开启后，目标应用的相关服务（如 widget 刷新、通知推送等）在放入后台 1 分钟后便会直接停止。
后台检查功能设计之初虽然针对 API 26 以下（即没有适配更高版本系统）的应用，国内的「毒瘤」应用也大多满足这个条件，但它们仍然可以通过上面提到的频繁发送通知这样的方式实现「保活」，同时，后台检查功能的限制范围不包括定时唤醒和任务调度周期。
用一句话来总结这个功能就是：后台检查虽然将躲在幕后的隐性机制变成了实实在在可操作的开关，但依然不够强力。因而在 Android 9.0 中我们会发现，应用信息里原有的后台检查功能已经被一个名为「应用限制（Restrict app）」的功能所取代。
应用限制与后台检查一脉相承但要更进一步，有着更广的适用范围和更强力的限制手段。
适用范围上，Android Oreo 中的后台检查只针对 API 26 以下应用，而 Android Pie 的应用限制面向系统中所有已安装应用；限制手段上，和本文第一部分所介绍的「应用待机桶」更多地采用延后、推迟等手段来节省系统资源的方法不同，当我们为某款应用开启了应用限制，这款应用的所有后台运行活动、联网请求和相关服务都将被系统强制忽略。当一款被限制的应用放入后台运行时，它只能通过 Android 平台的统一推送（FCM）与我们进行互动。
两个机制前者相对温和，后者更为激进。排除一味杀应用的粗暴做法，而是选择精细地限制应用运行的机会和资源，既可以由系统自动化建议和执行，也可以由用户自行设立限制，二者相辅相成，基本上可以治理好一些常见的「毒瘤」应用。
除了是一个内核玩家，我同时也是一个 iOS 用户，iOS 的低电量模式在限制后台活动刷新外，还会大幅降频 CPU， 能让手机的续航增色不少；但是 Android 上面的省电模式采用了不同的策略——它并没有降频 CPU 或牺牲性能，而是采用限制后台活动、关闭动画（我不太理解为什么 iOS 的低电量模式不关闭动画来省电）的方式，并在状态栏和导航栏用醒目刺眼的红色来警示用户少玩手机。
Android 9.0 上的省电模式的策略有所调整：不降频 CPU、不关闭动画、不用红色警示你，同时大幅削弱应用的后台活动。
这里的「大幅削弱应用的后台活动」主要体现在以下几个方面：
回到文章开头提到的问题：想要在 Android 9.0 上获得最佳的续航时间究竟该从何下手呢？
从用户的角度出发，我们需要做的其实并不多，因为大部分统计、检测、判断的任务其实都可以交给机器学习来完成，我们只需要像往常一样使用应用就行了，不用过多操心。如果你真的想帮它一点忙，或对某些「毒瘤」不太放心，也可以做这些事：
欢迎在评论区分享你的看法。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。