📚 课程目录第4章创建第一个 WorkManager 任务

4. 约束条件详解

约束条件是 WorkManager 调度任务的核心过滤器。通过 Constraints 类，你可以精确控制后台任务在何种设备状态下执行，从而避免在低电量、无网络、存储不足等场景下浪费系统资源或导致任务失败。本章将深入剖析每个约束项的原理、API 配置方式、组合逻辑以及运行时变化的回调处理。

4.1 Constraints 类结构

Constraints 是一个不可变的值对象，通过 Constraints.Builder 构建。每个约束项都对应一个枚举或布尔值：

约束字段	类型	默认值	说明
`setRequiredNetworkType()`	`NetworkType`	`NOT_REQUIRED`	任务执行所需的网络连接类型
`setRequiresCharging()`	`boolean`	`false`	设备是否必须处于充电状态
`setRequiresDeviceIdle()`	`boolean`	`false`	设备是否必须处于空闲状态（API 23+）
`setRequiresStorageNotLow()`	`boolean`	`false`	设备可用存储空间是否不能过低
`setRequiresBatteryNotLow()`	`boolean`	`false`	设备电池电量是否不能过低（API 26+）

最佳实践：合理设置约束可以减少系统对任务的延迟或取消。例如，数据同步任务应使用 CONNECTED 网络类型，避免在无网络时启动导致失败并消耗重试次数。

4.2 网络类型详解

NetworkType 枚举定义了任务对网络连接的需求级别：

NOT_REQUIRED：对网络无要求，即使离线也可执行。
CONNECTED：需要任意网络连接（Wi-Fi 或移动数据）。
UNMETERED：仅限非计量网络（通常为 Wi-Fi、以太网）。
TEMPORARILY_UNMETERED：临时非计量网络（如热点、手机开启个人热点时）。
METERED：仅限计量网络（移动数据）。

典型配置示例：

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.UNMETERED)
    .build()

val uploadWork = OneTimeWorkRequestBuilder<UploadWorker>()
    .setConstraints(constraints)
    .build()

4.3 充电状态、空闲状态与存储不足

这三个约束用于保护用户设备体验：

RequiresCharging：确保任务只在插入电源时执行，适合高耗电操作（如大量图片处理）。
RequiresDeviceIdle（API 23+）：要求设备进入 Doze 模式的空闲状态（屏幕关闭、无运动、无网络活动）。适合延迟容忍度极高的批处理任务。
RequiresStorageNotLow：系统存储空间低于阈值（通常是总空间的 10% 或 256MB 以下）时，任务不会启动。
RequiresBatteryNotLow（API 26+）：电量低于用户设定的低电量阈值（通常 15%）时，任务推迟。

以下是一个组合约束的完整代码：

val syncConstraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(true)
    .setRequiresDeviceIdle(true)
    .setRequiresStorageNotLow(true)
    .setRequiresBatteryNotLow(true)
    .build()

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setConstraints(syncConstraints)
    .build()

注意：setRequiresDeviceIdle(true) 会显著推迟任务执行，因为设备空闲状态不会频繁出现。仅适合不紧急的任务，例如每日数据备份。

4.4 约束组合逻辑

多个约束之间是与（AND）关系：所有约束条件必须同时满足，任务才会被触发。如果任一条件不满足，WorkManager 会将任务保留在队列中，持续监听系统状态的变化，直到所有约束满足后再执行。

下图展示了约束组合的判定流程：

当某些约束不满足时，WorkManager 会监听相应的系统广播（如 CONNECTIVITY_CHANGE、BATTERY_CHANGED 等），并在约束变为满足后立即触发任务。但如果任务在运行时约束状态发生变化（例如网络断开），WorkManager 会如何处理？

4.5 运行时约束变化处理

任务启动后，约束条件的变化不会导致正在执行的任务中断。WorkManager 的设计哲学是：一旦任务开始执行，就允许它完成，不会因为后续约束失效而取消它。但如果你需要感知运行中的环境变化，可以在 Worker 中自行监听系统广播或使用 ListenableWorker + CallbackToFutureAdapter 实现精细控制。

然而，对于非正在执行的任务，当约束从满足变为不满足时，WorkManager 会：

将任务重新放回队列等待，并继续监听变化；
如果任务已经处于 RUNNING 状态，则不受影响；
任务完成后，即使后续约束再次满足，也不会重复执行（一次性任务）。

4.6 常见错误与调试

问题现象	原因	解决方案
任务一直不执行	约束过严（如同时要求充电+空闲+非计量网络）	放宽约束，或使用链式任务拆分
任务在无网络时仍启动	忘记设置 `setRequiredNetworkType()`，默认值为 `NOT_REQUIRED`	显式设置为 `CONNECTED` 或 `UNMETERED`
任务反复被延迟	`setRequiresDeviceIdle(true)` 在低版本设备上不生效	检查运行时版本并准备回退方案
任务明明满足约束却未被触发	WorkManager 内部有指数退避，或任务已因其他原因被取消	通过 `WorkInfo.getWorkInfoById()` 查看状态

    调试技巧：在测试环境中设置尽量宽松的约束（如只要求 CONNECTED），待逻辑跑通后再添加更多约束。同时，使用 adb shell dumpsys jobscheduler 查看系统 JobScheduler（WorkManager 底层）的调度状态。

4.7 性能与稳定性优化建议

避免“全约束恐慌”：同时启用太多约束会使任务几乎无法启动，应只添加真正必要的约束。
善用 setBackoffCriteria()：当约束不满足导致重试时，设置合理退避策略防止频繁重试消耗电量。
分组约束相同任务：多个具有相同约束的 WorkRequest 可以共用一个 Constraints 实例，减少对象创建。
电池与存储约束：setRequiresBatteryNotLow() 和 setRequiresStorageNotLow() 对低端设备尤其重要，能避免任务因系统资源不足而崩溃。
运行时感知：若业务要求任务在网络断开时暂停，建议任务内部捕获资源变化并主动调用 Result.retry() 让 WorkManager 重新调度。