WorkManager 简介：背景、核心概念与作用
大家好，我是这次课程的主讲。
说到 WorkManager，我猜不少人有这样的经历：明明只是想在后台做个网络请求，结果被系统一刀砍死；想定时上传个日志，却发现 App 已经被杀得干干净净。嗯，后台任务这件事，在 Android 世界里一直是块硬骨头。
今天这第一节，我们先聊聊 WorkManager 到底是什么，它为什么会出现，以及——说白了——它跟我们这次的主题「帧率抖动」有什么关系。
1. 1 背景：安卓后台任务的那点破事
我刚开始做 Android 开发的时候，后台任务是个很「自由」的事。
Service 随便开，线程随便起，想怎么跑就怎么跑。但后来 Android 系统越来越严格——从 Doze 模式到 App Standby，再到 Android 8.0 的后台执行限制、Android 12 的 Foreground Service 启动限制……说白了，系统其实在跟你说一句话：别再偷偷摸摸干重活了。
所以开发者面临一个尴尬的处境：
- 用
Service？一锁屏就被杀。 - 用
AlarmManager？管理起来太麻烦。 - 用
JobScheduler？API 太老了。
就在这时候，Google 推出了 WorkManager。我记得当时我还在做一个日志上报功能，看到这东西的第一反应是：终于有个靠谱的解决方案了。
1. 2 核心概念：三个关键词帮你理解它
WorkManager 的核心其实就三样东西。咱们一个一个说。
1.2.1 Worker
Worker 是任务本体。你要做的事，写在 doWork() 里即可。
class TaskWorker(context: Context, params: WorkerParameters) : Worker(context, params) {
override fun doWork(): Result {
// 执行你的任务
return Result.success()
}
}
1.2.2 WorkRequest
这是任务的「配置器」。比如跑一次还是周期执行？要不要延迟？都在这配。
val request = OneTimeWorkRequestBuilder<TaskWorker>()
.setInitialDelay(10, TimeUnit.SECONDS)
.build()
1.2.3 WorkManager
调度引擎。你把 WorkRequest 交给它，它就帮你安排一切：合适的时机、合适的条件、合适的系统 API。
WorkManager.getInstance(context).enqueue(request)
这三者合在一起，就组成了一个完整的任务生命周期：提交 → 调度 → 执行 → 结束。
1. 3 作用：为什么它能影响帧率？
你可能会问：「一个后台任务框架，跟 UI 帧率有啥关系？」
关系大了。我这么给你解释：
- 后台任务可能在主线程上执行 —— 如果你不小心把 Worker 设成了
mainThread……嗯，屏幕就卡了。 - 任务过度堆积 —— 多个 WorkRequest 同时触发，CPU 突然飙高，UI 线程反而得不到资源。
- 调度时机不准 —— 比如你指望任务半夜跑，结果它偏偏在用户滑动列表时冒出来，那画面……
所以，WorkManager 调度一旦「堵车」，帧率自然就跟着抖。
1. 4 一张图看懂全貌
下面这张图，把 WorkManager 的完整流程、核心组件、以及它如何「卡住」帧率给串了起来。你们拿着看，很容易理解。
1. 5 核心功能速查表
| 功能点 | 说明 |
|---|---|
| 持久化任务 | 设备重启后，任务自动恢复执行 |
| 链式调度 | 多个任务可串联或并联，按顺序执行 |
| 约束条件 | 仅在充电、网络可用、空闲时执行 |
| 线程策略控制 | 可指定主线程 / 后台线程执行 |
| 最低兼容 API 14 | 自动适配不同系统版本的调度 API |
1. 6 两个常见误解
- 「WorkManager = 线程池」 —— 错。线程池只管执行，WorkManager 还管调度、持久化、约束。
- 「WorkManager 会卡 UI」 —— 错。它本身不会，是 你写的 Worker 卡了 UI。比如你在主线程 Worker 里做了大量计算……那别怪它。
ListenableWorker + 协程，确保绝不碰主线程。这样帧率就安全了一半。
1. 7 本章小结
好了，第一节讲到这里。
核心就是记住：WorkManager 是一个靠谱的后台任务框架，但它不是银弹。 用得好，帧率稳定；用不好，它就是帧率抖动的「隐形推手」。