javascript - Which types of queues are in event loop?

从 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)方法，它允许我们控制任务的优先级。

javascript - Which types of queues are in event loop?

问题描述

解决方案

推荐阅读