事件循环中有哪些类型的队列？

Question

render queue我在不同的文章（例如，例如）中都提到了两位作者都说

渲染回调被赋予最高优先级

1. 这是真的吗？
2. 是否render queue作为单独的队列存在或者是渲染回调的别名？
3. 渲染哪些回调？当我进行任何重绘时，都会进行渲染回调
4. 是否还有其他类型的队列？如果有，我可以在哪里阅读有关它们的信息？

在w3.org中我们可以阅读

来自不同任务源的任务可能会被放置在不同的任务队列中

但没有提及类型或优先级

Answer 1

从 HTML 规范来看，关于这个问题最重要的一点是在任务源定义中，我们可以在其中读到：

根据其源字段，每个任务都被定义为来自特定的任务源。对于每个事件循环，每个任务源必须与特定的任务队列关联。

Note

本质上，任务源在标准中用于分离逻辑上不同类型的任务，用户代理可能希望区分这些任务。用户代理使用任务队列来合并给定事件循环内的任务源。

Example

例如，用户代理可以有一个用于鼠标和按键事件的任务队列（与用户交互任务源关联），以及另一个与所有其他任务源关联的任务队列。然后，利用事件循环处理模型的初始步骤中授予的自由度，它可以在四分之三的时间里让键盘和鼠标事件优先于其他任务，从而保持界面响应，但不会让其他任务队列挨饿。请注意，在此设置中，处理模型仍然强制用户代理永远不会无序地处理来自任何一个任务源的事件。

在任务队列定义中：

事件循环有一个或多个任务队列。任务队列是一组任务。

总而言之，规范只要求每个事件循环至少有一个任务队列。他们不会深入了解有关任务队列的更多规范，而是使用任务源，用户代理 (UA) 将链接到他们希望的任何任务队列，但他们认为合适，只要执行每个任务源中的任务即可为了。

HTML 规范中使用了许多任务源，例如这里是通用任务源的列表，但每个规范都可以定义自己的任务源，就像Message API一样，其中每个MessagePort对象都有自己的任务源！（意味着 UA 可以将每个消息任务源映射到不同的任务队列）。

获得所有任务源的广泛列表实际上是不可能的，也不是很有用，因为它们实际上可能全部出现在同一个且唯一的任务队列中。

我们需要查看的规范中另一个非常重要的部分是事件循环处理模型。

该算法定义了事件循环在每次迭代时应经历的所有步骤。
乍一看有点复杂，而且随着时间的推移，它并没有变得简单，因为越来越多的上下文都遵循这个模型，需要处理非常不同的问题（看看 Worker 中的 OffscreenCanvas...）。

但是，对于我们在这里感兴趣的内容，让我们假设它很简单并且我们处于 Window 上下文中。

第一步是根据规范设计任务优先级：

让taskQueue成为事件循环的任务队列之一，以实现定义的方式选择[...]

就在这里，他们对 UA 说，他们有权从哪个任务队列中选择下一个任务。这意味着，例如，如果他们有一个用于用户交互任务源的专用任务队列，另一个仅用于网络任务源，并且两者都包含等待的任务，那么他们可以自由选择他们喜欢先运行的任务队列。

现在关于渲染，如果我们看看执行此任务后处理模型的情况如何，所有微任务也是如此并且进行了一堆测量，我们看到在步骤 11中，它们应该更新渲染。这实际上是所有事件循环迭代的一部分（在 Window 上下文中），但该算法的第一步是定义这是否确实是渲染帧，这意味着大多数时候它只会提前退出而不执行任何操作。
但是，当它是渲染帧时，它必须执行所有渲染步骤，作为事件循环迭代的一部分，即可能在执行正常任务之后。
因此，从规范的角度来看，我们不能在这里真正谈论优先级，它只是每个事件循环迭代的一部分，就像微任务检查点一样，它不会回到步骤1 ，在那里他们可以选择什么任务为了执行，它们被迫执行事件循环的该部分。_{尽管从技术上讲，在渲染步骤中，UA 还负责确定何时有“渲染机会”，因此如果他们愿意，他们实际上可以设置优先级。}

因此，对于我们网络作者来说，这意味着是的，我们可以requestAnimationFrame在一个任务（或任何其他任务）之前触发回调setTimeout(fn, 0)，至少在调用此requestAnimationFrame()方法的一个任务本身是在一个任务开始时执行的情况下是如此。渲染帧。

这实际上可能经常发生，这里有一个小片段，应该可以使它在 Firefox 中非常可靠地发生，有时在 Chrome 中：

/*
  In latest FF and Chrome browsers, UI events like mousemove are being throttled by the UA.
  (as recommended by the specs)
  They make the limit rate match the one of the screen-refresh, like resize or scroll events.
  However, at least in Firefox they don't make it part of the 'update the rendering' algorithm,
  but execute it as a normal task.
  So a 'mousemove' event in this browser actually gives us accesss to the first step of a 'rendering frame'.
  
  This simple snippet tries to demonstrate that,
  if successful, "rAF" should always be logged first.
*/
onmousemove = (evt) => {
  console.clear();
  setTimeout( () => console.log( 'timeout' ), 0 );
  requestAnimationFrame( () => console.log( 'rAF' ) );
};

move your mouse over the frame

现在我们可以回答您的所有观点：

1) 渲染回调被赋予最高优先级。这是真的吗？

正如我们刚刚演示的那样，事实并非如此，即使渲染回调可能会在与调度它们的任务相同的事件循环迭代中执行，我们也不能在这里真正讨论优先级。

2）渲染队列是否作为单独的队列存在，或者是渲染回调的别名？

规格上，没有定义任何特殊的任务队列，但也没有用于渲染的任务源。渲染算法的更新由许多要执行的不同任务组成，其中包含您可能提到的运行动画帧回调命令。但这些回调存储在 Map 中，而不是队列中。

3）渲染哪些回调？当我进行任何重绘时，都会进行渲染回调

这一切都在更新渲染中，但您可能希望重点关注步骤 5之后的内容，因为之前只是一些检查。

4）是否还有其他类型的队列？如果有，我可以在哪里阅读有关它们的信息？

正如已经说过的，规范没有定义任务队列，并且任务源的定义过于松散，无法给出完整的列表。

但请记住，所有这些都是从规格的角度来看的。实施者可能在很多方面偏离该模型，并且该模型本身足够宽松，可以允许一大堆不同的设置。

作为一个例子，我想向您指出一个Firefox 问题，其中引入了一个非常有趣的案例：
他们希望setTimeout回调的优先级低于其他任务，但仅限于页面加载时。为此，他们确实创建了一个新的任务队列，专门用于这种情况。
现在，在 Firefox 中，setTimeout回调的优先级低于其他任务，但仅限于页面加载时：

function test() {
  setTimeout( () => console.log('timeout'));
  onmessage = (evt) => console.log('message');
  postMessage('', '*');
}
console.log('at page load');
test();

setTimeout( () => {
  console.log('after page load');
  test();
}, 1000 );

/* results in Firefox:
at page load
message
timeout
after page load
timeout
message

Chrome will always print "message" first, but because they have a 2ms min timeout on setTimeout
*/

另一件需要注意的事情是可能传入的Prioritized postTaskAPI，我们已经可以在 Chrome 中使用它#enable-experimental-web-platform-features，并且它公开了一个scheduler.postTask(fn, priority)方法，允许我们控制任务优先级。