番外事件循环

本节来自渡一教育大师课课程课件，仅基于个人学习基础上增加部分补充。WEB前端大师课

浏览器的进程模型

何为进程？

程序运行需要有它自己专属的内存空间，可以把这块内存空间简单的理解为进程

每个应用至少有一个进程，进程之间相互独立，即使要通信，也需要双方同意。

何为线程？

有了进程后，就可以运行程序的代码了。

运行代码的「人」称之为「线程」。

一个进程至少有一个线程，所以在进程开启后会自动创建一个线程来运行代码，该线程称之为主线程。

如果程序需要同时执行多块代码，主线程就会启动更多的线程来执行代码，所以一个进程中可以包含多个线程。

浏览器有哪些进程和线程？

浏览器是一个多进程多线程的应用程序

浏览器内部工作极其复杂。

为了避免相互影响，为了减少连环崩溃的几率，当启动浏览器后，它会自动启动多个进程。

可以在浏览器的任务管理器中查看当前的所有进程

其中，最主要的进程有：

浏览器进程
主要负责界面显示、用户交互、子进程管理等。浏览器进程内部会启动多个线程处理不同的任务。
网络进程
负责加载网络资源。网络进程内部会启动多个线程来处理不同的网络任务。
渲染进程（本节课重点讲解的进程）
渲染进程启动后，会开启一个渲染主线程，主线程负责执行 HTML、CSS、JS 代码（这些若干任务必须只能由渲染主线程这一个进程执行，是无法分工的）。
默认情况下，浏览器会为每个标签页开启一个新的渲染进程，以保证不同的标签页之间不相互影响。
个人补充：js运行时（事件循环 + 调用栈 + 任务队列）也是标签页级别的，一个标签页一个独立运行时。这意味着js的世界最高也就直到标签页级别了，window.top指向标签页也是同样的道理。
js不存在跨标签页的概念标签栏、地址栏这些属于浏览器进程的 UI，对任何标签页的js来说都不存在。
Chromium 的默认策略是一个标签页对应一个渲染进程对应一个js运行时，也就对应着一个事件循环，但不是严格如此：
不同源的 iframe 必须跑在不同渲染进程里，防止跨域攻击。所以一个标签页里可以存在多个渲染进程；
同源 iframe 和父页面共享同一个渲染进程，甚至共享同一个事件循环。所以同源 iframe 里死循环会卡死父页面；
Chrome 内存紧张时，会把同站点的标签页合并到一个渲染进程里，此时两个标签页共享一个渲染进程，但各自仍有独立的事件循环（互相不会卡死）。
因此更精准的说法是：渲染进程 : JS 运行时 = 1 : N（一个进程可包含多个运行时），而标签页 : 渲染进程 = N : M。
唯一能确定的只有一个 JS 运行时一定跑在一个渲染进程里，至于这个进程里还挤了多少别的运行时，开发者控制不了也不需要关心。
将来该默认模式可能会有所改变，有兴趣的同学可参见chrome官方说明文档

渲染主线程是如何工作的？

渲染主线程是浏览器中最繁忙的线程，需要它处理的任务包括但不限于：

解析 HTML
解析 CSS
计算样式
布局
处理图层
每秒把页面画 60 次
执行全局 JS 代码
执行事件处理函数
执行计时器的回调函数
……

思考题：为什么渲染进程不适用多个线程来处理这些事情？

要处理这么多的任务，主线程遇到了一个前所未有的难题：如何调度任务？

比如：

我正在执行一个 JS 函数，执行到一半的时候用户点击了按钮，我该立即去执行点击事件的处理函数吗？
我正在执行一个 JS 函数，执行到一半的时候某个计时器到达了时间，我该立即去执行它的回调吗？
浏览器进程通知我“用户点击了按钮”，与此同时，某个计时器也到达了时间，我应该处理哪一个呢？
……

渲染主线程想出了一个绝妙的主意来处理这个问题：排队

在最开始的时候，渲染主线程会进入一个无限循环
每一次循环会检查消息队列中是否有任务存在。如果有，就取出第一个任务执行，执行完一个后进入下一次循环；如果没有，则进入休眠状态。
其他所有线程（包括其他进程的线程）可以随时向消息队列添加任务。新任务会加到消息队列的末尾。在添加新任务时，如果主线程是休眠状态，则会将其唤醒以继续循环拿取任务

这样一来，就可以让每个任务有条不紊的、持续的进行下去了。

整个过程，被称之为事件循环（消息循环）

个人补充：JS 引擎本身绝对单线程，不模拟多线程。所感觉到的多线程，是浏览器把不同模块交给不同线程完成，完成后通过事件循环把结果还给 JS 主线程。
此外，任务在消息队列中是包装为结构体的，也可以认为是对象，抽象地来说可以称之为任务。

若干解释

何为异步？

代码在执行过程中，会遇到一些无法立即处理的任务，比如：

计时完成后需要执行的任务 —— setTimeout、setInterval
网络通信完成后需要执行的任务 – XHR、Fetch
用户操作后需要执行的任务 – addEventListener

如果让渲染主线程等待这些任务的时机达到，就会导致主线程长期处于「阻塞」的状态，从而导致浏览器「卡死」

渲染主线程承担着极其重要的工作，无论如何都不能阻塞！

因此，浏览器选择异步来解决这个问题

使用异步的方式，渲染主线程永不阻塞

面试题：如何理解 JS 的异步？
参考答案：
JS是一门单线程的语言，这是因为它运行在浏览器的渲染主线程中，而渲染主线程只有一个。
而渲染主线程承担着诸多的工作，渲染页面、执行 JS 都在其中运行。
如果使用同步的方式，就极有可能导致主线程产生阻塞，从而导致消息队列中的很多其他任务无法得到执行。这样一来，一方面会导致繁忙的主线程白白的消耗时间，另一方面导致页面无法及时更新，给用户造成卡死现象。
所以浏览器采用异步的方式来避免。具体做法是当某些任务发生时，比如计时器、网络、事件监听，主线程将任务交给其他线程去处理，自身立即结束任务的执行，转而执行后续代码。当其他线程完成时，将事先传递的回调函数包装成任务，加入到消息队列的末尾排队，等待主线程调度执行。
在这种异步模式下，浏览器永不阻塞，从而最大限度的保证了单线程的流畅运行。

JS为何会阻碍渲染？

先看代码

  
<h1>Mr.Yuan is awesome!</h1>
<button>change</button>
<script>
  var h1 = document.querySelector('h1');
  var btn = document.querySelector('button');

  // 死循环指定的时间
  function delay(duration) {
    var start = Date.now();
    while (Date.now() - start < duration) {}
  }

  btn.onclick = function () {
    h1.textContent = '袁老师很帅！';
    delay(3000);
  };
</script>

点击按钮后，会发生什么呢？

任务有优先级吗？

任务没有优先级，在消息队列中先进先出

但消息队列是有优先级的

根据 W3C 的最新解释:

每个任务都有一个任务类型，同一个类型的任务必须在一个队列，不同类型的任务可以分属于不同的队列。在一次事件循环中，浏览器可以根据实际情况从不同的队列中取出任务执行。
浏览器必须准备好一个微队列，微队列中的任务优先所有其他任务执行 https://html.spec.whatwg.org/multipage/webappapis.html#perform-a-microtask-checkpoint

随着浏览器的复杂度急剧提升，W3C 不再使用宏队列的说法

在目前 chrome 的实现中，至少包含了下面的队列：

延时队列：用于存放计时器到达后的回调任务，优先级「中」
交互队列：用于存放用户操作后产生的事件处理任务，优先级「高」
微队列：用户存放需要最快执行的任务，优先级「最高」

添加任务到微队列的主要方式主要是使用 Promise、MutationObserver
例如：
1 2 3 // 立即把一个函数添加到微队列 Promise.resolve().then(函数) // （个人补充）如果采用async/await方案，await同样会将它后面的代码推入微任务队列

微任务的”最高优先级”需要限定在单轮事件循环内部理解。其准确含义是：当前宏任务执行完毕后，微任务队列中的全部任务优先于下一宏任务被调度。这一优先权不跨轮次。
以 fetch 请求为例说明这一边界。同步阶段调用 fetch() 后，网络线程启动，.then 回调注册在 promise 内部槽位但不排队。此后事件循环正常运转，可能经历若干轮宏任务的调度与微任务阶段的空转，回调始终未进入微任务队列。直到网络响应抵达，浏览器内部生成一个 fetch 宏任务推入队列，该宏任务被取出执行并调用 resolve()，此时 .then 回调才排入微任务队列，在同一轮的清理阶段执行。从 fetch 的同步调用到回调触发这一时间段内，已有若干轮宏任务先行完成。
因此，”微任务优先级最高”描述的是每一轮事件循环内部的调度顺序，而非回调在时间线上的绝对提前。微任务在所属轮次的清理阶段优先于下一宏任务，但不具备跨越轮次的优先能力。

浏览器还有很多其他的队列，由于和我们开发关系不大，不作考虑

同步执行栈

渲染主线程承担的所有工作都以任务为单位被调度。但事件循环从队列取出任务后，任务本身并不是在事件循环的 while 体内直接执行完的——中间还存在一个关键的中间结构：同步执行栈（call stack）。

同步执行栈是渲染主线程上的一个后进先出数据结构，每当一个函数被调用，其执行上下文被压入栈顶；函数返回时，上下文从栈顶弹出。事件循环从队列取一个任务、将其推入执行栈——此时栈为空，该任务成为栈底也是栈顶的唯一帧——然后开始出栈/压栈的函数调用链条，直到栈再次清空，这一轮宏任务才算执行完毕。

一轮事件循环的完整路径：

  事件循环取一个宏任务
       │
       ▼
  推入同步执行栈（call stack）
       │
       ▼
  栈内函数层层压入/弹出，直到栈清空
       │
       ▼
  排空所有微任务
       │
       ▼
  可能渲染一次

一个典型的场景可说明此流程的实际运作：浏览器首次解析 <script> 标签时，整段脚本被作为一个宏任务推入队列。事件循环第一轮取出它、推入 call stack，从第一行执行到最后一行，然后排空微任务，视情况渲染一次。此即整个 JavaScript 程序的第一轮事件循环，整段脚本代码本质上就是一个宏任务。后续的 setTimeout 回调、事件监听器等，则排队在各自独立的宏任务中，等待事件循环的后续轮次逐一取出执行。

之所以强调同步执行栈独立于事件循环循环体，是因为两个关键推论：

同步代码阻塞的本质是执行栈长时间不被清空——while (true) 让栈永远弹不出来，事件循环的 while 即使活着也无法取下一个任务
异步回调的调度逻辑是”等执行栈清空后再从队列取下一个”——不是插入正在执行的代码中间

执行栈是栈而非队列，这决定了同步代码的执行语义：函数调用的嵌套关系由压栈顺序决定，内层函数总是先于外层函数返回。同一次宏任务内的所有同步操作都在同一个执行栈生命周期内完成。

C++ 层是真实循环

事件循环是浏览器引擎（如 V8/libuv）用 C++ 跑的一个无限循环：

  
// 伪代码：这就是事件循环的真身
while (tab_is_alive) {
    // 1. 从优先级最高的非空宏任务队列取一个任务
    //    交互队列（高）> 延时队列（中）> 其他队列
    task = select_next_task();  // 各队列内部按 FIFO 出队
    if (task) {
        // 2. 推入同步执行栈，开始执行
        //    call stack: [task]
        //    task 内每调用一个函数，压入一层帧
        //    函数返回时弹出，直到 call stack 再次为空
        execute(task);  // 栈清空后返回这里
    }

    // 3. 排空所有微任务（每个微任务同样走 取任务→推入栈→清空 的路径）
    while (micro_task_queue.has_pending()) {
        micro = micro_task_queue.dequeue();
        execute(micro);
    }

    // 4. 需要的话触发渲染
    if (should_render) render();

    // 5. 回到步骤 1 —— 这就是"循环"
}

一次迭代只处理一个宏任务，不是清空整个队列。多个宏任务队列之间的优先级通过 select_next_task() 体现：每次循环时从当前优先级最高的非空队列中取出一个任务推入执行栈，各队列内部保持 FIFO 顺序。

这是 C++ 线程里真实在跑的 `while`，只要标签页没关，它就一直在。

### 网络请求与回调排队：以 `fetch` 为例

上述异步流程在 `fetch` 网络请求中表现最为完整，可展开为如下时间轴：

T0 同步阶段： fetch(‘/data’).then(res => res.json()).then(data => console.log(data)) │ ├── fetch() 调用 → 浏览器启动网络线程（异步，不阻塞主线程） │ ├── .then(res => res.json()) 注册回调，挂在 promise 内部 [[PromiseFulfillReactions]] 槽位 │ 回调未排队，等待 resolve 触发 │ ├── .then(data => console.log(data)) 同理注册 │ └── 同步代码继续执行，本轮宏任务结束

T1 ~ TN 若干轮事件循环： [宏任务 A] → [微任务清空（空）] → [可能渲染] [宏任务 B] → [微任务清空（空）] → [可能渲染] …（网络线程仍在工作中，JS 主线程不感知）

TN+1 网络响应抵达：网络线程收到 HTTP 响应 → 往宏任务队列插入一个 fetch task（规范内部任务，非 .then 回调） → 等待事件循环取出

TN+2 事件循环取出 fetch task： [宏任务：fetch task] → 处理响应头、状态码 → resolve(promise) ← 在主线程上同步调用 → .then(res => res.json()) 排队进微任务队列 → fetch task 结束 [微任务清空] → .then(res => res.json()) 执行，返回 promise A → promise A resolve → .then(data => …) 排队 → .then(data => console.log(data)) 执行 ← 数据在此可用 [可能渲染]

关键点：网络线程不可直接操作 promise 或微任务队列，二者均位于 JS 主线程。网络线程的唯一行为是往宏任务队列插入一个通知任务（fetch task），该任务在未来的某一轮被取出执行，在 JS 主线程上同步调用 `resolve()`，此时 `.then` 回调才排入微任务队列并在同一轮清空。从 `fetch` 的同步调用到 `.then` 回调执行之间，可能间隔若干轮完好的事件循环。微任务的"最高优先级"仅作用于回调被排入的那一轮内部（在该轮中微任务先于下一宏任务执行），而不具备跨轮次的优先能力。

### 一轮事件循环的含义

面试常说的一轮（one tick），指的就是 C++ 循环的一次迭代：

一轮事件循环 = 取 1 个宏任务执行 → 排空所有微任务 → 可能渲染一次 ├── 执行 rAF 回调队列 ├── layout（如果需要） └── paint

宏任务（每个占一轮）: setTimeout 回调、用户点击、I/O 回调、MessageChannel

微任务（不占轮次，当前轮里清干净）: Promise.then、queueMicrotask、MutationObserver

这就是为什么 `setTimeout(fn, 0)` 里的 fn 不是立刻执行，它必须排在下一轮，当前这轮还在跑。

事件循环既是真实循环（C++ 的 while），也是轮次概念（一轮 = 1 宏任务 + 排空微任务）。

为什么我们会说微任务的优先级高，因为在宏任务调用了下一轮宏任务，在下一轮宏任务启动前，微任务会先完成，虽然微任务是处在两个宏任务之间的，但是也在上一个宏任务的轮次里，表现起来就是微任务的优先级要高于下一轮宏任务。

### requestAnimationFrame 的位置

`requestAnimationFrame`（rAF）既不是宏任务，也不是微任务——它在渲染阶段执行，有自己的独立管道。

宏任务执行 → 微任务排空 → 渲染（rAF → layout → paint）→ 下一轮宏任务

rAF 的注册和执行是分离的：在宏任务里调用 `requestAnimationFrame(fn)`，`fn` 被注册到 rAF 回调队列，但当前轮不会执行。等到微任务清空后，如果浏览器决定本轮需要渲染，就在 layout 之前按注册顺序执行 rAF 队列中的所有回调。

> rAF 的设计初衷是为动画提供与屏幕刷新率同步的执行时机——屏幕 60Hz 时，rAF 约每 16.6ms 执行一次。它在 layout 之前、paint 之前执行，天然适合在回调里修改 DOM 后立即让浏览器在一次渲染中消化掉，避免掉帧。

rAF 有几个独特性质：

- **注册同步，执行异步**：`requestAnimationFrame(fn)` 只是把 `fn` 放入队列，不立即执行
- **执行时机由浏览器决定**：浏览器可能跳过渲染（比如标签页后台时），rAF 也就不执行
- **每帧清空一次**：一轮渲染里，rAF 队列全部排空后才进入 layout
- **回调里再次注册 rAF 会进入下一帧**：这是动画循环的标准写法

```js
// 标准动画循环
function animate() {
  element.style.transform = `translateX(${x++}px)`;  // 改 DOM
  requestAnimationFrame(animate);  // 注册下一帧
}
requestAnimationFrame(animate);  // 首帧注册

对比 setTimeout 做动画：setTimeout 不管屏幕刷新率，可能在两次渲染之间执行多次（浪费）或不执行（掉帧）。rAF 由浏览器保证每帧执行一次，是动画的最高效调度方式。

事件派发与微任务检查点

同一个按钮上绑了两个监听器，输出顺序会因为触发方式不同而改变：

  
button.addEventListener('click', () => {
  Promise.resolve().then(() => console.log('m1'));
  console.log('l1');
});
button.addEventListener('click', () => {
  Promise.resolve().then(() => console.log('m2'));
  console.log('l2');
});

用户点击（trusted event）：l1 → m1 → l2 → m2

宏任务：click 事件派发
  │
  ├── listener1 → log "l1" → m1 进微任务队列
  ├── ★ 微任务检查点（trusted event 规范要求）→ m1 执行 → log "m1"
  ├── listener2 → log "l2" → m2 进微任务队列
  └── ★ 微任务检查点 → m2 执行 → log "m2"

JS 触发（untrusted / button.click()）：l1 → l2 → m1 → m2

宏任务：click() 同步执行
  │
  ├── listener1 → log "l1" → m1 进微任务队列
  ├── listener2 → log "l2" → m2 进微任务队列
  │
  ▼ 宏任务结束
  ▼
微任务清空：m1 → m2 → log "m1" → log "m2"

这是 HTML 规范中的一条细则：事件派发时，每调完一个监听器后、调用下一个之前，如果事件是 trusted（用户真实操作触发的），浏览器必须执行一次微任务检查点（microtask checkpoint）。button.click() 派发的是 untrusted 事件，规范不要求中间插微任务检查点，所有监听器一口气跑完，微任务留到最后清空。
设计意图：浏览器希望每个监听器执行时看到的 DOM 环境是干净的。listener1 改了 DOM、产生了微任务（比如 Vue 的 nextTick），在 listener2 执行前把微任务清掉，确保 listener2 不会看到脏状态。手动 click() 不需要这种隔离——开发者既然手动调，就自己承担所有监听器的副作用。
更进一步，从 JS 调用栈的角度也能解释这个差异：
用户点击——浏览器从 C++ 层逐个调用监听器。listener1 执行完毕、出栈后，JS 调用栈为空（事件派发循环在 C++ 侧，不在 JS 栈上），因此微任务检查点可以立即执行，把 m1 清掉。之后 C++ 层再取 listener2 入栈执行，完成后 JS 栈又空，执行 m2。
JS 触发——button.click() 本身是一个 JS 函数调用，它在调用栈上。listener1 执行完出栈，但 click() 还在栈里（以及可能调用 click() 的外层函数），JS 调用栈没有清空。这种情况下微任务必须等整个调用栈清空后才能执行，所以 m1 和 m2 都要等到 click() 返回、宏任务结束后才被排空。
也就是说，两种场景的差异不仅来自规范中的微任务检查点要求，也来自 JS 栈是否已清空这一底层约束。trusted event 的派发循环跑在 C++ 侧，每调完一个监听器 JS 栈就空了，微任务自然可以运行；untrusted event 的 dispatchEvent / click() 跑在 JS 侧，监听器只是嵌套在调用栈里的子调用，栈不空微任务就不能跑。

面试题：阐述一下 JS 的事件循环
参考答案：
事件循环又叫做消息循环，是浏览器渲染主线程的工作方式。
在 Chrome 的源码中，它开启一个不会结束的 for 循环，每次循环从消息队列中取出第一个任务执行，而其他线程只需要在合适的时候将任务加入到队列末尾即可。
过去把消息队列简单分为宏队列和微队列，这种说法目前已无法满足复杂的浏览器环境，取而代之的是一种更加灵活多变的处理方式。
根据 W3C 官方的解释，每个任务有不同的类型，同类型的任务必须在同一个队列，不同的任务可以属于不同的队列。不同任务队列有不同的优先级，在一次事件循环中，由浏览器自行决定取哪一个队列的任务。但浏览器必须有一个微队列，微队列的任务一定具有最高的优先级，必须优先调度执行。

面试题：JS 中的计时器能做到精确计时吗？为什么？
参考答案：
不行，因为：
计算机硬件没有原子钟，无法做到精确计时
操作系统的计时函数本身就有少量偏差，由于 JS 的计时器最终调用的是操作系统的函数，也就携带了这些偏差
按照 W3C 的标准，浏览器实现计时器时，如果嵌套层级超过 5 层，则会带有 4 毫秒的最少时间，这样在计时时间少于 4 毫秒时又带来了偏差
受事件循环的影响，计时器的回调函数只能在主线程空闲时运行，因此又带来了偏差

番外 事件循环