先把结论放在前面：Android 的进程回收是"按优先级从低到高杀"，而优先级完全由"进程里有没有可见界面、有几个、有没有前台服务"决定。 所以保活的本质不是"骗系统"，而是把你的进程维持在有正当理由的高优先级——靠提升优先级而不是靠堆空组件。多进程架构下各进程独立算优先级、独立被回收，这一条决定了"以为多进程就更安全"的误解。
进程优先级与进程回收这题面试里怕只背结论。这篇把来龙去脉和落地场景一起讲清楚。
五档优先级：从高到低
ActivityManager 给每个进程维护一个 oom_score_adj 等级，回收时按这个值从大到小选牺牲品。面试要能报出五档与对应的可见性证据：
| 档位 | 场景 | 有没有可见界面 |
|---|---|---|
| 前台 | 有前台 Activity（或前台服务/前台 Service 通知） | 有，用户正在用 |
| 可见 | 有 Activity 可见但不在最前（如对话框覆盖、后台播放界面） | 有 |
| 服务 | 没界面，但有正在运行的 Service |
无 |
| 后台 | 不可见的 Activity + 有 Service | 无 |
| 缓存 | 没有任何活动组件，进程空转 | 无 |
关键推论：进程里只要有一个前台 Activity，整个进程就是前台的；Service 单独存在只到"服务"档——这就是"后台 Service 容易被杀"和"要开前台服务提升到前台档"的原理。所以"保活"的正确做法是明确告诉系统该进程还有用户在感知的事（前台服务 + 持续通知），而不是靠"起一个空 Service"这种会随系统升级失效的技巧。
最常见的坑是
用空服务拉高优先级保活，系统升级后策略收紧直接失效。
典型写法是启动一个不返回通知的 Service，靠"有 Service 存活"把进程维持在服务档。这类做法的问题是：① 系统在 Android 8 之后对后台启动 Service 有限制，隐式拉活路径被堵；② 厂商 ROM 的清理策略（尤其国内 ROM）会识别"无通知的常驻服务"并强制清理；③ 更实际的问题是这类实现往往在用户手动划掉最近任务后仍在跑，功耗与流量异常，用户投诉后被应用商店下架。
正确的三条替代路径：
<!-- 路径一：确实是用户可见的持续任务 → 前台服务（合规、可解释） -->
<!-- manifest -->
<service
android:name=".SyncService"
android:exported="false"
android:foregroundServiceType="dataSync" />
// 路径二：需要保证完成的延迟任务 → WorkManager（系统调度，不抗杀）
val req = OneTimeWorkRequestBuilder<SyncWorker>()
.setConstraints(Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED).build())
.setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 30, TimeUnit.SECONDS)
.build()
WorkManager.getInstance(context).enqueueUniqueWork("sync", ExistingWorkPolicy.KEEP, req)
// 路径三：需要事件驱动的即时唤醒 → FCM 推送（服务端唤醒，不占常驻资源）
class PushMessagingService : FirebaseMessagingService() {
override fun onMessageReceived(msg: RemoteMessage) {
// 服务端控制下发时机，客户端收到即处理，无常驻进程开销
// 具体同步任务转交 WorkManager，req 复用路径二的定义
WorkManager.getInstance(applicationContext)
.enqueueUniqueWork("sync", ExistingWorkPolicy.REPLACE, req)
}
}
还有一层判断要先做：这个任务真的需要抗回收吗？ 绝大多数需求里答案是否定的——用户下次打开时重新加载一次，成本远低于保活的复杂度与风险。
还有一个更隐蔽的坑：进程优先级与进程回收的坑别靠人记：高频踩坑点做成静态检查或单测断言。 可落地的做法有三条。① CI 里检查清单：android:persistent="true" 只能给系统应用、第三方应用申请了也是被拒；这类"假保活"配置直接扫出来；② Doze 与 App Standby 的真机验证：把应用设为"未使用"并开 Doze，观察关键任务是否被延后到维护窗口；③ 埋点监控：上报"进程被回收后下次冷启动恢复耗时"，这个指标变差就说明状态保存或缓存策略有问题——它是比"进程被杀"本身更值得关注的信号。
还有两个话题经常在这一题里被追问到，且都能体现实际经验。
话题一：Low Memory Killer 与 LMKD 的区别。 传统 Android 的 lowmemorykiller 是按"可用内存阈值"触发、按 oom_score 选进程的；Android 9 之后 Google 用 LMKD（Low Memory Killer Daemon）替换了它，改为按内存压力等级触发（用 PSI 内存压力信息），能更早介入、更精细地选择牺牲品，并且对长期不活跃的应用会主动做内存收缩。这条变化的实际影响是：以前"应用退到后台一段时间内存就被回收"的预期不再成立，系统更倾向于让应用留着但被限制——所以现在"被回收导致数据丢失"的问题变少了，"被限制导致调度延迟、FCM 收不到"的问题变多了。能区分 LMKD 与 lowmemorykiller，是这一题的最新加分点。
话题二：为什么禁止用 android:persistent="true" 保活。 这个属性只能给系统应用申请，普通应用申请了也会被系统忽略。它背后的逻辑是"保活应该是系统对应用真实状态的承认，而不是应用自己声明的意愿"——如果任何应用都能声明自己永不被杀，那系统的内存管理就形同虚设了。这条也解释了为什么厂商 ROM 的清理策略是"按实际使用痕迹判断"而不是"看有没有常驻服务"。
三条高频追问
问：怎么看当前应用的进程优先级？
adb shell dumpsys activity oom（Android 10+ 可加 --oom），或 adb shell cat /proc/<pid>/oom_score_adj。更实用的做法是开发生成 adb shell dumpsys activity processes | grep <package> 看 adj。注意 oom_score_adj 是系统内部字段，第三方应用读不到，只能在 adb 环境查，这也是这类问题难以自动化断言的原因之一。
问：内存泄漏会让进程更容易被回收吗？
方向相反：泄漏会抬高内存占用，让进程更接近被杀的阈值。系统按"可用内存"决定是否触发回收，而一个长期泄漏的进程占着几 MB 不放，等于让系统更早动手。所以泄漏排查与"抗回收"是同一个问题的两面——减少内存占用比保活手段更根本。
问：多进程能提高存活率吗？
不能靠"多"来提高，反而可能更差。① 每个进程独立算优先级、独立被回收，主进程被杀了子进程未必死，子进程被杀了主进程未必受影响——这是"可用性隔离"而非"存活率提升"；② 每个进程有独立堆（默认 32MB～256MB，按设备与进程数分配），多进程会显著抬高整体内存占用，反而让系统在内存紧张时更快出手；③ Application 在每个进程都会初始化一次，初始化里的重逻辑会被放大成本。结论：多进程用于"隔离崩溃"或"独立生命周期"（如推送进程），不用于保活。
问：Doze 和 App Standby 是什么关系？
Doze 是 API 23+ 引入的深度休眠（屏幕关闭、静止、拔充电器一段时间后触发），系统会限制网络访问、暂停后台任务、限制 Alarm；App Standby 是 API 24+ 引入的"闲置判定"（按用户使用频次给应用分档），用于批量 defer 任务。共同点是都把后台任务的执行推迟到维护窗口，所以"能立即执行"的需求必须走前台服务或推送，WorkManager 天然接受延迟。
落到项目里怎么做
一条能直接落地的规则：先用"下次进入重新加载"证明不需要保活，再考虑前台服务，最后才想别的。 这个顺序能把绝大多数保活需求消解掉。
配套实践三条：① 把"抗回收"需求收口到明确的一两类（通常是播放、定位上传、下载），其余一律用缓存 + 快速恢复替代；② 冷启动与进程恢复路径做端到端测试——杀掉进程后重新进入，状态与数据要正确恢复；③ 上报"冷启动耗时"与"状态恢复失败率"两个指标，它们的改善比任何保活技巧都更能说明问题。
给正在准备面试的你
这题的答法要立住"优先级由可见性决定，所以保活要靠正当理由"。推荐这条线：先报五档优先级与各自的可见性证据 → 推出关键结论（Service 单独存在只到"服务"档，需前台服务才到"前台"档）→ 于是"空服务保活"自然被否定 → 给出三条合规替代（前台服务 / WorkManager / 推送）→ 补追问层（oom_score_adj 怎么查、泄漏让进程更接近阈值、多进程是隔离不是保活、Doze 与 App Standby 的共同点）。能从"可见性 → 优先级 → 回收"的因果链讲完，这题就是满分。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：AndroidManifest-深度解析：组件声明的门道
下一篇预告：View-绘制流程：measure、layout、draw-三部曲
有任何问题欢迎在评论区留言交流。
