📚 课程目录第4章优先级概念（PERIODIC、ONETIME、延迟等）

优先级概念：PERIODIC、ONETIME 与延迟任务

先聊个核心问题。

你想想看，同样都是后台任务，为什么有的会卡帧，有的不会？

答案其实就俩字：优先级。

我刚开始接触 WorkManager 时，也觉得优先级不就是“重要”、“不重要”嘛。后来踩了坑才明白，这东西在 Android 系统里，比你想象的要复杂得多。

核心观点：WorkManager 的优先级不是简单的高中低，它由任务类型 + 约束 + 延迟策略共同决定。弄错一个环节，帧率就抖一下。

三大任务类型

WorkManager 给我们提供了三种基本任务类型。说白了，就是三个不同的“插队”方式。

任务类型	核心特点	典型场景	对帧率的影响
`OneTimeWorkRequest`	单次执行，立即或延迟调度	日志上传、数据同步	高（容易抢占UI线程资源）
`PeriodicWorkRequest`	周期性重复，最小间隔15分钟	定时拉取、后台心跳	中等（重复叠加可能造成累积抖动）
延迟任务（`setInitialDelay`）	任何任务+延迟执行	启动后延迟上报、非紧急清理	低（错峰执行，缓解帧率压力）

OneTimeWorkRequest——最容易被误用的任务

在我优化过的一个电商 App 里，团队习惯把所有请求都做成 OneTimeWorkRequest。

结果呢？

每次用户滑动商品列表时，后台的日志上传任务就“蹭”地窜上来。帧率直接从 60 掉到 40。

// 错误写法：未设置延迟，抢占UI资源
val uploadWork = OneTimeWorkRequestBuilder<LogUploadWorker>()
    .build()

为什么这样会卡？

OneTimeWorkRequest 默认是立即尝试执行的。如果系统当前处于 UI 繁忙状态，它依然会挤进线程池，争夺 CPU 时间片。帧率抖动就这么来了。

我的习惯：只要不是用户主动触发的操作，我全部加一个最小延迟 setInitialDelay(5, TimeUnit.SECONDS)。等 UI 空闲了再说。

// 推荐写法：加延迟，避开UI忙碌期
val uploadWork = OneTimeWorkRequestBuilder<LogUploadWorker>()
    .setInitialDelay(5, TimeUnit.SECONDS)
    .build()

PeriodicWorkRequest——定时任务的陷阱

这玩意儿，最坑爹的就是“重复”。

你以为只执行一次，实际上它每隔一段时间就会再蹦出来。多个周期的任务叠在一起，对帧率的杀伤力是叠加的。

举个例子：

你有一个 15 分钟一次的清理任务，还有一个 30 分钟一次的数据同步任务。如果它们触发时间恰好重合，系统就要同时拉起两个 Worker。CPU 负载翻倍，帧率直接跳水。

我曾经遇到过：某款天气 App，后台同时跑了 5 个周期任务。结果每次整点时刻，首页滑动就卡成 PPT。排查后发现，5 个任务的周期全是 15 分钟的整倍数，恰好同时触发。

解决方案？

给每个周期任务加一个随机偏移量。让它们错开，别扎堆。

// 给Periodic任务加随机偏移，避免扎堆
val periodicWork = PeriodicWorkRequestBuilder<CleanupWorker>(
        15, TimeUnit.MINUTES
    )
    .setInitialDelay(
        Random.nextLong(0, 300), // 随机偏移0-5分钟
        TimeUnit.SECONDS
    )
    .build()

延迟任务——帧率救星

说真的，延迟任务是我在性能优化时最常用的武器。

它的本质，就是把“必须做的事”推迟到“UI 不忙的时候”再做。

系统会根据你设定的延迟时间，在后台线程空闲时再拉起来执行。不像 OneTimeWorkRequest 那样霸蛮。

什么场景最适合用延迟？

启动后的非关键上报：比如首次启动后 10 秒才上传设备信息。
用户操作结束后的清理：比如离开详情页 5 秒后，才清理缓存。
低优先级的网络请求：比如预加载下一屏数据，延迟 1 秒。

// 延迟任务的经典写法
val lazyReport = OneTimeWorkRequestBuilder<LazyReportWorker>()
    .setInitialDelay(
        10, TimeUnit.SECONDS // 延迟10秒
    )
    .build()

优先级的内在逻辑

这三大类型之间，其实是有一套隐形的优先级排序的：

OneTimeWorkRequest（无延迟） > OneTimeWorkRequest（有延迟） > PeriodicWorkRequest（首次触发） > PeriodicWorkRequest（后续周期） > 延迟任务（超长延迟）

但要注意，这套排序不是的。系统会根据电量、网络状态、内存压力动态调整。说白了，WorkManager 有自己的“小算盘”。

关键认知：我们无法完全控制 WorkManager 的调度顺序，但可以通过合理选择任务类型 + 延迟策略，大幅降低对 UI 线程的冲击。

下面这张图，可以帮你快速理解整个优先级体系的脉络：

如何正确选择优先级类型？

我自己的选择原则其实就三条：

用户可见操作 → OneTimeWorkRequest（无延迟），但一定要确保 Worker 内操作轻量，不碰 UI。
后台定时任务 → PeriodicWorkRequest + 随机偏移，避免与 UI 渲染周期重叠。
非关键、可等待的任务 → 延迟任务，延迟时间越长，对帧率影响越小。

避坑指南：我曾经把一个大文件下载任务设成 PeriodicWorkRequest，想着每天执行一次。结果每次下载时，App 都卡得不行。原因就在于下载占用了大量网络和 CPU 资源。后来我改为 OneTimeWorkRequest + 延迟，只在用户打开 App 且空闲 30 秒后再下载。帧率稳了，用户也无感知。

小结

优先级不是死板的数字，而是一种调度策略的选择。

OneTimeWorkRequest 像“插队”，PeriodicWorkRequest 像“闹钟”，延迟任务像“等红灯”。

该插队的时候插队，该等红灯的时候等红灯。

你的帧率，就是这么被一点一点保护下来的。