5、任务约束与触发条件：NetworkType约束、BatteryNotLow约束、StorageNotLow约束、充电状态约束、Idle状态约束
各位同学，今天我们来聊聊WorkManager里一个非常实用的功能——任务约束。说白了，就是告诉系统：「嘿，我这个任务不是随便什么时候都能跑的，你得满足我几个条件才行。」
我个人习惯把约束理解为「任务的脾气」。有的任务脾气大，非得连上Wi-Fi才干活；有的任务比较省心，只要电量不是太低就行。WorkManager为我们提供了五种核心约束，咱们一个一个来看。
核心思想：约束不是强制任务立即执行的条件，而是任务进入可执行状态的门槛。系统会在满足所有约束后，选择一个合适的时机来运行你的任务。
5.1 NetworkType约束：联网还是不联网？
这个约束可能是大家用得最多的。我在项目中遇到过好几次，用户反馈「为什么我的App在后台偷偷跑流量？」——其实就是因为没有加网络约束。
NetworkType约束有以下几个选项：
| 约束值 | 含义 | 适用场景 |
|---|---|---|
| NOT_REQUIRED | 不要求网络连接 | 本地计算、数据库清理 |
| CONNECTED | 只要有网络连接即可 | 普通数据同步 |
| UNMETERED | 非计量网络（通常指Wi-Fi） | 大文件下载、视频缓存 |
| METERED | 计量网络（移动数据） | 仅在流量套餐下执行的任务 |
| NOT_ROAMING | 非漫游状态 | 避免漫游高额费用 |
嗯，这里要注意一点：UNMETERED 和 NOT_ROAMING 经常被混淆。前者关心的是「流量计费方式」，后者关心的是「是否在漫游」。我建议你根据实际业务场景来选择，别一股脑全加上。
// 设置网络约束的典型写法
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED) // 只在Wi-Fi下执行
.build()
val uploadWork = OneTimeWorkRequestBuilder<UploadWorker>()
.setConstraints(constraints)
.build()小技巧：如果你需要「有网络就执行，但优先用Wi-Fi」，可以设置 CONNECTED 约束，然后在Worker内部判断网络类型。这样灵活性更高。
5.2 BatteryNotLow约束：电量焦虑症的福音
你想想看，如果用户在玩游戏，突然你的后台任务开始疯狂跑CPU，把电量耗光了——这体验得多糟糕？
BatteryNotLow 约束就是干这个的。它确保任务只在电量充足（通常指电量高于15%或处于充电状态）时才会执行。
val constraints = Constraints.Builder()
.setRequiresBatteryNotLow(true)
.build()我曾经在一个日志上传功能上吃过亏。当时没加这个约束，结果用户反馈手机发烫、掉电快。排查了半天，发现是日志上传任务在低电量时还在拼命重试。加了 BatteryNotLow 之后，问题立刻解决了。
避坑指南：不要过度依赖这个约束。如果你的任务本身很轻量（比如几毫秒的数据库操作），加这个约束反而会延迟任务执行。我建议只对「耗电型任务」使用。
5.3 StorageNotLow约束：别把存储空间撑爆了
这个约束和 BatteryNotLow 很像，只不过它关心的是存储空间。当设备可用存储空间低于某个阈值（通常是10%）时，任务不会执行。
我个人习惯在「下载大文件」或「生成缓存数据」的任务上加这个约束。你想想看，如果用户手机只剩200MB空间，你的任务还要下载一个500MB的视频——这不等着崩溃吗？
val constraints = Constraints.Builder()
.setRequiresStorageNotLow(true)
.build()不过说实话，这个约束在实际项目中用得相对少一些。因为大多数App的存储管理做得比较好，而且系统本身也会在存储不足时发出警告。但如果你是做视频、图片处理类的App，我建议还是加上。
5.4 充电状态约束：趁充电时偷偷干活
这个约束太实用了。说白了就是：「只有在手机插着充电器的时候，你才能跑这个任务。」
典型的场景是什么？数据备份、系统更新、大量图片的云端同步。这些任务耗电、耗流量，而且用户不急着要结果。那就在充电时做，既不影响用户体验，又能保证任务完成。
val constraints = Constraints.Builder()
.setRequiresCharging(true)
.build()我记得有一次做相册备份功能，一开始没加充电约束。结果用户反馈说「晚上睡觉时手机一直在发热」。后来改成充电时备份，用户满意度直接提升了一个档次。
最佳实践：充电约束 + UNMETERED网络约束，是「大后台任务」的黄金组合。既省电、又省流量、还不影响用户。
5.5 Idle状态约束：系统空闲时再干活
这个约束比较特殊。它要求设备处于空闲状态——也就是屏幕关闭、没有正在运行的前台应用、没有正在进行的音视频播放等。
为什么需要这个？因为有些任务虽然不紧急，但一旦执行就会抢占CPU资源，影响前台应用的流畅度。比如：数据库的垃圾回收、日志的压缩归档、缓存的清理。
val constraints = Constraints.Builder()
.setRequiresDeviceIdle(true)
.build()嗯，这里要特别提醒一下：setRequiresDeviceIdle(true) 在Android 9及以上版本中，实际上会使用「Doze模式」的维护窗口来执行任务。这意味着任务的执行延迟可能会比较长——最长可能达到几个小时。
注意：不要对「用户期望立即看到结果」的任务使用Idle约束。比如「发送消息」、「保存草稿」这些，用Idle约束就等着被用户骂吧。
5.6 组合约束：让任务更聪明
上面我们讲了单个约束，但实际项目中，我们经常需要组合使用。比如：
- 「大文件下载」：充电 + Wi-Fi + 存储空间充足
- 「日志上传」：有网络 + 电量不低
- 「缓存清理」：空闲状态 + 存储空间不足
val constraints = Constraints.Builder()
.setRequiredNetworkType(NetworkType.UNMETERED)
.setRequiresCharging(true)
.setRequiresStorageNotLow(true)
.setRequiresBatteryNotLow(true)
.build()你可能会问：「约束加得越多越好吗？」其实不是。约束越多，任务被触发的机会就越少。我建议你遵循「最小必要原则」——只加那些真正必要的约束。
5.7 知识体系总览
为了让你更直观地理解这五种约束的关系，我画了一张图：
5.8 实战建议
最后，分享几个我踩过的坑：
- 不要滥用Idle约束：我曾经在一个「每日统计上报」任务上用了Idle约束，结果用户反映数据更新不及时。后来改成
CONNECTED+BatteryNotLow，问题解决。 - 网络约束要谨慎：如果你的App主要面向海外用户，记得考虑漫游场景。我有个朋友没加
NOT_ROAMING，结果用户出国后流量费暴涨，被投诉到应用商店下架了。 - 测试约束是否生效：WorkManager提供了
WorkManager.enqueue()后的状态查询API。我建议你在开发阶段打印出约束状态，确保它们按预期工作。
一句话总结：约束是WorkManager的「看门人」，用好了能让你的后台任务既高效又优雅。但记住——约束不是越多越好，合适才是王道。
公众号:蓝海资料掘金营，微信deep3321