WorkManager 概述：它到底是什么？
简单说，WorkManager 是 Android 官方推出的一个异步任务调度库。嗯，它是 Jetpack 家族的一员。你可能会问：我用 AsyncTask、Handler 或者 Coroutine 不也能做后台任务吗？为啥非得用它？
我刚开始接触时也有这个疑惑。直到我在一个项目里需要“确保某个任务即使 App 被杀死、手机重启也能执行”……那时候就知道 WorkManager 的价值了。
WorkManager 的核心功能
说白了，WorkManager 就是帮你管理那些“不需要用户立刻看到结果，但必须最终一定要做完”的任务。我用一个表格概括它的几大能力：
| 能力 | 说明 |
|---|---|
| 持久化任务 | 任务被存储到数据库里，App 杀掉、设备重启都不会丢 |
| 约束条件 | 比如“只在充电时执行”“只在有网络时执行” |
| 链式任务 | 任务 A 完成后自动启动任务 B，还能组合并行 |
| 灵活调度 | 支持一次性任务、周期性任务、延迟任务 |
| 兼容性 | 向下兼容到 API 14，底层自动适配 JobScheduler / AlarmManager |
| 状态观察 | 可以监听任务的执行状态（成功、失败、重试等） |
我记得有个同事之前用 JobScheduler 写了很复杂的逻辑，后来切到 WorkManager 只用了三行配置，这就是差距。
架构：WorkManager 怎么运作的？
WorkManager 不是单枪匹马完成的，它背后有一套清晰的组件。我画了一张图，你看一眼就能理解：
这张图你多看几遍。我重点解释几个关键点：
- WorkManager API：你直接调用的入口，比如
beginWith()、enqueue()。 - WorkDatabase：Room 数据库，任务状态全存这里。所以能扛住进程被杀。
- Scheduler：底层根据 Android 版本选择 JobScheduler 或 AlarmManager。
- Processor：真正的执行线程池，可以跑在后台线程或前台 Service 里。
- ForegroundProcessor：处理需要前台通知的长任务，比如下载大文件。
- WorkerWrapper：每个 Worker 实例的包装，负责状态流转和结果回传。
什么时候该用 WorkManager？
不是所有后台任务都要用它。我一般遵循这个判断标准：
核心原则：如果任务“不需要立即响应，但不能中途丢失”，就用 WorkManager。
举几个常见场景：
- 上传日志文件到服务器（即使 App 被划掉也要保证最终上传成功）
- 定期同步本地数据库到云端（比如用户笔记的自动备份）
- 图片或视频的压缩处理（利用空闲时间+可延迟）
- 预缓存首页数据（充电+WiFi 条件下再做）
反过来看，哪些情况不适合？
- 需要立刻执行的 UI 操作 —— 别用 WorkManager，用 Coroutine 或 LiveData 直接走。
- 一次性且非常快的计算（比如 100ms 内的计算）—— 没必要交给调度器。
- 必须保证前台进程可见的任务 —— WorkManager 虽然支持 Foreground，但优先级不如前台 Service 直接。
避坑指南：我踩过的几个坑
⚠️ 我曾经遇到过的一个典型问题：任务设置了约束条件“网络可用”，结果用户飞行模式 + 离线很久，任务就一直卡在 ENQUEUED 状态，既不执行也不失败。后来我给它加了 backoffCriteria 和超时，才解决僵尸任务。
还有一点你一定要注意：
- WorkManager 的
doWork()是默认跑在后台线程的，但别在里面做内存密集型操作，容易 OOM。我习惯在里面只做 IO 操作，计算放到 Coroutine 里。 - 同一个
Worker类不要同时被多个WorkRequest引用，除非你设置了ExistingWorkPolicy去重。否则会重复执行。 - 别忘了
Result.retry()的使用：当网络临时失败时，返回 retry 会自动按策略重试。我早期总是返回 failure，结果任务直接停了。
小结
WorkManager 是 Android 后台任务的“正规军”。它解决了异步调度中最头疼的两个问题：持久化和约束。你想想看，以前用 JobScheduler 或 AlarmManager 自己写重试、写数据库、写状态机……那得多累？WorkManager 全给我们封装好了。
我个人建议：只要是“能晚点做但必须做”的任务，全部交给 WorkManager。它稳定、可靠、测试也方便——这也正是我们后续课程要讲的重点：如何 Mock 和回放这些任务流程。
（本章完）