PeriodicWorkRequest 与 OneTimeWorkRequest 的最大时间间隔限制是多少？
解读
面试官抛出这道题，并不是想让你背“24 小时”这么简单，而是想确认三件事：
- 你是否真的在 8.0 之后的国内 ROM 上踩过“定时任务不准”的坑；
- 你是否清楚 WorkManager 只是系统调度的“建议值”，而不是硬实时；
- 你是否知道国内厂商的“对齐唤醒”“省电精灵”会把 24 h 稀释成什么数量级。
一句话：考的是“你对 Android 软实时+国产 ROM 特色”有没有体感。
知识点
- WorkManager 的约束模型
- 最小间隔：API 层面强制 15 min（PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS）。
- 最大间隔：官方文档写的是“建议不超过 24 h”，但源码里并没有硬编码上限，只是 AlarmManager/JobScheduler 的底层窗口被系统裁剪为 24 h。
- OneTimeWorkRequest
- 本身没有“周期”概念，所谓“最大延迟”是 setInitialDelay 的上限，同样被框架层约束为 24 h（INITIAL_DELAY_THRESHOLD_MILLIS）。
- 国产 ROM 的二次裁剪
- 华为 EMUI 10+：后台任务对齐窗口 6 h，24 h 任务会被折叠到下一个 6 h 批次。
- 小米 MIUI 12+：省电策略下，24 h 周期实际漂移 18~36 h 很常见。
- OPPO/Vivo：后台冻结 12 h 后，任务会被推迟到下一次设备深度空闲窗口。
- 兜底方案
- 24 h 以上需求必须拆分为“链式+Boot 接收器+电池白名单”三件套，再叠加厂商 Push SDK 做反向唤醒，否则在国内市场上基本不可达。
答案
PeriodicWorkRequest 的“官方建议”最大间隔是 24 小时，OneTimeWorkRequest 的 setInitialDelay 也受同一 24 小时阈值限制；超过 24 h 框架会直接抛 IllegalArgumentException。但在国内主流 ROM 上，由于对齐唤醒和省电策略，24 h 任务的真实漂移范围是 18~48 h，甚至更长，因此业务上若需要严格 24 h 触达，必须配合厂商白名单或 Push 通道做兜底。
拓展思考
- 如果业务场景是“每 30 天提醒一次用户续费”，你怎样用 WorkManager 实现？
答：拆成 30 个链式 OneTimeWorkRequest，每个 24 h 递推，并在链首加 Battery 不限制、存储重入标记，防止关机丢失；同时接入华为 Push 的“定时消息”作为双保险。 - Android 14 引入的“用户可撤销长期任务”权限对 24 h 周期有何影响？
答：用户可在设置里直接撤销 APP 的“长期运行”授权，系统会立即取消所有未执行的 24 h 周期任务，因此需要监听 PackageManager.getBackgroundPermissionSetting() 变化，动态重新注册。 - 车载 Android（AAOS）场景下，车机常通电，是否还受 24 h 限制？
答：AAOS 仍继承 AOSP 的 JobScheduler 24 h 窗口，但车机厂商可把 WorkManager 底层换成自己实现的 CarJobScheduler，彻底拿掉 24 h 上限；作为第三方 APK，想利用这一特性必须加入车厂白名单并签名到系统证书，否则依旧受限。