用途
该技能面向 Android 平台，解决“设置驱动后台任务”的一致性问题：让设置存储成为唯一事实来源，把周期性任务的调度视为设置的投影。当用户切换开关或修改间隔时，任务应立即生效，而不是等到进程重启或下一次手动触发。
主要能力
- 设置流即调度器：用一个长期收集器监听设置，组合开关与间隔两个流后收集，在启用时调用
scheduleBackup(frequency)，禁用时调用cancelBackup()。 - 正确的去重方式：在组合后的二元组上使用
distinctUntilChanged()，避免无关设置写入触发重复入队或周期重置。 - 入队策略：使用
enqueueUniquePeriodicWork(WORK_NAME, ExistingPeriodicWorkPolicy.UPDATE, request)，每个收集发射都可以携带不同周期，UPDATE 会原地替换已入队请求的参数并保留唯一名称。 - 取消的镜像操作：
cancelUniqueWork(WORK_NAME)与调度使用同一个名称常量。 - Worker 自检：
doWork()开头重新读取启用标志，若已关闭则返回Result.success()，表示“无事可做”而非失败，不消耗重试预算。
使用方式
将收集器放在与进程同生命周期的作用域中（例如 Application 的 onCreate 中只启动一次）。避免放在屏幕作用域或 ViewModel 作用域，否则屏幕销毁后不再重新调度。Worker 由框架构造，需通过服务定位器或注入工厂获取设置存储依赖，而不是构造函数注入。在构建请求时校验设置值是否满足平台的最小周期，低于下限的请求会被钳制而非拒绝。
适用场景
适合任何需要根据用户偏好启停或调整频率的 Android 周期性后台任务，例如自动备份、定期同步、定时通知等。尤其适合设置项包含开关加间隔组合、且要求修改即时生效的产品。
限制与陷阱
KEEP策略会静默忽略新间隔，已入队的唯一任务保持不变，直到被取消或清除应用数据；只在请求为常量时使用 KEEP，凡是字段来自设置的应使用 UPDATE。- 唯一任务由名称字符串标识，而非 Worker 类；调度与取消必须引用同一常量，两个拼写会导致无法取消的泄漏调度，两个功能复用同一名称会互相争抢同一槽位。
- 约束条件（网络、电量）属于调度的一部分，任务可能被长时间推迟，任何假设“每 24 小时必跑”的下游逻辑都不成立。
- 取消对已分发的运行不具追溯力，周期性运行可能在入队很久后才触发，因此 Worker 必须自行重读设置。
- 平台会强制最小周期，界面中低于下限的选项在运行时会变成谎言。
验证方法
在运行中的应用里修改间隔，确认已入队请求发生变化（按唯一名称检查，或记录构建的间隔与所用策略）；关闭开关后强制运行一次，确认 Worker 返回 success 且不执行任何操作；用 grep 确认收集器的启动作用域是 Application 且只创建一次；重发一个无关偏好，确认没有触发重新入队；确认调度与取消引用的是同一个名称常量而非两个字符串字面量。