第2章 后台任务调度背景：演进、API级别与兼容性

2.1 边界与职责

Android 后台任务调度经历了从简单定时到智能弹性执行的演进。本章从组件职责和API级别兼容性两个维度，厘清各方案在生态系统中的位置。核心边界划分如下：

• AlarmManager：仅负责定时唤醒，不关心任务类型或重试策略。
• Service（长期后台）：无调度逻辑，完全由开发者控制生命周期，易被系统杀死。
• JobScheduler（API 21+）：系统级调度框架，按约束（网络、电量等）合并执行，但低版本不可用。
• Firebase JobDispatcher（已废弃）：Google 服务层兼容方案，依赖 Google Play Services。
• WorkManager（API 14+）：Jetpack 组件，向下兼容 JobScheduler 与 AlarmManager，提供统一调度实体。

2.2 Android 后台调度演进时间线

2.3 数据流与控制流对比

以“上传日志文件”为例，对比 JobScheduler 与 WorkManager 的任务生命周期：

• JobScheduler 控制流： 应用创建 JobInfo → 提交至 JobScheduler → 系统在满足约束时回调 onStartJob() → 应用执行 → 返回 true 则系统保持唤醒锁，执行完毕后调用 jobFinished() → 系统释放。
• WorkManager 控制流： 应用创建 OneTimeWorkRequest → enqueue → WorkManager 内部判断 API 级别 → 底层委托给 JobScheduler（API 21+）或 AlarmManager+BroadcastReceiver（API 14-20）→ 系统触发 Worker.doWork() → 返回 Result.success/failure → WorkManager 自动处理重试或链式后继。

关键差异：WorkManager 将调度策略与底层实现解耦，开发者无需感知 API 版本差异。

2.4 内联 SVG：任务调度演进对比图

2.5 选型权衡与兼容性矩阵

以下权衡点直接影响架构决策：

2.6 落地步骤与验收标准

• 步骤1：评估最小支持版本 — 若 minSdk < 21，直接选 WorkManager；若 minSdk ≥ 21 且无持久化需求，可选用 JobScheduler。
• 步骤2：引入 WorkManager 依赖 — 在 build.gradle 中添加 androidx.work:work-runtime-ktx:2.9.0。
• 步骤3：定义 Worker 子类 — 实现 doWork()，返回 Result.success/failure。
• 步骤4：创建约束与请求 — 通过 Constraints.Builder() 设置网络、电量等约束。
• 步骤5：提交调度 — WorkManager.getInstance(context).enqueue(workRequest)。

验收标准：

• 在 API 14、21、30 模拟器上分别执行同一测试任务，任务均能被调度并完成。
• 应用杀死后重启，任务自动恢复（WorkManager 持久化特征）。
• Doze 模式下任务延迟不超过最大允许窗口（15分钟）。