Android 9.0 正式版已经推送了两月有余，尽管这一次很多非 Google 机型都借助 Project Treble 第一时间吃上了「派」，但 9.0 的诸多 改动和新特性 对部分用户而言还是有着不小的上手门槛和适应难度，比如更加强力、但也略显复杂的通知系统与勿扰模式，再比如拥有受限应用、后台检查、待机应用等多层机制的电源管理模式。
如果你想要拥有最佳的续航时间却不知该从何下手进行应用管理，今天这篇文章应该能够帮到你。
待机机制
你可能不知道的是，谷歌自 Android 6.0 时代就已经为 Android 系统引入了待机（Standby）机制，这个机制通过推迟后台网络活动（比如获取你不关心的资讯动态）来尽可能地降低那些我们使用频率较低的应用的后台电量消耗。
但这个待机机制长期一来却被诟病为「鸡肋」。
一方面，Android 系统并未向我们提供一个可交互的界面来对这个「使用频率」进行自定义，而这个待机机制本身对于「使用频率较低」这个条件的判定规则过于宽松，待机机制的后台活动限制可以轻松地被 BAT 三家的「毒瘤」应用们破除；另一方面，和 Android 系统的其他省电机制（如 Doze）比起来，待机机制的限制力度也较低，最终达到的效果微乎其微。
Android 9.0 对待机机制进行了优化和改进：首先，待机机制从「使用频率较低」这个较为模糊的概念范围中跳了出来，进而适用于所有应用。
其次，新的待机机制引入了一个新的概念——应用待机桶（App Standby Buckets），基于 AI 对我们日常应用使用习惯的观察和学习，手机中的所有应用都会被分配到不同的「桶」当中去，这些「桶」包括：
- 活跃（Active）：正在使用中的应用，如正在前台运行的微信。系统不会对这个「桶」中的应用施加任何后台资源限制。
- 工作组（Working set）：经常使用但当前并没有活动的应用，如用于移动支付的支付宝，我们并不需要它像微信那样具备即时性，只需它在使用时能够快速进入工作状态。系统会对这些应用施加较为温和的后台资源限制（如适当推迟一些内容更新活动等等）。
- 频繁（Frequent）：频繁这个「桶」里的应用其实没有固定的频率，比如我们隔三差五去健身房或出门下馆子才会用的运动记录、优惠券 App 等。系统会延迟这些应用的部分后台活动并减少它们发出高优先级通知的频率。
- 罕用（Rare）：不常用的应用，比如我们偶尔出差、旅游时才会打开预定车票、机票和住宿的应用。系统会延迟「罕用」应用的后台活动和大部分通知，对这些应用的后台网络活动限制最长可达 24 小时。
- 从不使用（Never）：从来没有运行过的应用，自然而然地，系统不会为这些应用分配任何系统资源。
这里需要大家额外注意的有这样几点。
其一，上面出现的应用仅作为方便大家理解的例子，在实际使用中，哪些应用该进入哪个「桶」，都会根据个体的使用习惯而变——比如你的主要移动支付工具是微信，偶尔打开看看理财收益的支付宝，也许就会被放入「频繁」甚至是「罕用」应用当中。
其二，如果你想进一步了解「哪些『桶』有哪些具体的限制」这个问题，不妨参考下面这份由谷歌给出的示例表格：
其三，针对 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、不关闭动画、不用红色警示你，同时大幅削弱应用的后台活动。
这里的「大幅削弱应用的后台活动」主要体现在以下几个方面：
- 系统不再等待应用空闲，而是主动将应用设置为待机（Standby）模式，这样一来，应用待机桶功能起到的作用会更为明显；
- 「应用限制」将施加在所有应用上，无论用户是否针对应用单独进行过设置；
- 后台的应用程序没有访问网络的权限，屏幕关闭时还可能会自动禁用位置服务；
- 针对传感器进行功耗优化，比如在开启了省电模式的 Pixel 2 上，抬手亮屏和双击亮屏都被禁用了；
- 省电模式可以手动打开，也可以在我们设定的电量百分比（5%~75%） 自动打开；
- 同样，这个省电模式的具体限制方式和触发规则也可以由 OEM 厂商根据需求进行定制。
小结
回到文章开头提到的问题：想要在 Android 9.0 上获得最佳的续航时间究竟该从何下手呢？
从用户的角度出发，我们需要做的其实并不多，因为大部分统计、检测、判断的任务其实都可以交给机器学习来完成，我们只需要像往常一样使用应用就行了，不用过多操心。如果你真的想帮它一点忙，或对某些「毒瘤」不太放心，也可以做这些事：
- 及时更新你的应用到最新版本。适配系统后的应用才能最大地限度发挥它们功能的同时，又不过度消耗你的电量；
- 系统向你建议限制应用、阻止通知时，根据自己的实际需求考虑后做决定；
- 据自己日常行程设定一个合适的电量百分比，自动打开你的节电模式；
- 打开开发者选项，关闭毒瘤的后台活动，在「待机应用」里将不常用的应用设置为「罕用」。
欢迎在评论区分享你的看法。
