了解 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 机制,但针对移动设备的特点进行了优化。
回收流程
通过回收流程能够概括为:分层评估 + 按需回收。下图描绘了一个应用从进入后台到可能被回收的历程,以及体系中各模块的分工: