Worker/JobScheduler停止与限流机制及相关技术问题咨询

背景说明 #

开发需耗时执行的Worker组件，可在系统限制时重新调度。计划使用setRequiresDeviceIdle让任务在设备息屏时执行，避免影响用户体验。Worker基于JobScheduler，不同Android API版本的任务执行时长限制不同：

• API21-22：1分钟
• API23-R：10分钟
• API-S及以上：系统空闲时可超出10分钟

存在未明确的定义：

• setRequiresDeviceIdle中“设备处于活跃使用状态”的含义，非系统Doze/idle状态，疑似指屏幕点亮，但测试未触发；
• Worker/JobScheduler被“停止”的具体影响；
• “throttle”的含义及触发时机。

核心问题与解答 #

1. setRequiresDeviceIdle是否仅在设备息屏时生效？需满足息屏时长？ #

setRequiresDeviceIdle并非仅依赖息屏状态，它要求设备进入系统Idle模式（即Doze模式的空闲阶段）。息屏是进入Idle模式的前提，但不是唯一条件：

• 设备息屏后，还需经历一段系统设定的无操作时长（通常为几分钟），才会进入Idle模式，此时该条件才会触发任务执行；
• 短时间息屏不会触发Idle模式，任务也不会启动；
• 极少数情况下，屏幕点亮但长时间无用户交互，部分系统版本可能进入轻度Idle状态，但这种场景可忽略。

2. 当Worker/JobScheduler因超时触发onStopped/onStopJob时，任务、应用及进程会发生什么？进程是否会被系统杀死？ #

触发onStopped()（Worker）或onStopJob()（JobScheduler）时：

• 任务：系统会强制终止当前执行的任务逻辑，不会等待任务完成。Worker会根据WorkRequest的重试策略决定是否重新调度；JobScheduler需在onStopJob()中返回true才会触发重新调度。
• 应用/进程：进程不会直接被杀死，但系统会标记该任务超时。如果应用没有其他前台组件保持活跃，系统在资源紧张时可能优先回收该进程，但超时本身不会直接导致进程被杀。

3. “throttle”指系统延迟应用的所有任务、特定任务还是降低任务执行速度？ #

这里的“throttle”指系统延迟特定任务的调度，而非降低任务执行速度或限制所有任务：

• 通常针对频繁触发、违反调度规则的单个任务（比如短时间内多次调度同一个Job/Worker），系统会延长该任务的下次执行间隔，避免过度消耗资源；
• 若应用存在大量违规任务，可能触发对所有调度任务的全局限流，但这种情况较少见。

4. “runaway application”的定义是什么？触发限流的场景有哪些？是两种还是一种？ #

• runaway application定义：指持续消耗系统资源、违反系统调度规则的应用，比如频繁创建任务、任务多次超时、在非允许时段强行执行任务等。
• 触发限流的场景主要有两类：
  1. 任务调度过于频繁：短时间内重复提交大量相同或相似的Job/Worker任务；
  2. 任务违规执行：比如任务多次超时、在系统限制时段（如活跃使用状态）强行执行，或不遵守setRequiresDeviceIdle等约束条件。

内容的提问来源于stack exchange，提问作者android developer