Android 12+ 内存新特性：App Hibernation，Memory Advice API，后台限制增强
Android 12 这一版，说实话，在内存管理上动了大手术。我当年刚接触这些新特性时，第一反应是「Google 终于要对那些乱吃内存的后台应用动手了」。你想想看，用户手机里装了几百个 App，大部分其实就用一两次，结果它们一直在后台占着内存，系统能不卡吗？
这一章，我们就来聊聊 Android 12 引入的三个核心内存机制：App Hibernation、Memory Advice API，以及后台限制增强。这三板斧砍下去，系统内存的利用率确实提升了一大截。
App Hibernation：让不用的 App 彻底「冬眠」
什么叫 App Hibernation？说白了，就是系统检测到某个 App 你已经很久没碰了，就把它整个「冷冻」起来。不只是杀掉进程，而是把它的存储空间都做一层优化，连缓存文件都可能被清理掉。
我记得在 Android 11 及之前，App 只要被用户打开过一次，它就能在后台保留各种权限和缓存。哪怕你三个月没用它，它依然能偷偷跑点任务。这合理吗？不合理。
Android 12 的 Hibernation 机制，触发条件是这样的：
- App 在后台没有任何活动，持续数周
- 用户没有主动启动该 App
- 系统资源紧张时，会优先把「冬眠」候选 App 列入清理名单
一旦 App 进入 Hibernation 状态，系统会做三件事：
- 撤销运行时权限——比如定位、相机、麦克风这些敏感权限，全部收回
- 清除缓存文件——临时文件、图片缓存等，统统删掉
- 停止所有 JobScheduler 和 AlarmManager 任务——别想再偷偷唤醒
核心要点：Hibernation 不是简单的「杀进程」，而是对 App 的存储状态和权限状态做了一次彻底的「归零」操作。用户下次再打开这个 App，系统会重新初始化，就像第一次安装后启动一样。
我在项目里遇到过一个问题：有个社交 App 的用户反馈说「为什么我几个月没打开，再进去发现通知权限被关了？」。嗯，这就是 Hibernation 在起作用。用户其实不反感这个机制，反感的是「没人告诉他权限被改了」。所以，如果你的 App 涉及敏感权限，最好在启动时检测一下权限状态，主动引导用户重新授权。
Memory Advice API：系统给你「递纸条」
这个 API 是我个人非常喜欢的一个设计。以前，App 想知道系统内存紧不紧张，只能靠 onTrimMemory() 回调。但这个回调有个问题——它太「滞后」了。系统都快撑不住了才通知你，你能做的只有「赶紧释放」，没有预判空间。
Android 12 引入了 MemoryAdvice 这个 API。它不是一个回调，而是一个可以主动查询的接口。你可以随时问系统：「哥们，现在内存情况怎么样？我该不该省着点用？」
用法很简单：
// 获取 MemoryAdvice 实例
MemoryAdvice memoryAdvice = MemoryAdvice.getContext(context);
// 查询当前内存状态
MemoryState state = memoryAdvice.getMemoryState();
if (state == MemoryState.CRITICAL) {
// 内存极度紧张，赶紧释放大对象
releaseLargeCaches();
} else if (state == MemoryState.LOW) {
// 内存偏低，可以适当降级
reduceImageQuality();
} else {
// 内存充裕，正常使用
}
这个 API 的好处是什么？它给了 App 一个「主动决策」的机会。比如你在做一个图片编辑 App，用户正在编辑一张大图。如果系统告诉你内存已经 LOW 了，你就可以提前把历史版本压缩一下，而不是等到 OOM 崩溃了再后悔。
我的建议：不要只在 onTrimMemory() 里做内存释放。把 MemoryAdvice API 作为一个「定期巡检」的手段，比如每 30 秒查一次，或者在做大内存操作前查一次。这样你的 App 会更「聪明」。
后台限制增强：系统越来越「强势」了
Android 12 对后台的限制，可以说是「层层加码」。我总结了一下，主要有这几个变化：
| 限制项 | Android 11 及之前 | Android 12+ |
|---|---|---|
| 前台服务限制 | 允许大部分后台启动前台服务 | 禁止从后台启动前台服务（除白名单场景） |
| AlarmManager 唤醒 | 允许精确唤醒 | 非白名单 App 只能使用近似唤醒 |
| JobScheduler 频率 | 无严格限制 | 根据 App 使用频率动态调整配额 |
| 广播接收器 | 大部分隐式广播可接收 | 大量隐式广播被移除或限制 |
你看这个表格，Google 的思路很清晰：用户不常用的 App，就别想在后台搞事情。我曾经调试过一个 App，它在 Android 11 上能正常接收网络变化广播，到了 Android 12 上就收不到了。查了半天才发现，那个广播在 Android 12 里已经被标记为「后台不可接收」了。
避坑指南：如果你的 App 依赖后台广播或前台服务来维持功能，一定要在 Android 12 上做充分测试。我曾经遇到一个即时通讯 App，因为前台服务被限制，导致消息接收延迟了十几分钟。解决方案是改用 Firebase Cloud Messaging（FCM）高优先级推送，而不是自己维护长连接。
知识体系总览
为了让你更直观地理解这三个特性之间的关系，我画了一张图：
从这张图你能看出来，这三个特性其实是「分层治理」的思路。Hibernation 管的是「死 App」，Memory Advice 管的是「活 App」，后台限制管的是「所有 App 的行为边界」。三层叠加，系统内存的掌控力就上来了。
实际项目中的适配建议
说了这么多理论，最后给点实在的。如果你现在正在维护一个 Android 12+ 的 App，我建议你做这几件事：
- 检查你的前台服务——看看有没有从后台启动前台服务的场景。如果有，要么改成 FCM 推送，要么申请白名单（但白名单很难过审）。
- 集成 Memory Advice API——至少在你的图片加载、视频播放、大文件处理这些模块里加上内存状态查询。别等到 OOM 了再处理。
- 测试 Hibernation 后的行为——用
adb shell am set-hibernation命令手动触发 Hibernation，然后打开你的 App，看看权限恢复、数据加载是否正常。 - 关注
android:allowWhileIdle的变化——Android 12 对setAndAllowWhileIdle()也做了限制，非白名单 App 每小时只能触发一次。
一个小技巧：你可以用 adb shell dumpsys meminfo 查看当前系统内存压力等级。配合 Memory Advice API 一起用，调试起来会顺手很多。
嗯，Android 12 的这些内存新特性，说白了就是逼着开发者「更规矩」地使用系统资源。以前那种「我就要在后台跑服务，你能拿我怎么样」的时代，已经过去了。适应这些变化，你的 App 才能在 Android 12+ 上活得更好。
公众号:蓝海资料掘金营，微信deep3321