1. 课程总览与目标
本课程旨在帮助 Android 开发者从架构层面完整理解 WorkManager 与 JobScheduler 的差异，并掌握在实际项目中做出最优选型的能力。课程以“架构方案”为主线，围绕边界划分、组件职责、数据流/控制流、选型权衡、风险点、落地步骤与验收标准组织每一章。
1.1 交付物说明
完成本课程后，你将获得以下可复用交付物：
| 交付物 | 形式 | 用途 |
|---|---|---|
| 选型决策矩阵 | 表格 + 决策树 | 快速判断场景该用 WorkManager 还是 JobScheduler |
| 组件责任边界文档 | 文本 + 架构图 | 团队对齐后台任务调度架构规范 |
| 迁移/落地步骤清单 | Checklist | 从 JobScheduler 迁移到 WorkManager 的操作指南 |
| 风险控制预案 | 列表 + 代码示例 | 规避电量、OOM、系统限制等常见坑 |
| 验收测试用例集 | 测试点表格 | 验证调度正确性与稳定性 |
1.2 适用读者
- Android 架构决策者：技术经理、架构师，需要制定后台任务调度规范。
- 高级/资深开发：已经在使用 JobScheduler 或 WorkManager，想深入理解原理和边界。
- 系统应用开发者：需要处理系统级后台任务，对 API 限制尤其敏感。
- 技术顾问 & 培训讲师：需要完整对比材料用于内部培训或公开课程。
1.3 学习路径
建议按课程章节顺序学习，共 30 章，划分为 6 个阶段：
- 基础认知（第 1-5 章）：课程总览、前置知识复习、两种 API 概述。
- 核心对比（第 6-15 章）：边界划分、组件职责、数据流/控制流、生命周期。
- 选型权衡（第 16-20 章）：场景矩阵、兼容性、电量/性能影响、生态支持。
- 风险与避坑（第 21-25 章）：常见陷阱、调试技巧、后台限制演进。
- 落地实战（第 26-28 章）：从零搭建 TaskManager 层、迁移案例、测试验收。
- 总结与展望（第 29-30 章）：全局对比地图、未来趋势。
建议：如果你已有较深 JDK 和 Android 基础，可以直接从第 6 章开始，但第 1-5 章的知识结构图和边界定义仍建议快速浏览。
1.4 前置知识
| 领域 | 具体要求 | 参考材料 |
|---|---|---|
| Android 组件 | 理解 Service、BroadcastReceiver、Binder 工作机制 | 官方文档：Service 与进程生命周期 |
| Java/Kotlin | 熟悉多线程、HandlerThread、AsyncTask 差异（非必须但推荐） | Kotlin 协程基础（可选） |
| 系统调度 | 了解 Android 后台执行限制（Doze、App Standby） | Android 电量优化官方指南 |
| 依赖注入 | 了解 DI 基本概念（本课程实战部分会用到 Hilt） | Hilt 官方 Codelab |
1.5 边界划分
本课程严格限定在 Android 应用层 的后台任务调度范围：
- 包含：
WorkManager与JobSchedulerAPI 使用、内部架构对比、电量/性能分析、真实项目集成方案。 - 不包含：
AlarmManager、Firebase Cloud Messaging、Foreground Service的详细讲解（仅会提到作为替代方案时的对比参考）。 - 不涵盖：跨进程 IPC 设计、自建调度引擎、NDK 层任务调度。
以下内联 SVG 展示了本课程后续将要深入对比的两个核心组件的宏观位置关系：
1.6 组件职责
从架构层面快速界定两个组件的宏观职责：
| 组件 | 职责 | 所在层次 |
|---|---|---|
| WorkManager | 封装任务定义、约束、观察、重试、链式依赖，并提供统一兼容 API（回退到 JobScheduler、AlarmManager 或前台服务）。 | 应用层库 |
| JobScheduler | 系统级调度引擎，负责根据电量、网络、时间等约束决定何时执行任务，并强制执行 Doze 模式限制。 | 系统服务层 |
1.7 数据流/控制流简要对比
两种方式的控制流核心差异在于调度决策权的位置：
- JobScheduler：应用提交 JobInfo → System Server 根据约束排队 → 时机满足时回调 JobService → 执行任务 → 任务结束调用 jobFinished。
- WorkManager：应用定义 OneTimeWorkRequest/PeriodicWorkRequest → WorkManager 内部 Repository 持久化 → 通过 SystemJobService 委托给系统 JobScheduler（API≥23）或自有的 AlarmManager 兼容层 → 执行时回调 Worker.doWork() → 返回 Result.success/retry/failure。
详细的时序图和状态机将在第 8-10 章展开。
1.8 选型权衡快速总览
第一原则：优先使用 WorkManager，除非你明确需要绕过 WorkManager 的抽象层直接控制系统调度行为（例如系统应用需要自定义最小间隔，或需要直接操作 JobScheduler 的 not-require-network 行为）。
以下为典型场景的初步判断：
| 场景 | 推荐组件 | 理由 |
|---|---|---|
| 常规后台上传/下载 | WorkManager | 自动处理重试、约束、兼容性 |
| 严格周期性的轮询（< 15 分钟） | WorkManager（支持最小 15 分钟间隔） | 无需自行管理周期逻辑 |
| 需要精确延时执行（秒级） | JobScheduler 或 AlarmManager | WorkManager 的最小 delay 有限制 |
| 系统级应用定制 Doze 白名单行为 | JobScheduler（直接操作） | WorkManager 会额外增加一层抽象，可能不符合系统签名要求 |
1.9 风险点总览
本课程将反复出现的风险点（已在第 21−25 章详细展开）：
- 兼容性裂痕：WorkManager 2.7.0 之后移除了对 API 14-20 的支持，部分旧设备只能退回到 JobScheduler。
- 电量守卫误杀：JobScheduler 在 Doze 模式下可能无限推迟任务，WorkManager 则通过合并窗口缓解。
- 进程被杀：两种方式在进程被杀死后恢复行为不同，JobScheduler 依赖系统重启，WorkManager 依赖 Room 持久化。
- 过度抽象：WorkManager 隐藏太多细节，一旦出问题难以排查；JobScheduler 则需要开发者手动处理更多边缘情况。
1.10 落地步骤与验收标准
在后续章节你将学习到详细落地步骤，这里给出全局路径：
- 调研现有代码：识别所有后台任务，分类为“可迁移”与“保留”。
- 选型决策：使用选型矩阵确定每个任务的组件。
- 搭建 TaskManager 抽象层（第 26 章）统一调度接口。
- 编写单元测试 & 集成测试：验证任务被正确调度、执行、重试（验收标准）。
- 灰度发布 & 监控：通过日志和 WorkManager 自带指标确认稳定性。
验收标准示例（课程结束时你可以验证）：
- ✅ 所有后台任务能在 API 21-34 上正确执行，不出现 ANR 或异常 Crash。
- ✅ 网络可用性、电量约束等条件被准确遵守。
- ✅ 任务失败后按指定策略重试，重试次数不溢出。
- ✅ 迁移后应用能耗曲线无明显上升（通过 Battery Historian 对比）。
注意：验收标准应在项目落地前与 QA 团队对齐，避免基于理想模型设定过高期望（例如某些系统厂商对 JobScheduler 做了魔改，可能导致部分设备行为不一致）。