WorkManager任务执行模型解析

聊到优先级调优，必须先搞清楚WorkManager到底怎么调度任务的。我记得刚接手一个视频编辑App的性能优化时，发现主页帧率总是不稳定。后来一查，原来是后台WorkManager的任务和前台渲染抢CPU。说白了，就是任务调度模型没搞明白。

核心调度架构

WorkManager的任务执行，不是简单地启动一个线程就跑。它背后有一套完整的“排队 - 调度 - 执行”机制。我画了一张执行模型结构图，帮你把这件事看清楚。

三阶段模型详解

任务从发出到跑完，经历三个阶段。每个阶段都可能成为帧率抖动的根源。我带你过一遍。

阶段一：任务入队与优先级标记

你调用 enqueue() 时，任务不会立刻执行。WorkManager 会把它丢进对应优先级的队列。默认是所有任务走 默认优先级队列。如果你想调整，就得显式设置 setExpedited() 或者通过 WorkRequest.Builder 设置优先级参数。

阶段二：任务调度与Worker分配

调度器干三件事：排序、检查预算、分配Worker。我来拆开说。

• 排序：高优先级任务始终排在前面。默认优先级任务只有在没有高优先级任务时才能拿到Worker。
• 预算约束：WorkManager默认给App一个“同时执行任务数”的上限。我遇到过的默认值是 2个 后台Worker。也就是说，就算你有10个任务排队，同一时刻最多跑2个。
• Worker分配：调度器从线程池里拿空闲线程。如果线程池满了，高优先级任务可以触发 抢占 机制。

阶段三：Worker执行与抢占

Worker在跑任务时，可能会遇到被抢占的情况。什么叫抢占？就是高优先级任务来了，低优先级的Worker还没跑完，系统会把它暂停，腾出线程给高优先级的任务。

嗯，这里要注意。被抢占的任务不会丢，它会回到队列头部。下次轮到它时再重新执行。但这意味着：低优先级任务可能被无限推迟，如果高优先级任务持续入队的话。

触发场景	抢占结果	影响帧率
高优先级任务入队，线程池已满	最低优先级的Worker被暂停	低优先级任务延迟，不影响前台渲染
默认优先级任务执行中	不会被抢占，但无法获得新Worker	可能导致后台积压，间接影响前台
同优先级任务排队	按FIFO顺序执行	一般无明显抖动

线程池与CPU资源争夺

WorkManager的线程池，默认大小是 MAX(2, CPU核心数 - 1)。我遇到过一台8核设备，WorkManager最多能开7个线程。你想想看，这7个线程如果都在执行CPU密集型的后台任务，前台渲染线程（UI Thread）能抢到的时间片就少得可怜。

所以，并不是所有任务都适合用WorkManager跑。做UI动画的时候，后台任务越少越好。优先级调优的本质，就是确保UI线程拿到足够的CPU时间片。

关键配置参数一览

我整理了几个影响任务执行模型的关键参数。你在调优时重点关注。

参数	默认值	调优建议
WorkManager.setMaximumPoolSize()	MAX(2, CPU核心数-1)	核心数-2 或 核心数/2，减少后台线程
WorkRequest.setExpedited()	False	重要且短的任务设为true
WorkRequest.setInitialDelay()	0ms	避开高负载时间段（如页面滚动时）
Worker.getRunAttemptCount()	1	用于判断是否因抢占被重试