这是一个创建于 1382 天前的主题，其中的信息可能已经有所发展或是发生改变。
定个优先级不就好了吗? 还搞 2 个异步 queue
 |
1
autoxbc 2020-07-06 20:52:38 +08:00
所以楼主是不理解这个设计，还是理解了觉得不好
|
 |
4
WhoAmIAndwhoAreU 2020-07-06 21:11:01 +08:00
微任务中产生了新的宏任务会在下一次 Event Loop 执行的微任务之前执行，明白？
|
 |
5
SilentDepth 2020-07-06 21:20:37 +08:00
因为两个 queue 比全部打散一起排优先级实现起来更容易
|
 |
6
JayLin1011 2020-07-06 21:24:48 +08:00
@ailuoliai 存在即合理。还有，所谓同步任务也是宏任务哦。
|
 |
7
xinleibird 250 天前
1. 同步任务和异步任务是周期性切换的：同步 -> 异步 -> 同步 -> 异步……
2. 对于同步结构：代码在执行时，可执行的部分被压入执行栈，子部分被继续分解压入，继续压入执行栈。分解完毕后，由栈顶逐一弹出，最后统一执行。这个部分在所有语言中的模型是一致的。 3. 加入异步任务之后，就面临一个问题，在什么时机将异步任务中的同步部分插入到同步任务中？ JavaScript 采用的思路是以「是否由事件驱动」来做区分： 3.1 「微任务队列」：对于 Promise 相关的异步任务，JavaScript 不认为它是由事件驱动的。因此这些任务即使在同一个轮询周期内都回调了，它也认为是应该同一个周期进行响应的。表现就是只要在这个周期内响应的 Promise 的回调，它就按照顺序都按一般规则压入执行栈。 3.2 「宏任务队列」：对于由事件驱动的异步任务，例如各种 UI 响应（点击啦，焦点啦之类的）、或者 UI 渲染、或者单纯的脚本加载之类的，JavaScript 认为它们应该在一个轮询周期内只触发一个。（例如说，鼠标点击一个元素，它大概率会触发重绘或者重排，重绘重排同时是 UI 渲染，如果这个「宏任务队列」积压的任务过多，一次执行，则会有 UI 渲染错误的风险。这里仅是举例）将这个宏任务的回调压入执行栈。 4. 这时候我们可以从「执行栈」和「两个异步队列」来看这个循环： （首先由 <script> 标签引入代码的过程是个宏任务，我们略过不提。仅此一次而已） 4.1 脚本的中的代码顺序执行，同步代码则依次压入执行栈，异步回调代码按照分类分别放入「微任务队列」和「宏任务队列」。 4.2 执行的焦点一直在执行栈之间切换。 4.2.1 焦点在执行栈中时，则弹栈执行清空。 4.2.2 焦点在异步队列时，则首先查看「微任务队列」，此时已响应的「微任务」会按队列顺序依次压入执行栈。然后会查看「宏任务队列」，将队列中排位靠前的一个「宏任务」压入执行栈。 4.2.3 焦点再转回执行栈，然后再转回异步队列，由此循环。 题外话，你把视角代入到「执行栈」就容易想清楚了。（静态的执行栈如何管理异步代码？） |
|
8
xinleibird 250 天前
改一下：
题外话，你把视角代入到「执行栈」就容易想清楚了。（同步的执行栈如何管理异步代码？） |
Select Language