12、周期性任务实战：PeriodicWorkRequest配置、最小间隔时间限制(15分钟)、灵活间隔与FlexInterval、周期性任务的观察与管理
各位同学，欢迎来到第12章。今天我们来聊聊周期性任务。
说实话，我在刚接触WorkManager时，对周期性任务的理解有点想当然。我以为设个5分钟执行一次，它就会乖乖每5分钟跑一次。结果呢？任务要么不执行，要么间隔完全不对。后来我才明白——Android系统对周期性任务有严格的约束，尤其是那个15分钟的最小间隔限制。
这一章，我会把PeriodicWorkRequest的配置细节、FlexInterval的灵活用法，以及如何观察和管理周期性任务，一次性讲清楚。
12.1 PeriodicWorkRequest基础配置
先看一个最简单的例子。假设我们要做一个每30分钟同步一次数据的任务：
val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(
30, TimeUnit.MINUTES
).build()
WorkManager.getInstance(context)
.enqueueUniquePeriodicWork(
"sync_work",
ExistingPeriodicWorkPolicy.KEEP,
syncRequest
)嗯，代码看起来很简单对吧？但这里有个坑——你设30分钟，系统不一定真的30分钟执行一次。为什么？因为Android为了省电，会把多个应用的周期性任务合并到一起执行。你的任务可能会被延迟几分钟，甚至十几分钟。
核心要点：PeriodicWorkRequest的最小间隔是15分钟。如果你设小于15分钟，系统会强制提升到15分钟。我在项目中就踩过这个坑，当时设了10分钟，结果日志一看，每次都是15分钟才触发。
12.2 最小间隔时间限制（15分钟）
这个15分钟的限制，是Android系统层面的硬性规定。你想想看，如果每个App都能随意设几秒一次的周期性任务，用户的手机电量怕是撑不过半天。
具体规则是这样的：
| 你设置的时间 | 实际生效时间 | 说明 |
|---|---|---|
| 5分钟 | 15分钟 | 系统强制提升到最小间隔 |
| 15分钟 | 15分钟 | 正常生效 |
| 30分钟 | 30分钟 | 正常生效 |
| 1小时 | 1小时 | 正常生效 |
注意：即使你设了15分钟，系统也可能因为Doze模式、省电模式等原因，将任务延迟到更晚执行。不要假设任务会精确按时间点触发。
12.3 FlexInterval：灵活间隔的妙用
好，接下来是重点——FlexInterval。我个人觉得这是WorkManager最巧妙的设计之一。
什么叫FlexInterval？说白了就是：你给任务一个“执行窗口”，系统在这个窗口内的任意时间点执行都可以。
举个例子：
val flexRequest = PeriodicWorkRequestBuilder<SyncWorker>(
60, TimeUnit.MINUTES, // 周期：1小时
15, TimeUnit.MINUTES // FlexInterval：15分钟
).build()这段代码的意思是：每1小时执行一次，但系统可以在每个小时的最后15分钟内执行。也就是说，任务会在第45分钟到第60分钟之间的某个时间点触发。
为什么会需要这个？我遇到过这样一个场景：多个周期性任务如果都在整点执行，会导致CPU瞬间飙高。用FlexInterval把任务分散到不同的时间窗口，系统负载就平滑多了。
FlexInterval的规则是这样的：
- FlexInterval必须小于周期时间。比如周期60分钟，FlexInterval最大可以设59分钟。
- 任务会在每个周期的最后FlexInterval时间段内执行。
- FlexInterval设得越大，系统调度越灵活，省电效果越好。
我的建议：如果你的任务对实时性要求不高，比如数据上报、日志清理这类，尽量把FlexInterval设大一些。我曾经把一个15分钟周期的任务，FlexInterval设到10分钟，系统调度起来非常顺畅，电量消耗也明显降低。
12.4 周期性任务的观察与管理
任务配置好了，怎么观察它是否按预期执行？WorkManager提供了很完善的观察机制。
12.4.1 使用LiveData观察任务状态
val workManager = WorkManager.getInstance(context)
val workInfoLiveData = workManager.getWorkInfoByIdLiveData(syncRequest.id)
workInfoLiveData.observe(this) { workInfo ->
if (workInfo != null) {
when (workInfo.state) {
WorkInfo.State.ENQUEUED -> Log.d("TAG", "任务已排队")
WorkInfo.State.RUNNING -> Log.d("TAG", "任务正在执行")
WorkInfo.State.SUCCEEDED -> Log.d("TAG", "任务执行成功")
WorkInfo.State.FAILED -> Log.d("TAG", "任务执行失败")
WorkInfo.State.CANCELLED -> Log.d("TAG", "任务已取消")
}
}
}12.4.2 通过唯一名称查询
workManager.getWorkInfosForUniqueWorkLiveData("sync_work")
.observe(this) { workInfos ->
// 处理所有关联的任务信息
}12.4.3 取消周期性任务
// 取消单个任务
workManager.cancelWorkById(syncRequest.id)
// 取消唯一周期性任务
workManager.cancelUniqueWork("sync_work")
// 取消所有任务
workManager.cancelAllWork()避坑指南：我曾经在取消任务时犯过一个错误——用cancelWorkById取消了一个周期性任务，但忘了它还有后续的周期。结果任务在下一个周期又自动恢复了。记住：周期性任务取消后，不会自动重新调度。如果你需要彻底停止，用cancelUniqueWork更稳妥。
12.5 知识体系总览
下面这张图，是我对本章知识点的梳理。你可以把它当作一个快速参考：
12.6 实战建议
最后，我总结几条实战中的经验：
- 能用OneTimeWorkRequest就别用PeriodicWorkRequest。很多场景其实只需要一次性的延迟任务，用周期性任务反而增加复杂度。
- 周期任务一定要设置唯一名称。否则每次App启动都enqueue一次，你会得到一堆重复的任务。
- 测试时把周期设短一点。比如设成15分钟，方便验证逻辑。上线前再改回正常周期。
- 别忘了处理任务失败的情况。周期性任务失败后，默认会按指数退避策略重试。如果你不想重试，记得在Worker里返回Result.failure()。
个人习惯：我通常会在Worker的doWork()方法里加一个超时保护。比如任务最多执行5分钟，超过就强制结束。这样可以防止某些异常情况导致任务一直占用资源。
好了，关于PeriodicWorkRequest的内容就讲到这里。记住：周期性任务的核心不是“精确执行”，而是“在合理的时间范围内执行”。理解了这一点，你就能用好WorkManager的周期性调度能力。