25、Android 12/13/14电源新特性：省电模式增强、后台限制收紧、休眠策略更新
各位好，今天我们聊聊 Android 12 到 14 这几个版本在电源管理上的变化。说实话，这几年 Google 对电池续航的优化力度越来越大。我个人从 Android 11 开始跟进这些改动，每次大版本升级，都能感受到系统对后台应用的「敌意」在加深。嗯，这其实对用户是好事，但对开发者来说，坑也变多了。
省电模式的进化：从「一刀切」到「精细化」
省电模式不是新东西，但 Android 12 之后，它变得聪明多了。
Android 12 的省电模式：
- 引入了「极致省电」模式，说白了就是只允许你选定的几个应用运行。
- 屏幕刷新率强制降到 60Hz，动画效果减半。
- 后台同步全部暂停，包括邮件、社交应用。
Android 13 的改进：
- 省电模式现在可以按应用单独配置了。我记得在项目中遇到过，用户反馈某个地图应用在省电模式下无法导航。后来发现是系统把它的后台定位给掐了。
- 新增了「自适应省电」功能，系统会学习你的使用习惯。比如你每天晚上 10 点后基本不用手机，它就会提前进入省电状态。
Android 14 的增强：
- 省电模式现在会主动限制前台服务的 CPU 使用率。你想想看，就算应用在前台，如果它疯狂吃 CPU，系统也会出手干预。
- 新增了「电池健康」页面，直接告诉你电池最大容量还剩多少。这个功能其实底层早就有了，只是现在才开放给用户看。
核心变化总结：省电模式不再是简单的「关屏幕、降亮度」，而是变成了一个智能的、可配置的系统级资源调度器。
后台限制：越来越紧的「紧箍咒」
后台限制是 Android 12 到 14 变化最大的部分。我刚开始做 Android 开发时，后台想怎么跑就怎么跑。现在？嗯，Google 恨不得所有应用都乖乖待在前台。
Android 12 的后台限制：
- 引入了
foregroundServiceType属性。你必须在 Manifest 中声明前台服务的类型，比如camera、location、mediaPlayback等。不声明？系统直接抛异常。 - 后台应用启动前台服务被严格限制。只有少数几种情况允许，比如用户可见的通知、系统广播等。
<!-- Android 12 必须声明前台服务类型 -->
<service
android:name=".MyLocationService"
android:foregroundServiceType="location"
android:exported="false" />Android 13 的收紧：
- 新增了
POST_NOTIFICATIONS权限。应用必须先申请这个权限，才能发送通知。这直接影响了那些靠通知唤醒用户的应用。 - 后台 body 传感器（比如计步器）的访问被限制。应用在后台时，无法再读取这些传感器的数据。
注意：Android 13 开始，如果用户拒绝了通知权限，你的应用连前台服务通知都发不了。我曾经有个项目，用户反馈收不到导航提示，排查了半天才发现是通知权限被关了。
Android 14 的进一步限制：
- 后台启动 Activity 的限制更加严格。只有应用处于前台、或者用户主动交互时，才能启动 Activity。
- 新增了「精确闹钟」权限
SCHEDULE_EXACT_ALARM。如果你的应用不是闹钟或日历类应用，基本申请不到这个权限。 - JobScheduler 的作业执行间隔被拉长。系统会尽量把多个作业合并到一起执行，减少唤醒次数。
我的建议：如果你的应用需要定时执行任务，优先考虑 WorkManager。它已经适配了这些限制，会自动选择合适的执行时机。别自己写 AlarmManager 了，坑太多。
休眠策略更新：App Standby 和 Doze 的进化
Android 6 就引入了 Doze 模式，但直到 Android 12，它才真正变得「有攻击性」。
Android 12 的休眠策略：
- 引入了「休眠桶」（App Standby Buckets）的细化。系统会把应用分为五类：活跃、工作集、频繁、罕见、从未使用。不同类别的应用，后台限制力度不同。
- 「罕见」类别的应用，每天只能唤醒一次网络。你想想看，如果你的应用被归到这一类，基本等于断网了。
| 休眠桶类别 | 网络访问频率 | 作业执行频率 | 典型应用 |
|---|---|---|---|
| 活跃 | 无限制 | 无限制 | 当前正在使用的应用 |
| 工作集 | 每 2 小时一次 | 每 2 小时一次 | 经常使用的应用 |
| 频繁 | 每 4 小时一次 | 每 4 小时一次 | 偶尔使用的应用 |
| 罕见 | 每 24 小时一次 | 每 24 小时一次 | 很少使用的应用 |
| 从未使用 | 不允许 | 不允许 | 安装后从未打开的应用 |
Android 13 的更新：
- Doze 模式现在会更快进入。以前需要设备静止 30 分钟才进入，现在可能 15 分钟就开始了。
- 新增了「深度 Doze」状态。在这个状态下，所有网络访问都被禁止，包括高优先级的消息推送。
Android 14 的休眠策略：
- 引入了「休眠模式」的自动激活。如果用户连续几天没有打开某个应用，系统会自动把它放入「罕见」桶。
- 新增了「冻结」机制。应用在后台时，系统会直接冻结它的所有线程，连 CPU 时间都不给。只有用户再次打开应用时，才会解冻。
避坑指南：我曾经有个即时通讯应用，用户反馈收不到消息。排查后发现，Android 14 把我们的应用冻结了。解决方案是使用 Firebase Cloud Messaging（FCM）的高优先级消息，它可以在冻结状态下唤醒应用。但注意，高优先级消息每天也有配额限制。
知识体系结构图
下面这张图展示了 Android 12/13/14 电源新特性的核心逻辑。我习惯用这种图来梳理知识点，一目了然。
开发者需要做什么？
说了这么多，其实就一句话：别再依赖后台常驻了。我见过太多应用还在用老一套的保活手段，比如双进程守护、前台服务循环。这些在 Android 12 之后基本都失效了。
- 优先使用 WorkManager：它已经适配了所有版本的休眠策略，会自动选择合适的执行时机。
- 声明前台服务类型：如果你的应用确实需要前台服务，记得在 Manifest 中声明
foregroundServiceType。 - 申请必要权限：通知权限、精确闹钟权限，该申请就申请，但别滥用。
- 使用 FCM 高优先级消息：这是目前最可靠的唤醒方式，但注意配额限制。
- 测试你的应用：在开发者选项中，可以手动将应用放入「罕见」桶，模拟最严格的限制环境。
一个小技巧：在 Android 14 上，你可以通过 adb shell am set-standby-bucket <package> rare 命令，强制将你的应用设为「罕见」类别，然后测试后台行为。我每次适配新版本都会这么干一遍。
好了，关于 Android 12 到 14 的电源新特性就聊到这里。这些变化看似复杂，但核心逻辑很简单：系统越来越智能，开发者需要越来越规范。适应它，而不是对抗它。