Question

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

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

是真的吗？
render queue是否作为单独的队列存在？它是渲染回调的别名吗？
呈现哪些回调？当我进行任何重绘时，都是渲染回调
还有其他类型的队列吗？如果在哪里可以了解到它们？

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

来自不同任务源的
任务可以放在不同的任务队列中

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

Answer 1

根据HTML规范，对此问题最重要的一点是在task-source definition中，我们可以阅读：

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

Note

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

Example

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

在task queue definition中：

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

总而言之，规范仅要求每个事件循环至少具有一个任务队列。他们将不涉及关于任务队列的更多规范，而是使用任务源，即用户代理（UA）将链接到任何任务队列< / em>，只要他们按顺序执行每个任务源中的任务，他们便希望自己认为合适。

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

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

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

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

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

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

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

就在这里，他们告诉UA，他们有权从哪个任务队列中进行选择，以从中选择下一个任务。这意味着，例如，如果他们有一个专用的 task队列用于用户交互任务源，而另一个仅用于 networking任务源 ，并且都包含等待的任务，然后他们可以自由选择要先运行的任务。

现在，关于渲染，如果我们查看执行此任务后处理模型的运行情况，那么所有微任务也都已完成，并且进行了大量测量，我们看到了在第11步，他们应该update the rendering。这实际上是所有事件循环迭代的一部分（在Window上下文中），但是此算法的第一步是定义这是否确实是渲染帧，这意味着在大多数情况下，它将不做任何事情就提前退出。
不过，当它是一个渲染框架时，它必须执行所有渲染步骤，这是事件循环迭代的一部分，即在执行了 normal 任务之后。
因此，从规格的角度来看，我们在这里不能真正讨论优先级，它只是每个事件循环迭代的一部分，就像微任务检查点一样，它不会返回到步骤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）渲染队列是否作为单独的队列存在？还是渲染回调的别名？

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

3）呈现哪些回调？在我进行任何重绘时，都是渲染回调

这一切都在update the rendering中，但是您可能要专注于第5步之后的内容，因为之前只是做一些检查。

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

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

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

作为一个例子，我想向您指出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)方法，允许我们控制任务的优先级。

Answer 2

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

通过阅读下面的链接，我认为是这样。

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

下面的链接说它是相同的任务队列，即“事件”任务队列。

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

我认为渲染回调基本上是浏览器根据dom的最新更新定期尝试重新绘制/渲染屏幕的过程。

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

是，请在此处查看详细信息：https://html.spec.whatwg.org/multipage/webappapis.html#task-queue

这似乎是对此的最佳覆盖：https://html.spec.whatwg.org/multipage/webappapis.html#event-loops

Answer 3

除非我有误解，否则我认为这是不正确的。这是我当前的信息来源。

“在执行每个宏任务之后，引擎会立即执行微任务队列中的所有任务，然后再运行其他宏任务或渲染或其他任何操作。”

https://javascript.info/event-loop

以下是我的代码段中未进行的实验，但它证明了.then中button_one()的微轨迹优先于按钮上的渲染更改。您可以从"button one out"的控制台输出中看到，微任务位于按钮功能之后。


<body>
    <button id="but_one" onclick='button_one()'>Click me</button>
    <button id="but_two" onclick='button_two()'>Reset</button>
</body>
<script>
    function button_one() {
        console.log("button one clicked")
        document.getElementById("but_one").innerText ='YouClickedMe';
        autoResolve().then(msg =>{
            console.log("Inside resolve callback")
            sleep(5000)
        });
        console.log("button one out")
    }

    function button_two() {
        document.getElementById("but_one").innerText = 'Click me';
    }

    function sleep(milliseconds) {
        const date = Date.now();
        let currentDate = null;
        do {
            currentDate = Date.now();
        } while (currentDate - date < milliseconds);
    }

    async function autoResolve() { return "resolved" }
</script>

</html>

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

3 个答案: