AOSP CachedAppOptimizer 冻结方案
背景
Android 一直面临一个核心难题：如何优化进程对有限系统资源（如 CPU、电量）的使用，同时保证用户体验。
当进程进入后台后，它们虽不再贡献用户体验，却仍可能消耗资源。传统的杀后台方案虽然节省资源，但会导致用户抱怨（如影响多任务和启动速度）。如今，随着内存容量提升，进程冻结方案（苹果的墓碑机制）成为更优解——它既能保留后台进程（保障快速启动），又能严格限制其 CPU 和电量消耗。
原生方案开关
Google 在android 11 原生代码开始引入进程冻结方案，可能基于代码不稳定考虑，整个功能默认是关闭的，然后在android 12 重新做了一些修改后，默认是打开状态。
可以通过如下方式打开或者关闭原生进程冻结功能：
方式一 开发者选项 “Suspend execution for cached apps”。 可选项一共有三个， Device default, Enabled 和Disabled，android 11 default 是关闭，android 12 default 默认是打开
方式二 adb 命令： adb shell settings put global cached_apps_freezer
以上两种方式都需要重启手机生效
原生进程冻结方案框架图
Framework 上层主要由两个类控制, OomAdjuster 负责计算APP的oom_score_adj，一旦某个APP的adj大于等于CACHED_APP_MIN_ADJ，就会将冻结该进程的工作委托给CachedAppOptimizer去处理，后者跑在独立的线程，然后通过jni层接口调用到cgroup的native层。
cgroup抽象层编译成库libprocessgroup。抽象层通过往cgroup的文件节点写入相应的值，来触发kernel的回调，代码路径system\core\libprocessgroup，具体是往/sys/fs/cgroup///cgroup.freeze 节点写入1冻结，写入0解冻。
最终kernel cgroup机制的freezer控制子系统真正实现了冻结进程的功能，如下所示：
被冻结的进程，会在freeze_schdule中主动放弃CPU使用权限，将CPU让给当运行队列rq中的下一个任务执行，实现的用户进程的无感冻结。
原生冻结例子
应用A打开到前台，使用完后，退到后台，启动应用B，然后A变成前APP级别，adj变成700，然后再打开应用C，这时如果A没有启动服务或者接受广播之类的，就会变成cached级别应用，那么系统就会设置一个10分钟的超时，如果10分钟的时间内，adj的级别没有变化或者没有小于cached级别，系统就会触发冻结A，如果adj变化为小于cached级别，那么就会取消冻结A
原生框架流程
相关代码路径
frameworks/base/services/core/java/com/android/server/am/OomAdjuster.java frameworks/base/services/core/java/com/android/server/am/CachedAppOptimizer.java frameworks/base/services/core/jni/com_android_server_am_CachedAppOptimizer.cpp frameworks/base/core/java/android/os/Process.java frameworks/base/core/jni/android_util_Process.cpp
原生冻结细节
第一步，检查文件锁"/proc/locks"的状态。这是为了防止冻结进程持有文件锁引起死锁。考虑到一些特殊场景下，进程在被冻结的过程中拿住了文件锁，冻结成功后还会再检查一次，发现持有锁就立刻解冻。
第二步，freeze binder，先是处理当前待处理的binder通信请求，如果进程需要处理的binder请求过多导致在100ms内无法完成，则重新在10分钟后再次进行冻结流程。如果该过程在100ms内成功，后面禁掉该进程对同步binder请求的接收和处理，以及对异步binder请求的处理。
第三步，setProcessFrozen，调用抽象层提供的API冻结进程。
第四步，再次检查该进程有没有需要处理的binder请求，有则解冻进程，然后在10分钟后再次触发冻结。这个检查是为一些特殊场景下，进程在被冻结的过程中产生了binder请求。
原生方案不足
