Android JobIntentService：一个曾经用来兼容后台任务的过渡方案
在 Android 后台任务体系里，JobIntentService 是一个很有时代感的类。
它出现的背景是：以前我们经常用 IntentService 来处理后台任务，比如上传日志、同步数据、处理广播后的耗时操作。但从 Android 8.0 开始，系统加强了后台执行限制，普通后台 Service 不能再像以前那样随意运行。于是 JobIntentService 出现了，它试图在新旧系统之间做一层兼容。
不过要先说结论：JobIntentService 现在已经废弃，官方推荐使用 WorkManager 来处理可延迟、需要可靠执行的后台任务。Android 官方文档
一、JobIntentService 是什么
JobIntentService 本质上是一个特殊的 Service，它用来处理一批通过 Intent 投递进来的任务。
它的特点是：
外部通过
enqueueWork()提交任务。每个任务最终会进入
onHandleWork()。onHandleWork()运行在后台线程，不需要开发者自己开线程。多个任务会按顺序执行。
任务执行完之后，Service 会自动结束。
可以把它理解为：
JobIntentService = IntentService 的兼容升级版 + JobScheduler 的包装层
它不是一个全新的后台任务框架，而是一个兼容方案。
二、为什么需要 JobIntentService
早期 Android 开发里，IntentService 很常见。
比如用户点击“同步数据”，我们可以这样做：
启动一个
IntentService。在后台线程执行网络请求。
执行完成后自动停止。
这套模型很简单，但是 Android 8.0 之后，后台服务被限制了。如果 App 已经进入后台，再直接 startService()，可能会失败，甚至抛异常。
于是 JobIntentService 做了一个兼容判断：
官方文档也说明了这一点：Android O 及以上会通过 JobScheduler.enqueue 分发任务，旧版本则使用 Context.startService。Android 官方文档
三、它的执行流程
这个流程说明了 JobIntentService 的核心价值：开发者只写一套代码，它内部根据系统版本选择不同的执行方式。
四、基本使用方式
如果是维护老项目，可能还会看到类似代码。
先定义一个 JobIntentService：
class UploadLogService : JobIntentService() {
override fun onHandleWork(intent: Intent) {
val logPath = intent.getStringExtra("log_path")
// 这里已经是后台线程，可以执行耗时任务
uploadLog(logPath)
}
private fun uploadLog(path: String?) {
// 执行日志上传
}
companion object {
private const val JOB_ID = 1001
fun enqueue(context: Context, intent: Intent) {
enqueueWork(
context,
UploadLogService::class.java,
JOB_ID,
intent
)
}
}
}
然后在外部提交任务：
val intent = Intent(context, UploadLogService::class.java)
intent.putExtra("log_path", "/sdcard/app/log.txt")
UploadLogService.enqueue(context, intent)
在 AndroidManifest.xml 中声明：
<service
android:name=".UploadLogService"
android:permission="android.permission.BIND_JOB_SERVICE"
android:exported="false" />
这里要注意：android.permission.BIND_JOB_SERVICE 主要是为了兼容 Android 8.0 之后内部走 JobScheduler 的情况。
五、onHandleWork 的特点
onHandleWork() 是 JobIntentService 最核心的方法。
它有几个重要特点：
官方文档也提醒，当它作为 Job 执行时，会受到 Job 最大执行时长限制；如果任务太长，可能会被系统停止，之后再重新调度。Android 官方文档
六、JobIntentService 和 IntentService 的区别
IntentService 在 API 30 被废弃，官方说明它会受到 Android 8.0 后台执行限制影响，并建议考虑使用 WorkManager。Android 官方文档
七、为什么 JobIntentService 也被废弃了
原因很简单：它只是一个过渡方案，不是最终方案。
它解决了 IntentService 在 Android 8.0 之后的一部分兼容问题，但后台任务本身越来越复杂：
是否需要网络？
是否只在充电时执行？
是否需要失败重试？
是否需要链式任务？
是否需要观察任务状态？
是否需要跨进程、跨重启继续执行？
是否需要和前台服务配合？
这些能力不是 JobIntentService 擅长的。
所以官方把推荐方向转向了 WorkManager。WorkManager 是官方推荐的持久性后台任务库，可以设置约束、观察状态、组织任务链，并且底层会根据系统版本选择合适的调度方式。Android 官方文档
八、现在应该用什么替代
现在可以这样选型：
官方后台任务指南也提到，大多数后台任务场景推荐使用 WorkManager；如果任务必须立即执行且不应被中断，则可以考虑前台服务，但前台服务需要显示通知，也受到更多限制。Android 官方文档
九、用 WorkManager 改写思路
以前的 JobIntentService 代码通常是这样：
UploadLogService.enqueue(context, intent)
迁移到 WorkManager 后，思路会变成：
class UploadLogWorker(
context: Context,
params: WorkerParameters
) : Worker(context, params) {
override fun doWork(): Result {
val logPath = inputData.getString("log_path")
return try {
uploadLog(logPath)
Result.success()
} catch (e: Exception) {
Result.retry()
}
}
private fun uploadLog(path: String?) {
// 上传日志
}
}
提交任务：
val request = OneTimeWorkRequestBuilder<UploadLogWorker>()
.setInputData(
workDataOf("log_path" to "/sdcard/app/log.txt")
)
.build()
WorkManager.getInstance(context).enqueue(request)
相比 JobIntentService，WorkManager 的优势是可以很自然地支持约束条件：
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.build()
val request = OneTimeWorkRequestBuilder<UploadLogWorker>()
.setConstraints(constraints)
.build()
也就是说，JobIntentService 更像是“收到任务就尽量执行”，而 WorkManager 更像是“告诉系统这个任务需要什么条件，系统在合适的时候可靠执行”。
十、JobIntentService 适合怎么理解
今天学习 JobIntentService，重点不是为了新项目继续使用它，而是为了理解 Android 后台任务演进。
它代表了一个阶段：
这个演进过程背后的核心思想是：
Android 不希望 App 在后台无限制运行任务，而是希望任务交给系统统一调度，从而控制功耗、性能和用户体验。
总结
JobIntentService 是 IntentService 之后的一个兼容方案。它通过一套统一 API，在 Android 8.0 以下使用 startService()，在 Android 8.0 及以上使用 JobScheduler.enqueue()，让开发者可以相对平滑地处理后台任务。
但是它现在已经废弃，不适合作为新项目的后台任务方案。
如果你是在维护老项目，理解它很有必要；如果你是在写新代码，应该优先考虑 WorkManager。只有当任务必须马上执行、用户明确感知且不希望被系统中断时，才考虑前台服务。
Android JobIntentService：一个曾经用来兼容后台任务的过渡方案
https://lautung.com/archives/JWSD81L1
评论