简介：一份面向Android开发者的后台服务保活资料包，围绕如何降低进程被系统回收风险、如何在进程被杀后重新拉活等难题，整理了前台服务、绑定服务、JobScheduler/WorkManager、AlarmManager、广播拉活等多种实现思路。包内KeepLiveDemo工程包含5个Java源文件、8个XML布局与配置、5张演示图片、Gradle构建脚本及README说明，共22个文件，压缩包约45KB，目录结构清晰，便于对照关键代码进行调试和二次开发。对于需要提升推送到达率、延长任务执行时间、或在特定系统事件后自动恢复服务的应用场景，可直接作为基础模板修改使用。已有5108人学习下载，适合正在处理服务存活率、兼容Doze模式与App Standby限制的中级Android开发人员。通过学习这份示例，可快速掌握进程优先级提升、粘性意图恢复、推送唤醒等常见保活手段，并理解各方案背后的系统机制与取舍，例如通过startForeground提升服务优先级、利用WorkManager设定延迟任务、监听BOOT_COMPLETED广播触发重启等，都能在工程中找到对应代码实现，从而在真实项目中合理平衡服务持续运行与系统资源占用。 做Android开发的朋友，基本都遇到过这个场景：App一切到后台，过几分钟再点开，发现进程没了，数据要重新加载，音乐停了，导航断了，消息也不推送了。用户第一反应就是骂App垃圾，但搞过的人心里都清楚，这锅不全在App身上——从Android 6.0的Doze到Android 12的“休眠应用”，再到各家厂商激进的后台清理策略，系统对后台的管控一年比一年狠。这篇文章就围绕“Android App如何保证后台服务不被杀死”这个核心问题，把进程优先级、内存回收、Doze机制、厂商ROM策略这些底层逻辑讲清楚，再给出真正能落地、合规的实操方案，包括前台服务、WorkManager、跨进程守护和引导用户加白名单。适合正在做IM、音乐、导航、运动健康这类强后台需求的App开发者参考，也适合刚接触后台任务、对保活方案一头雾水的新手。
1. 项目背景与核心思路
1.1 保活的本质：不是“不死”，而是“死得体面”
先说一个最容易踩的误区：很多人一上来就想找“怎么让进程永远不被杀”的偏方，比如1像素Activity、锁屏清理、反复拉活互相守护。这类方案我不是没试过，实测下来要么在Android 8.0之后被系统直接按死，要么被应用商店检测到下架，要么白耗电导致用户主动卸载。真正的保活思路应该是：让系统认为你的进程“值得留”，并且在被清理后能快速恢复，而不是跟系统玩猫鼠游戏。
Android后台被杀的根源在于，系统在内存不足或电量紧张时，要根据一套优先级规则回收进程。你的App能不能活下来，取决于它处于哪一级优先级，而不是你用了多少“黑科技”。所以做保活之前，先要把Android的进程生杀大权理解透。
1.2 方案选型：合规优先，引导用户比对抗系统更有效
我做了几年Android之后最大的体会是：在国产ROM上，技术手段的边际效应非常低。你代码写得再漂亮，小米的MIUI、华为的EMUI、vivo的OriginOS照杀不误，因为这些系统有自己的一套后台管理策略，App只能被动适配。
所以我的整体思路分三层：第一层，用系统官方推荐的API，比如前台服务、WorkManager，把进程优先级抬高；第二层，通过合理的架构设计，如多进程隔离、广播拉活、账号同步拉活，把被杀的恢复时间压缩到最短；第三层，引导用户把你App加入电池优化白名单、自启动白名单，这层虽然不算纯技术手段，但实测是保活效果最明显的。这篇文章会按这三层逐层拆开讲。
2. 后台服务的生死逻辑：系统凭什么杀你
2.1 进程优先级与LMK回收机制
Android系统里的进程，从系统的角度看并不是“平等”的。系统根据进程当前做的事，把进程划分成五个优先级层级，从高到低大致是：
| 优先级 | 进程类型 | 典型场景 | 被杀概率 |
|---|---|---|---|
| 1 | 前台进程 | 正在交互的Activity、正在执行onStartForeground的服务 | 极低 |
| 2 | 可见进程 | 被前台Activity绑定、正在显示但无焦点的界面 | 低 |
| 3 | 服务进程 | 已启动的Service，且未转到前台 | 中 |
| 4 | 后台进程 | 已退到后台的Activity | 高 |
| 5 | 空进程 | 无活跃组件的进程 | 最高 |
每一层进程都有一个oom_adj值，数值越大表示优先级越低、越容易被杀。Low Memory Killer（LMK）就是根据这个值来决定“杀谁”的。我在开发过程中常用的一个排查命令是adb shell cat /proc/[pid]/oom_adj，可以直接看到自己App当前被系统标记的adj值。如果你发现它的值一直在10以上，说明系统随时可能回收你的进程，这时候再谈什么保活都是空话。
2.2 Doze模式与应用待机的叠加限制
Android 6.0引入的Doze模式是很多老开发的噩梦。设备充电且静止不动一段时间后，系统进入睡眠状态，会暂停网络访问、延迟JobScheduler任务、禁止WakeLock，让你的后台任务几乎全部失效。Android 7.0又加了“应用待机”机制：如果用户长期不打开某个App，系统会把它标记为待机状态，后台任务和推送全部被限制。
到了Android 8.0，连Service本身都被限制了：startService()在后台直接抛IllegalStateException，必须改成startForegroundService()并在5秒内调用startForeground()，否则直接崩。Android 9.0的App Standby Buckets把应用分成活跃、工作、频繁、罕见四类；Android 12的“休眠应用”机制甚至会在后台强制停止应用。这一整套组合拳下来，想靠裸Service在后台一直跑，已经不现实了。
2.3 厂商ROM的“第二套规则”
如果说Google原生的机制还能通过官方API去适配，那国产ROM就是“另一个世界”。MIUI有“省电策略”、EMUI有“应用启动管理”、ColorOS有“智能后台管理”，它们不只拦截Service，还会拦截广播、限制WakeLock、杀掉互相拉起的进程。我做双进程守护方案的时候，在原生Android上跑得好好的，放到某些国产机型上，一锁屏不到十分钟两个进程全被清掉。
注意：厂商ROM的限制通常不在AOSP代码里，而是写在厂商自己的系统框架层，比如MIUI的
MemInfo里会有额外的进程清理逻辑，这些在公开文档里查不到，只能通过实测去总结规律。
3. 核心保活方案落地实操
3.1 前台服务：最正统、最有效的方案
如果你的App有音乐播放、导航、运动记录这类需要长时间运行的功能，最标准的方案就是给Service挂一个常驻通知，变成前台服务。前台服务属于“前台进程”级别，oom_adj值非常低，基本不会被杀。Android 8.0之后要使用startForegroundService()启动，然后在Service的onCreate()或onStartCommand()里5秒内调用startForeground()。
class MusicService : Service() { override fun onCreate() { super.onCreate() val channelId = "music_playback" val channel = NotificationChannel( channelId, "音乐播放", NotificationManager.IMPORTANCE_LOW ).apply { description = "音乐播放控制" setShowBadge(false) } getSystemService(NotificationManager::class.java).createNotificationChannel(channel) val notification = NotificationCompat.Builder(this, channelId) .setContentTitle("正在播放：夜曲") .setContentText("周杰伦") .setSmallIcon(R.drawable.ic_music_note) .setOngoing(true) .build() startForeground(NOTIFICATION_ID, notification) } }这段代码看着简单，实际操作里有几个细节要特别注意。Android 13开始，通知需要动态申请POST_NOTIFICATIONS权限，如果用户拒绝授权，前台服务通知会不显示，但服务本身还是能启动。Android 14更是强制要求声明foregroundServiceType，如果你在后台启动服务但没声明类型，系统会直接抛ForegroundServiceStartNotAllowedException。
<manifest> <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" /> <uses-permission android:name="android.permission.POST_NOTIFICATIONS" /> <service android:name=".MusicService" android:foregroundServiceType="mediaPlayback" android:exported="false" /> </manifest>3.2 WorkManager：延迟任务的正确打开方式
很多开发想把“定时上传数据”“每天同步一次”这类需求做成保活Service，这其实属于过度设计。这类不需要持续运行的任务，用WorkManager就够了。WorkManager会根据系统电量、网络状态、设备待机情况自动选择执行时机，而且兼容到API 14，比裸写JobScheduler省心太多。
val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(15, TimeUnit.MINUTES) .setConstraints( Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build() ) .build() WorkManager.getInstance(context).enqueueUniquePeriodicWork( "sync_worker", ExistingPeriodicWorkPolicy.KEEP, syncRequest )这里有个容易踩的坑：PeriodicWorkRequest的周期最短是15分钟，这是系统限制，你设10分钟它会自动调整到15分钟。而且WorkManager不保证精确按时执行，它的设计哲学是“在满足条件的前提下尽快执行”，不是“严格按周期执行”。所以如果你的业务真的需要精确到秒的后台行为，比如IM实时消息，那还得走前台服务加推送通道的方案。
3.3 跨进程守护与拉活：双进程的“野路子”还有效吗
双进程守护是很多老Android开发记忆里的“神技”：两个进程互绑，A死了B拉活A，B死了A拉活B，实现方式一般通过AIDL绑定Service，利用Binder的linkToDeath监听对方死亡。我当年也是这么干的，在Android 5.0、6.0时代效果确实不错。但Android 8.0之后，后台绑定服务受限，这个方案在原生系统上基本废了。
实测下来，双进程守护如今更多是配合推送服务的“保活辅助”。比如极光推送、友盟推送，就是用类似方式提高推送到达率。它能保证的是“进程被系统杀掉后，在特定时机（比如屏幕解锁、网络切换、开机）收到广播并重新拉起”，而不是“永远不被杀”。如果你要做的业务是IM类或资讯类，需要保证消息秒级到达，建议优先靠厂商推送通道（小米推送、华为推送、OPPO推送），再配合常驻前台服务，而不是指望双进程守护。
// 守护进程中的Binder死亡监听 private val deathRecipient = object : IBinder.DeathRecipient { override fun binderDied() { // 主进程死亡，尝试重新绑定或拉起 reconnect() } } override fun onServiceConnected(name: ComponentName?, binder: IBinder?) { super.onServiceConnected(name, binder) binder?.linkToDeath(deathRecipient, 0) }3.4 引导用户加白名单：保活效率最高的“软方案”
做保活这么久，我最大的心得是：技术方案做得再好，不如用户一个设置。把App加进电池优化白名单、自启动白名单、后台运行白名单，比任何代码都管用。系统提供了ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS这个Intent，可以直接引导用户跳过电池优化。
if (pm.isIgnoringBatteryOptimizations(packageName)) { // 已经加入白名单 } else { val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply { data = Uri.parse("package:$packageName") } startActivity(intent) }但要提醒的是，这个Intent并非在所有ROM上都有效，部分国产ROM会把“忽略电池优化”和“自启动管理”分开处理，你得再引导用户去系统设置里手动开启。这里比较稳妥的方式是把引导流程做成应用内的“保活指南”，一步步告诉用户点哪里、开哪个开关，同时给出“是否已开启”的检测接口，每次启动时检测一次并提醒用户。这比后台代码做什么都直观。
4. 常见问题与排查技巧实录
4.1 为什么我加了前台服务，App还是被杀
这是我在网上被问得最多的问题。很多人加了startForeground()就以为万事大吉，结果跑到国产ROM上还是被杀，原因大概率出在以下几个方面。
| 现象 | 可能原因 | 排查方式 |
|---|---|---|
| 进程被清理，但通知还在 | 通知渠道被系统识别为不重要的通知，进程被判为可回收 | 检查通知渠道重要性是否为IMPORTANCE_LOW以上 |
| 锁屏几分钟后被杀 | 被厂商省电策略清理，前台服务类型不被识别 | 检查是否声明了foregroundServiceType |
| 收到推送但进程没启动 | 开机广播受限，应用被系统标记为“待机”状态 | 检查是否被加入系统的“特殊访问权限”白名单 |
| 运行中突然崩溃 | 可能触发了Android 8.0后台Service限制 | 查看logcat中是否有IllegalStateException |
排查的时候，我建议先用adb shell dumpsys activity services看一下自己的Service是不是处于started状态，再用adb shell cat /proc/[pid]/oom_adj看进程优先级。如果adj值正常在0~2之间，服务状态也是started，但进程还是被杀，那基本就是厂商ROM的“额外管理”在起作用，这种情况除了引导用户加白名单，谁也没办法。
4.2 保活的“度”在哪里：什么时候该停手
最后聊一个很多人忽略的问题：保活不是越强越好。我做项目的时候，经常看到有人把保活方案搞得极其激进：多个进程互相守护、定时拉活、后台频繁唤醒。这样做的结果往往是：用户手机电量尿崩、流量耗费暴涨，最后被用户手动卸载，甚至被应用商店以“恶意消耗资源”的名义下架。Android系统本身对后台的限制就是“用户体验优先”的思路，你的App想长期待在后台，前提一定是能为用户提供长期价值。
我的原则是：能用前台服务解决的，就别用多进程；能用WorkManager解决的，就别用前台服务；需要实时消息的，先考虑厂商推送通道；能引导用户加白名单的，就别在代码里搞对抗。把保活做好，最终是让App和系统“和平共处”，而不是“你死我活”。
4.3 排查工具与自查清单
这里分享一套我常用的自查流程：先确认目标机型是原生Android还是国产ROM，再判断App的业务场景是需要持续运行、定时运行还是实时接收消息。持续运行对应前台服务，定时运行对应WorkManager，实时接收消息对应推送通道加双进程守护辅助。然后把服务声明、通知渠道、权限、电池优化白名单逐个检查一遍，基本能解决九成以上“后台被杀”的问题。
# 查看自己App的进程状态 adb shell ps -A | grep your.package.name # 查看Service运行状态 adb shell dumpsys activity services your.package.name # 查看进程adj优先级 adb shell cat /proc/[pid]/oom_adj # 查看最近被杀进程的记录 adb shell dumpsys activity processes | grep "your.package.name"个人经验是，做后台保活一定不要在真机上“我觉得没问题”就完事，同一套代码在原生Android和国产ROM上的差异极大，发布前至少要在两三台不同品牌的真机上做锁屏、后台切换、内存压力测试。只有把厂商ROM的行为摸透了，才能针对性地设计保活策略，否则代码写得再华丽，用户一锁屏就原形毕露。
在实际项目里，我越来越觉得保活这件事，技术只是其中一部分，更重要的是对用户场景的理解和对系统的敬畏。如果你的App确实需要常驻后台，那就老老实实做前台服务并给出合理的用户引导；如果只是定时同步类需求，WorkManager已经足够了。别总想着对抗系统，顺着系统的规则来，反而能活得最久。
本文还有配套的精品资源，点击获取
