javascript - 事件队列中有哪些类型的队列？

Question

我在不同的文章(example，example)中都提到了render queue两位作者都说

render callback is given the highest priority

是真的吗？

render queue是否作为单独的队列存在？
它是渲染回调的别名吗？

呈现哪些回调？当我进行任何重绘时，渲染回调

是否还有其他类型的队列，并且在哪里可以找到它们？

在 w3.org中，我们可以阅读

tasks from different task sources may be placed in different task queues

但是没有提及类型或优先级

Answer 1

从HTML规范中，最重要的一点是在task-source definition中，我们可以阅读:

Per its source field, each task is defined as coming from a specific task source. For each event loop, every task source must be associated with a specific task queue.

Note

Essentially, task sources are used within standards to separate logically-different types of tasks, which a user agent might wish to distinguish between. Task queues are used by user agents to coalesce task sources within a given event loop.

Example

For example, a user agent could have one task queue for mouse and key events (to which the user interaction task source is associated), and another to which all other task sources are associated. Then, using the freedom granted in the initial step of the event loop processing model, it could give keyboard and mouse events preference over other tasks three-quarters of the time, keeping the interface responsive but not starving other task queues. Note that in this setup, the processing model still enforces that the user agent would never process events from any one task source out of order.

在 task queue definition中:

An event loop has one or more task queues. A task queue is a set of tasks.

综上所述，规范仅要求每个事件循环至少具有一个任务队列。他们将不再详细介绍任务队列，而是使用任务源，只要执行每个任务源中的任务，用户代理(UA)便会链接到他们希望的任何任务队列，只要他们认为合适即可。为了。

HTML规范中使用了许多任务源，例如 here is a list of the generic ones，但是每个规范都可以定义自己的任务源，就像 Message API一样，其中每个MessagePort对象都将拥有自己的任务源! (意味着UA可以将这些消息任务源中的每一个映射到不同的任务队列)。

不可能获得所有任务源的详尽列表，也不是真正有用的，因为它们实际上可能全部都位于相同且唯一的任务队列中。

我们需要查看的规格的另一个非常重要的部分是 event loop processing model。

该算法定义了事件循环在每次迭代中应执行的所有步骤。
乍看之下，它有点复杂，而且随着时间的流逝，它并没有得到简化，因为越来越多的上下文都遵循此模型，并且要处理的问题非常不同(请在Worker中查看OffscreenCanvas ...)。

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

The first step是由规范设计任务优先级的地方:

Let taskQueue be one of the event loop's task queues, chosen in an implementation-defined manner [...]

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

现在关于渲染，如果我们看一下执行此任务后处理模型的运行方式，所有微任务也是如此，并进行了大量测量，我们看到在步骤11中，它们应该为 update the rendering。这实际上是所有事件循环迭代的一部分(在Window上下文中)，但是此算法的第一步是定义这是否确实是渲染帧，这意味着在大多数情况下，它将不做任何事情就提前退出。
但是，当它是一个渲染框架时，它必须执行所有渲染步骤，作为事件循环迭代的一部分，即在执行正常任务之后。
因此，从规格的 Angular 来看，我们在这里不能真正谈论优先级，它只是每个事件循环迭代的一部分，就像微任务检查点一样，它不会返回到步骤1，他们可以选择什么任务为了执行，他们被迫执行事件循环的那一部分。尽管从技术上讲，在渲染步骤中，UA还是负责确定何时具有“渲染机会”的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) render callback is given the highest priority. Is it true?

正如我们刚刚演示的那样，虽然不是真的，尽管渲染回调可能会在与安排它们的任务相同的事件循环迭代中执行，但我们在这里不能真正讨论优先级。

2) Does render queue exist as separate queue or is it alias for render callbacks?

规范，没有定义任何特殊的任务队列，但是也没有用于渲染的任务源。 update the rendering算法由许多要执行的不同任务组成，并且其中包含您可能要引用的 run the animation frame callbacks命令。但是这些回调存储在Map中，而不是存储在队列中。

3) Which callbacks are render? As I take in any repaint is render callback

所有这些都在 update the rendering中，但是您可能要关注步骤5之后的内容，因为之前只是进行一些检查。

4) Are there any other types of queues and if there are where can I read about them?

如前所述，规范没有定义任务队列，并且任务源定义过于宽松，无法提供完整的列表。

但是请记住，所有这些都是从规范的 Angular 来看的。实现者可能会在许多方面偏离该模型，并且该模型本身过于宽松，无法进行一整套不同的设置。

例如，我想为您指出 Firefox issue，它引入了一个非常有趣的情况:
他们希望 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 postTask API，我们已经可以在#enable-experimental-web-platform-features标志下在Chrome中播放它了，它公开了scheduler.postTask(fn, priority)方法，该方法允许我们控制任务优先级。