scheduler.yield 怎么把长任务拆开又保持优先级

scheduler.yield() 的作用不是把工作交给另一个线程，而是结束当前任务，把后续代码安排成一个新的 continuation。浏览器因此有机会先处理输入、渲染或更高优先级任务，然后再从 await 后继续执行。

要同时做到“拆开长任务”和“保持优先级”，应把整项工作放进 scheduler.postTask()，再在回调内部多次 await scheduler.yield()。continuation 会继承外围任务的优先级；若直接调用，默认优先级是 user-visible。

参考入口：https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/yield

规范草案：https://wicg.github.io/scheduling-apis/

先找出真正需要让出的长任务

适合切片的是可以分段推进的同步工作，例如批量格式化数据、逐批创建 DOM 节点、解析一组记录或计算多个彼此独立的条目。每完成一小段就归还主线程，用户输入和绘制才有机会穿插执行。

如果一次函数调用本身就持续很久，在它结束前插入 yield() 没有帮助。此时应继续拆小函数，或把纯计算迁移到 Web Worker。scheduler.yield() 只在代码真正执行到 await 时才能让出控制权。

用最小封装接入 scheduler.yield

这个 API 目前仍是 Limited availability，不能假设所有浏览器都支持。最小封装先检查 globalThis.scheduler?.yield，支持时使用原生 continuation，不支持时用定时器创建一个普通新任务。

async function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    // 原生 continuation 能参与浏览器优先级调度。
    await globalThis.scheduler.yield();
    return;
  }

  // 降级只保证切开任务，不提供优先级继承语义。
  await new Promise((resolve) => setTimeout(resolve, 0));
}

不要把 Promise.resolve() 当作降级方案。它只排入微任务，连续微任务仍可能阻止浏览器进入下一个任务并完成渲染。定时器虽然有延迟和节流规则，至少会把 continuation 放到新的任务中。

按时间预算而不是固定条数切片

固定“每 100 条让出一次”在高端设备上可能过于频繁，在低端设备上又可能太晚。更稳妥的起点是观察当前片段已运行多久，达到预算后再让出。下面的 8ms 只是示例起点，不是浏览器保证值，应根据页面交互和设备数据调整。

async function processInChunks(items) {
  let sliceStart = performance.now();

  for (const item of items) {
    updateIndex(item); // 单项工作必须足够小，才能形成有效切分点。

    if (performance.now() - sliceStart >= 8) {
      await yieldToMain(); // 到达预算后归还主线程。
      sliceStart = performance.now();
    }
  }
}

切片预算越短，交互机会通常越多，但调度次数也会增加，整项工作可能更晚完成。先从关键交互页面测量，再决定是 4ms、8ms、16ms，还是按业务阶段设置不同预算。

在 postTask 中继承任务优先级

scheduler.yield() 本身没有优先级参数。独立调用时默认使用 user-visible；如果它位于 scheduler.postTask() 回调内，continuation 会继承外围任务的优先级。规范定义了 user-blocking、user-visible 和 background 三档。

const controller = new AbortController();

const job = scheduler.postTask(
  async () => {
    for (const item of analyticsQueue) {
      aggregate(item); // 后台统计按小单元推进。
      await scheduler.yield(); // 继承 background 优先级和取消信号。
    }
  },
  {
    priority: "background",
    signal: controller.signal, // 页面状态失效时可以取消后续 continuation。
  },
);

// 路由离开或数据版本变化时调用：controller.abort("stale");
await job;

同一优先级内，yield continuation 会进入提升后的队列，可把它理解为比同级普通 postTask() 更靠前；但更高优先级任务仍然先执行。这个设计既让已开始的工作能继续推进，也避免后台工作越过紧急交互。

把取消和兼容降级纳入失败处理

长任务经常依赖当前页面、筛选条件或数据版本。当条件已变化，继续跑完旧任务不仅浪费资源，还可能覆盖新结果。将 AbortSignal 传给 postTask() 后，待执行的 continuation 可随外围任务一起取消；await scheduler.yield() 可能以取消原因拒绝，因此调用方应把取消与真正故障分开处理。

try {
  await job;
} catch (error) {
  if (controller.signal.aborted) {
    // 取消属于预期控制流，不上报为脚本故障。
    console.info("后台任务已取消", controller.signal.reason);
  } else {
    // 真实异常继续交给统一监控。
    reportError(error);
  }
}

兼容降级也要明确边界：setTimeout(0) 可以改善“一个同步任务占满主线程”的问题，却不能模拟 postTask 的优先级、动态优先级或继承取消语义。如果业务依赖这些能力，应在不支持时改走简化路径，而不是假装语义完全一致。

用响应性指标复盘切片效果

接入 yield 后，至少同时观察三类结果：长任务数量或持续时间是否下降，用户输入到下一次绘制是否更及时，整批工作完成时间是否增加过多。只看总耗时容易误判，因为切片的目标是用少量吞吐代价换取更稳定的响应性。

• 确认热点函数内部确实存在多个可到达的 await 切分点。
• 在支持和不支持 Scheduler API 的环境分别走一遍功能路径。
• 检查后台任务是否保持 background，关键交互是否使用更合适的优先级。
• 触发路由切换或数据失效，确认后续 continuation 能停止。
• 比较切片前后的长任务、输入延迟和批处理完成时间，再调整预算。

常见问题

scheduler.yield 会自动把代码移到 Worker 吗？

不会。continuation 仍在原来的 Window 或 Worker 全局环境中运行；在主线程调用时，后续代码仍回到主线程，只是被安排到一个新的任务。

为什么 yield 后还能保持 background 优先级？

因为调用发生在设置为 background 的 postTask 回调内。continuation 继承包含它的任务优先级，而不是重新使用默认的 user-visible。

可以在每次循环都调用 yield 吗？

可以，但通常没有必要。过度切分会增加调度开销并拉长完成时间。按运行时间或阶段边界让出，通常比固定每项都让出更稳妥。

requestIdleCallback 能完全替代它吗？

不能完全替代。requestIdleCallback 面向空闲工作；scheduler.yield 面向当前任务的 continuation，并能继承优先级。两者适用的调度意图不同。

简化成一句话：用 yield() 建立切分点，用 postTask() 定义优先级和取消边界，再用特性检测保证不支持时仍能运行。这样长任务不再一次占满主线程，任务的重要性也不会在每次让出后丢失。