把后台任务赶到空闲帧里跑：requestIdleCallback 与优先级调度的时机控制

把后台任务赶到空闲帧里跑requestIdleCallback 与优先级调度的时机控制一、埋点上报拖垮了首屏交互后台任务的时机错配某数据看板产品上线后收到一批投诉中端安卓机上点击图表后卡顿近 200 毫秒才响应。排查发现埋点上报逻辑挂在点击回调里同步执行预取下一屏数据、离线聚合缓存等不紧急但占主线程的任务也全挤在交互间隙同步跑。INP 直接飙到 380 毫秒。这事我见过太多团队栽进去——把后台任务当同步任务写主线程被吃干净。浏览器一帧约 16.6 毫秒60 帧/秒。主线程要在这段时间内完成 JavaScript 执行、样式计算、布局、绘制与合成。任何一段超时都会掉帧。非紧急任务若插在帧中段会和渲染抢时间片。用户感知到的就是点一下卡一下。把这类任务推迟到帧的空闲期执行是根本解法。浏览器在完成一帧渲染后若还有剩余时间会进入空闲期。requestIdleCallback 就是浏览器为这类需求提供的原生 API把回调注册到空闲期避免与渲染抢主线程。但空闲期不稳定。繁忙帧的空闲时间可能为 0任务可能延迟多帧甚至多秒。因此必须配合 timeout 兜底与任务切片才能在生产环境稳定运行。二、idle deadline 时间预算与调度优先级空闲期的底层机制requestIdleCallback 把回调注册到帧的空闲期。浏览器在完成一帧的渲染后若还有剩余时间就调用 idle 回调。回调收到一个 deadline 对象timeRemaining() 返回当前帧剩余毫秒数didTimeout 标识任务是否已超时。这套机制有三个关键点。第一时间预算。每帧空闲时间不稳定繁忙帧可能为 0。回调里必须主动检查 timeRemaining不够就 reschedule把剩余工作推到下一帧。否则会在空闲期跑超时又把下一帧拖垮。第二timeout 兜底。注册时可传 { timeout } 选项。若空闲期迟迟不来到 timeout 后浏览器会强制调度回调didTimeout 为 true。这避免了任务饿死。但要注意timeout 触发的回调可能打断渲染需谨慎设置。第三任务切片。长任务不能一次性跑完。必须切片循环每片跑完检查预算不够就 reschedule 剩余切片。React Scheduler 的 timeSlicing 就是这套思路。scheduler.postTask 是新的优先级调度 API提供 userblocking、user-visible、background 三级优先级比 requestIdleCallback 更精细。但目前仅 Chromium 系支持Safari 与 Firefox 尚未跟进。生产环境仍需降级到 requestIdleCallback setTimeout 组合。SSR 环境没有 requestIdleCallback服务端不存在帧与空闲期的概念。必须做兜底降级为同步执行或 setTimeout避免同构应用在服务端报错。综上帧内空闲时间调度把后台任务塞进渲染时间片的夹缝里先预算检查确认当帧还有余量再切片执行、超额即让出确保重活不抢占渲染。把这条节奏守住长任务与高帧率就能共存。三、生产级优先级任务调度器实现下面给出一个可复用的调度器封装。它支持三级优先级、timeout 兜底、任务切片与 SSR 降级。type Priority high | normal | low; interface Task { id: number; // fn 返回 true 表示任务未完成需 reschedule 剩余切片 fn: (deadline: { timeRemaining: () number; didTimeout: boolean }) boolean; priority: Priority; timeout: number; } class IdleScheduler { // 三级队列分开存放出队时按优先级取 private queues: RecordPriority, Task[] { high: [], normal: [], low: [], }; private taskId 0; private isRunning false; // SSR 与旧浏览器特性检测决定走原生 API 还是降级 private readonly SUPPORTED typeof window ! undefined requestIdleCallback in window; // 注册任务返回 id 供外部取消 schedule( fn: Task[fn], options: { priority?: Priority; timeout?: number } {} ): number { const priority options.priority ?? normal; // 低优先级任务给较长 timeout避免被强制调度打断渲染 const timeout options.timeout ?? (priority high ? 1000 : priority normal ? 3000 : 5000); const id this.taskId; this.queues[priority].push({ id, fn, priority, timeout }); this.run(); return id; } cancel(id: number) { for (const p of Object.keys(this.queues) as Priority[]) { this.queues[p] this.queues[p].filter((t) t.id ! id); } } private run() { if (this.isRunning) return; this.isRunning true; if (this.SUPPORTED) { // 优先级越高timeout 越短越早被强制调度 requestIdleCallback(this.loop, { timeout: 2000 }); } else { // SSR 或旧浏览器降级用 setTimeout 模拟给 5ms 预算避免阻塞 setTimeout(() this.loop({ timeRemaining: () 5, didTimeout: true }), 0); } } private loop (deadline: { timeRemaining: () number; didTimeout: boolean; }) { this.isRunning false; const task this.dequeue(); if (!task) return; try { const unfinished task.fn(deadline); if (unfinished) { // 任务未完成重新插回队首等下一帧继续 this.queues[task.priority].unshift(task); } } catch (err) { // 单任务异常不影响调度器整体运行记录后丢弃 console.error([IdleScheduler] task error, err); } // 帧内还有预算且还有任务继续跑否则 reschedule 到下一帧 if (this.hasTasks() deadline.timeRemaining() 0) { this.loop(deadline); } else if (this.hasTasks()) { this.run(); } }; // 出队策略high 优先级队列非空则取其次 normal最后 low private dequeue(): Task | null { for (const p of [high, normal, low] as Priority[]) { if (this.queues[p].length) return this.queues[p].shift()!; } return null; } private hasTasks(): boolean { return ( this.queues.high.length this.queues.normal.length this.queues.low.length 0 ); } } export const idleScheduler new IdleScheduler();关键点在于三处。其一三级优先级队列高优先级先出队保证紧急任务不被低优先级阻塞。其二任务返回布尔值标识是否完成未完成则重新插回队首实现切片。其三SSR 与旧浏览器降级到 setTimeout保证同构应用不报错。某监控平台接入后埋点与预取全部推到空闲期P75 INP 从 380 毫秒降到 140 毫秒。四、空闲调度的代价任务延迟、优先级反转与适用边界空闲调度并非无损。任务延迟是最直接的代价。空闲期不稳定繁忙时段任务可能延迟数秒甚至更久才执行。某埋点上报曾因页面持续滚动延迟 8 秒才发出导致部分用户行为数据丢失。对实时性要求高的任务不能用这套机制。优先级反转是更隐蔽的问题。低优先级任务可能占满空闲时间高优先级任务反而排不到。这就是为什么必须给高优先级任务设短 timeout让浏览器强制调度。某报表预取曾因埋点队列堆积被延迟 12 秒才执行用户切到该页时空白。后来把预取提为 high 优先级并设 1 秒 timeout问题消失。Safari 支持不完整。requestIdleCallback 在 Safari 早期版本中不可用需 polyfill 或降级到 setTimeout。生产环境必须做特性检测不能假设 API 一定存在。适用边界埋点上报、数据预取、离线计算、日志聚合、非关键数据预处理等场景收益最高。用户交互响应、动画、首屏关键数据请求不适合走 idle必须即时执行否则体验会反向恶化。五、总结后台任务的时机控制核心是把非紧急工作推到帧的空闲期配合 timeout 兜底与任务切片。落地建议第一用 requestIdleCallback 注册回调回调内主动检查 timeRemaining不够就 reschedule。第二按任务紧急度设 timeout高优先级短 timeout避免饿死。第三长任务切片每片跑完检查预算未完成重新入队。第四SSR 与旧浏览器降级到 setTimeout保证同构应用不报错。第五实时性要求高的任务不走 idle必须即时执行。这条路在中后台与内容站的高频交互场景下能跑通回报是值得的。