6、App Standby：App Standby机制、分类（Active、Working Set、Frequent、Rare、Never）、如何影响后台行为。
各位同学，咱们今天聊聊 App Standby。这玩意儿，说白了就是 Android 系统用来管住那些“不老实”的后台应用的。你想想看，手机电池就那么大，要是每个 App 都在后台偷偷摸摸干活，那电量还不跟流水似的往下掉？
我刚开始接触这个机制的时候，也觉得它有点“霸道”。但后来在项目里吃过亏，才明白它的重要性。嗯，咱们一步步来看。
App Standby 是什么？
App Standby 是 Android 6.0（API 23）引入的一套后台管理策略。它的核心思想很简单：系统会根据用户最近是否主动与某个 App 交互，来动态限制它的后台行为。
说白了，就是系统会判断：“这个 App，用户是不是很久没碰它了？” 如果是，那就给它“降降温”，限制它的网络访问、延迟它的 Job 和 Alarm，甚至禁止它唤醒 CPU。
核心目标： 在用户不感知的情况下，最大化电池续航。
五大分类：你的 App 在哪个“候车室”？
App Standby 把应用分成了五个等级，就像火车站里的候车室一样，等级不同，待遇天差地别。我习惯叫它们“五档位”。
| 分类 | 英文名 | 含义 | 后台行为限制 |
|---|---|---|---|
| 活跃 | Active | 用户正在使用，或刚使用过 | 无限制，想干嘛干嘛 |
| 工作集 | Working Set | 用户经常使用，但当前不在前台 | 轻微限制，网络访问可能稍有延迟 |
| 频繁 | Frequent | 用户偶尔使用，频率不高 | 限制网络访问，Job 和 Alarm 被延迟 |
| 罕见 | Rare | 用户很少使用，很久没打开过 | 严格限制网络，禁止唤醒 CPU，Job 和 Alarm 被大幅延迟 |
| 从不 | Never | 用户从未使用过，或已被卸载 | 几乎完全禁止后台活动 |
你看这个表，从 Active 到 Never，限制是逐步加码的。为什么会这样？因为系统认为，你越不用的 App，它就越不应该在后台浪费资源。
它是如何影响后台行为的？
这个机制对后台行为的影响，主要体现在三个方面：
- 网络访问受限： 当 App 进入 Frequent 或 Rare 状态时，系统会阻止它在后台发起网络请求。除非你使用了 Firebase Cloud Messaging（FCM）这样的高优先级推送，否则网络连接会被直接掐断。
- Job 和 Alarm 延迟： 你通过
JobScheduler或AlarmManager设置的任务，会被系统推迟执行。比如你设了一个 10 分钟后的闹钟，但 App 在 Rare 状态，这个闹钟可能被延迟到 1 小时甚至更久以后。 - 禁止唤醒 CPU： 这是最狠的一招。系统会阻止 App 通过
WakeLock或AlarmManager的setExact()来唤醒设备。说白了，就是不让你的 App 把手机从休眠中叫醒。
注意： 我曾经在项目里遇到过一个坑。我们有个即时通讯 App，为了省电，用了 JobScheduler 来做心跳保活。结果用户反馈消息经常延迟。一查才发现，App 被系统归到了 Rare 分类，心跳 Job 被延迟了。后来我们改用了 FCM 推送，才解决了这个问题。
状态迁移：App 是如何“降级”的？
系统会维护一个“最后使用时间”的计时器。当用户主动打开 App，或者 App 在前台运行，计时器就会重置。一旦 App 进入后台，计时器就开始倒计时。
- 如果用户 24 小时内 没有主动与 App 交互，它就会从 Active 降级到 Working Set。
- 如果 几天内 都没有交互，就会进入 Frequent。
- 如果 几周甚至更久 都没碰过，那就进入 Rare 了。
当然，这个时间阈值在不同 Android 版本上可能略有差异。但大逻辑是不变的：用户越不关心，系统就越限制。
如何查看 App 的 Standby 状态？
你可以通过 adb 命令来查看某个 App 当前处于哪个“候车室”：
adb shell dumpsys usagestats这个命令会输出一大堆信息。你可以搜索你的包名，找到类似这样的字段：
appId=com.example.myapp
...
standby-bucket: rare
...这里的 standby-bucket 就是当前状态。如果看到是 rare，那你的 App 基本就处于“半休眠”状态了。
小技巧： 在开发测试时，你可以手动强制设置 App 的 Standby 状态，来模拟不同场景：
adb shell am set-standby-bucket com.example.myapp rare这样就能快速验证你的 App 在受限状态下的表现。
一张图看懂 App Standby
为了让你更直观地理解，我画了一张流程图。它展示了 App 从 Active 到 Never 的完整生命周期，以及每个阶段的行为限制。
避坑指南：开发者该怎么做？
了解了这些，你可能会问：“那我该怎么让我的 App 不被系统‘降级’？” 嗯，这里有几个我踩过的坑，分享给你：
- 别滥用 WakeLock： 我曾经见过一个 App，为了保活，疯狂持有 WakeLock。结果不仅没保住，还被用户投诉耗电。系统检测到这种行为，会直接把 App 扔进 Rare 分类。
- 用 FCM 代替轮询： 如果你的 App 需要实时消息，别自己搞长连接或轮询。用 Firebase Cloud Messaging，它走的是系统级的高优先级通道，不受 App Standby 限制。
- 合理使用 JobScheduler： 设置 Job 时，尽量用
setPeriodic()而不是setMinimumLatency()。系统对周期性 Job 的容忍度更高。 - 测试你的 App： 在开发阶段，一定要用 adb 命令模拟不同 Standby 状态，看看你的 App 在受限情况下是否还能正常工作。
总结一下： App Standby 是 Android 系统为了省电而设计的“懒人管理法”。它通过五个等级，动态限制不常用 App 的后台行为。作为开发者，我们要做的不是对抗它，而是顺应它——用更优雅的方式实现后台功能。