登录从浏览器进程层面理解事件循环
现代浏览器的进程架构
进程之间是独立存在的，因此为了防止浏览器 tab 连续崩坏的情况，如今已经演变成了多进程架构，每个进程都会有个独立的内存空间
一般就是下面这六个进程：
- 浏览器主进程（Browser Process）
- 负责管理浏览器的界面显示（比如导航栏）、用户交互、子进程管理
- 处理书签、历史记录、下载等功能
- 协调其他进程
- 渲染进程（Renderer Process）
- 负责网页内容的渲染
- 每个标签页通常会有自己的渲染进程（沙箱隔离）
- 包含多个线程：
- 主线程：处理JavaScript执行、DOM解析、CSS计算等
- 合成线程：处理图层合成
- 工作线程：处理Web Workers
- 光栅化线程：将图形转换为位图
- GPU进程（GPU Process）
- 处理GPU任务，加速图形渲染
- 负责将渲染进程的输出合成并显示到屏幕上
- 网络进程（Network Process）
- 处理网络请求
- 实现HTTP/HTTPS协议
- 管理缓存
- 插件进程（Plugin Process）
- 运行浏览器插件（如Flash）
- 每个插件通常有自己的进程
- 实用程序进程（Utility Process）
- 处理一些辅助功能，如音频服务、打印等
在 windows 下，我们可以通过快捷键
Ctrl + Shift + Esc 来打开 windows 的实时进程，其实浏览器也有对应的界面，我们可以通过 Shift + Esc 来打开浏览器的实时进程
比如我这里开了两个 tab，首先每个 tab 都会存在一个独立的进程，这个进程就是我们说的渲染进程，图中可以看到 第一个 Chrome 图标的那个就是浏览器的主进程，第二个为 GPU 进程，第三个为 网络进程，第四个为 实用程序进程，然后后面几个 service worker 其实就是后台的特殊进程
其实早在 2018年，Chrome 就已经更新了一个名为 站点隔离（Site Isolation）的机制，这意味着不再是简单地一个标签页一个进程，而是按照网站的源（协议 + 域名 + 端口）来分配进程，这么做对于很多用户来讲应该可以很大程度减少 Chrome 内存占用，像是开发过程中你可能 csdn 会有很多 tab 同时存在，不过Chrome 会够根据用户的硬件设备调整不同的进程架构，像是站点隔离在内存受限的设备上就不会生效
实用程序进程这里可以看到是个 storage service ，这就是他处理存储的功能，当我们看 B站 视频时，就会存在一个 audio service，就说明在发挥它的 音频 功能
六个进程中我们了解大概就差不多了，但是渲染进程我们需要单独聊聊，这对前端仔来讲还是非常重要的
因为我们的前端代码均是在这个进程程执行的
渲染进程
渲染进程负责将 HTML，CSS 和 JS 转换为用户可以看到的网页内容和交互
渲染进程核心的职责就是我们熟知的下面五个步骤：
- 解析HTML和CSS：将HTML转换为DOM树，将CSS转换为CSSOM树
- 执行JavaScript：运行页面中的JavaScript代码
- 布局计算：确定每个元素在屏幕上的确切位置和大小
- 绘制：将元素绘制到内存中的位图
- 合成：将不同的绘制层合成为最终显示的图像
若将渲染进程进行线程拆分，那么它主要是靠三个线程：主线程、合成线程和光栅线程
还有 工作线程（Web Workers），定时器线程，事件触发线程
我们的前端代码其实就是在 渲染进程中的 主线程 执行的，接下来我们引入事件循环来结合讲解
渲染主线程
渲染主线程负责渲染进程的大部分工作，所以它需要处理许多任务，执行 js 是它，绘制页面又是它，可能发生性能瓶颈，说 js 代码阻塞其实就是因为渲染主线程只有一个，无法同时处理两份属于自己的工作，渲染主线程的主要工作如下：
- 执行 JS 代码
- 处理 DOM 操作
- 处理用户事件（如 Click）
- 处理计时器回调
- 处理网络请求回调
- 执行微任务和宏任务
这个时候其实你可能会很好奇为何渲染主线程要做的东西这么多，也确实容易出现问题，那他为何不分配一些新的线程来做呢，比如专门给一个 js 线程来执行 js 代码，专门一个 dom 线程来处理 dom 操作
其实这个问题会有很多原因，其中我们最容易理解的就是因为 js 可以操作 dom，多个线程同时修改 dom 会导致难以预测的竞态条件；还有就是历史原因，js 最初就是个单线程语言，web 本身就非常向后兼容，改变这个线程模型就会破坏现有网站；再一个就是实际上浏览器已经采取了多线程优化方案，比如 WebWorker 新开了一个线程执行 js，但是这些 js 又不能直接访问 dom
事件循环（event-loop / message-loop）我们已经很熟悉了，但是想要真正理解透彻我们应该将 UI 渲染这一步骤结合进来
事件循环出来的目的也就是因为 js 执行变得复杂，此前单线程的原因并没有考虑这个问题，后来才逐步引入的机制，比如一个 for 循环很多次，执行的过程中某个定时器的回调也到了时间应该如何调度呢，如何调度其实就是事件循环，通俗理解这个东西就是让任务之间进行排队
事件循环在主线程上的工作流程如下：
- 执行当前的 JS 调用栈中的所有同步代码
- 检查微任务队列（microtask queue），执行所有微任务直到队列清空
- 执行一个宏任务（macrotask）
- 再次检查微任务队列，执行所有微任务
- 如果需要，执行UI渲染
- 返回步骤3，继续循环
我们再来复习下常见的宏微任务有哪些：
微任务
- Promise回调（.then/.catch/.finally）
- MutationObserver回调
- queueMicrotask() API
- 处理优先级较高，在每个宏任务之后立即执行
宏任务
- Script 标签
- setTimeout/setInterval回调
- 用户交互事件（点击、键盘输入等）
- 网络请求回调（XHR, fetch）
- MessageChannel
- requestAnimationFrame
- I/O操作
也许有人会争 宏任务比 同步先执行，这么说也是对的，因为本身 Script 就是个宏任务
执行 js 代码过程中，不一定会是当前执行代码所引入的 回调 进入消息队列，也有可能来自浏览器进程监听的用户交互，比如 click 事件，浏览器进程虽然不会执行 js 代码，js 执行是在渲染进程的渲染主线程中，浏览器进程可以监听事件然后放入消息队列，js 再从消息队列拿回调来执行
所以我们现在可以明白浏览器如何处理这些事件的，我们可以临时往消息队列中塞任务，但是执行就不一定是立即执行，因为他需要先等当前的调用栈执行完毕后，再依次检查消息队列中前面的事件是否执行完毕再去执行这个临时加的任务
event-loop 就是为了解决 js 单线程问题，异步的目的就是为了不让页面卡死，因为渲染这个关键步骤也是在 event-loop 之中或者说由渲染主线程负责
消息队列的优先级
消息队列可以理解为任务队列，我们在面试时常常会说宏任务队列，微任务队列，但是大家也清楚，其实宏任务这个概念官方已经抛弃了，此前宏任务就是 macrotask，现在官方换成了 task ，就是一个 任务，微任务依旧为 microtask
我也不清楚为何要换个名字，其实 task 和 macrotask 没有本质区别，因此我们完全可以沿用这个宏任务概念
对于 js 而言，任务是没有优先级的，它只管从 消息队列 依次去获取任务执行，这个任务就是回调，其实每个任务都会被浏览器包装成一个对象或者说是一个块
但是消息队列是具有优先级的，task queue 其实就是宏任务队列，因为浏览器的复杂程度越来越高，宏任务队列其实会被划分成不同的队列，有可能定时器会专门有一个定时器的队列，然后事件回调会有一个事件回调的队列，ui 渲染会专门有一个 渲染队列，这些队列具有优先级，另外，每种任务其实会专门放到对应的任务队列中，但是其实也可以放到其他不同的任务队列，比如监听事件的回调可以放到定时器队列，但是这样做后，它就不能放到其余的队列中了
这是 w3c 给出的规定，同一个类型必须在同一个队列，也可以分属不同的队列
宏任务细分下去的任务队列优先级其实不需要我们关注，我们只需要清楚微任务队列的优先级永远是最高的
不过对于宏任务队列而言，一般用户交互的事件队列是最高级的，比如点击，键盘，鼠标，其次再是 ui 渲染，这个也很好理解，为用户体验着想，总不可能用户点击后这个任务还有延迟执行吧，后面的优先级详细内容请看下面图示
有个地方需要特别留意，微任务优先级最高，这就意味着 高于 了 ui 渲染这个队列
另外，这里也可以看到定时器哪怕在宏任务队列中都是优先级较低的存在，就算不管微任务队列这个最高优先级，他的执行都是靠后的，因此他的计时肯定是不准的，因为他的回调需要等待前面的任务执行完毕才能继续执行，另外在 w3c 中有个 规定，定时器嵌套（nesting）层级超过了 5 层，后面的定时器就会增加 4 ms 的误差，其实浏览器的定时器实现本身就是调用的操作系统，操作系统本身的计时也是存在误差的，这点无法避免，真正准时的永远是原子钟
最后
总结下本文主要内容
浏览器有很多进程，但是对于前端仔来讲主要关注渲染进程，这个进程其实主要发挥作用的又是渲染主线程，由于前端代码都是在这个进程运行的，因此可以说 js 是个单线程语言，渲染其实也是个 task queue 类型，他的优先级还是比较高的，因此在一轮 event-loop 结束后，就是 ui 渲染线程开始执行
