了解 Android 应用在后台的回收机制，能帮助大家更好地理解应用的行为。简单来说，Android 普通应用切换到后台后，并没有一个固定的回收时间。其回收完全取决于架构当前的内存压力和应用的优先级。
回收时间不是一个定时器，而是由体系根据当前可用内存的紧张程度和应用进程的重要性（优先级） 动态决定的。
系统内存充足时，你的应用可能在后台存活很久；而内存紧张时，高优先级的应用会更晚被回收。
详细解释：
影响回收时间的因素非常多，首要包括：
设备物理内存（RAM）大小：内存越小的设备，系统越激进，后台应用存活时间越短。
当前系统内存压力：用户同时运行的应用越多，系统内存越紧张，回收越快。
应用进程的优先级（最重要因素）：
前台进程 (Foreground Process)：用户正在交互的App（如正在使用的Activity、前台Service）。几乎不会被回收，除非内存极端不足。
可见进程 (Visible Process)：不在前台但仍对用户可见（如一个Activity上弹出一个非全屏的对话框）。优先级很高，不易被回收。
服务进程 (Service Process)：托管了已启动服务的应用（如正在播放音乐的后台服务）。优先级中等，内存紧张时会被回收。
“普通应用”切后台后最常见的状态，优先级最低，最先被回收。就是后台进程 (Cached/Background Process)：完全进入后台，没有任何活跃组件（Activity完全不可见，Service已停止）。这
空进程 (Empty Process)：不囊括任何活跃组件的缓存进程，保留它只是为了下次启动更快。最先被回收。
厂商定制（非常重要）：不同手机厂商（如华为、小米、OPPO、vivo）都有自己的省电策略和后台管理机制。它们可能会比原生Android框架更激进地杀死后台进程以节省电量，这会导致你的应用在后台存活时间大大缩短，甚至几分钟内就被“清理”。
总结一下时间范围：一个纯粹的后台进程（没有任何服务等活跃组件），在内存充足的旗舰机上可能存活几小时甚至更久，但在内存紧张的中低端机或受到厂商省电策略影响时，可能几分钟到半小时内就会被回收。
⚙️ 回收机制与负责模块
是体系的哪个模块负责回收？
关键负责回收应用进程的模块是 Linux内核中的 Low Memory Killer (LMK) 驱动。
但整个决策流程是由 用户空间的系统服务 ActivityManagerService (AMS) 和 LMK 协同工作完成的。
ActivityManagerService (AMS)：
归属：frameworks/base/services/core/java/com/android/server/am/
职责：它是Android系统管理的“大脑”。它负责管理四大组件（Activity, Service, BroadcastReceiver, ContentProvider）的生命周期，并维护所有应用进程的优先级列表（OOM_ADJ）。
它决定“该杀谁”。AMS会根据应用组件的状态（如是否有Activity可见、是否有Service在运行）动态计算每个进程的 oom_adj_score（Out Of Memory Adjustment值）。这个分数值越高，进程优先级越低，越容易被杀。
Low Memory Killer (LMK) 驱动：
归属：Linux内核的一部分（通常是 drivers/staging/android/lowmemorykiller.c 或类似路径）。
职责：它监听内核的内存压力事件。当系统可用内存降到某个阈值时，它被触发。
它负责“动手”。LMK会检查AMS预先设置好的oom_adj分数阈值，然后找到分数高于阈值且分数最高的进程（即优先级最低的进程），将其杀死，释放其占用的内存。
关系可以便捷理解为：
AMS 是 法官，它根据法律（优先级规则）给每个犯人（进程）判刑（贴上oom_adj标签）。
LMK 是 刽子手，它会在资源不足（饥荒）时，根据法官设定的处决标准（阈值），从刑期最重（oom_adj分数最高）的犯人开始处决。
Android 的进程回收重要涉及两个层次：
- Application Framework 层：负责管理应用组件的生命周期（如 Activity、Service），并在适当时机通知内核层某个进程可以被回收。
- Linux 内核层：这是实际执行进程回收（杀死） 的“执法部门”，其核心是 Low Memory Killer (LMK) 驱动。LMK 基于 Linux 内核的 OOM Killer 机制，但针对移动设备的特点进行了优化。
回收流程
通过回收流程能够概括为：分层评估 + 按需回收。下图描绘了一个应用从进入后台到可能被回收的历程，以及体系中各模块的分工：