共计 1553 个字符，预计需要花费 4 分钟才能阅读完成。
大家好，我卡颂。
在中文社区，这么多年始终流传一个说法：
JS线程负责执行 JS，GUI 渲染线程负责渲染，这两者是互斥的，所以 JS 执行时会阻塞渲染。
但随着 Dev Tools 应用的增多，逐步开始狐疑以上说法。本文会以理论案例来解释为什么 JS 阻塞渲染。
欢送退出人类高质量前端框架群，带飞
到底几个线程
在解说 JS 线程与 GUI 线程互斥的文章中，通常会列出渲染过程蕴含的线程，比方：
GUI渲染线程JS引擎线程- 事件触发线程
- 定时触发器线程
HTTP申请线程
等
然而，咱们以百度的搜寻页举例，关上 Performance 面板开启录制：
上图录制后果中：
Chrome_ChildIOThread对应IO线程的工作记录，用户输出、网络、设施相干事件都与他相干Raster记录光栅化线程池工作、GPU记录GPU合成位图的工作、Compositor记录合成线程的工作执行，以上三者都与浏览器渲染相干Main记录渲染过程的主线程中的工作
从这个角度看，浏览器理论的线程状况与那些 GUI 线程相干的文章形容的并不相同。
主线程的工作
接下来，让咱们进入Main。红线框内长短不一的灰色块，就是主线程中执行的工作。
留神看红框内的绿色块FP，代表First Paint（首次绘制）：
那么在首次绘制前都要执行什么工作呢？能够看到次要有 3 个Task（工作）：
第一个工作是申请 HTML 数据：
Parse HTML
当申请回 HTML 字节流后，开始第二个工作，将 HTML 字节流解析为DOM，这个工作的名字就是图中的蓝色块Parse HTML：
留神其中有些执行时长不一的 Evaluate Script，这些是解析DOM 树过程中遇到的 JS 代码。
从 DOM 树中能够看到这些阻塞 DOM 树生成的 JS 脚本：
他们的存在显著拉长了 Parse HTML 的用时。
Recaculate Style
解析完 DOM 树（蓝色Parse HTML）后，下一个工作是紫色Recaculate Style：
他负责将 HTML 中的 CSS 款式（外联、内联）输入为 styleSheets，styleSheets 有两个作用：
- 能够与
DOM树联合为页面带来款式 JS能够操作styleSheets扭转页面款式
咱们能够从控制台打印 document.styleSheets 直观感触他的存在：
Layout
有了 DOM 树与 styleSheets，接下来须要为视图中可见局部生成一棵树（比方display: none 局部就不须要在这棵树中显示）。
这个工作是紫色Layout：
Update Layer Tree
用户看到的页面理论是由多层页面重叠后的后果，开发者能够用很多伎俩（比方z-index）扭转某局部的层级。
比方滚动条就会造成本人独立的层级：
既然是多层构造，那么就须要更新每层的信息，这个工作是紫色的Update Layer Tree：
Paint
咱们能够发现，在 FP 之前，Update Layer Tree之后只剩下 Paint 这一工作了：
从字面意义讲，这就是 绘制 么？并不是。
Paint的工作是整顿每一层页面的绘制信息，形成绘制列表，这些数据会交给合成线程负责后续绘制操作。
能够发现，具体的绘制操作是交由合成线程实现，他与 JS 所在线程（主线程）并不是互斥的。
JS 为啥阻塞渲染
咱们当初晓得，JS执行与 Paint 工作都产生在主线程。
渲染被阻塞 的起因很显著：因为 Paint 工作没有及时执行，即绘制列表没有及时提交给合成线程。
之所以没有及时执行，可能是因为 JS 执行工夫过长，导致这一帧没有工夫执行Paint。
比方，咱们关上 B 站，记录下主线程的工作。
能够看到，有个 JS 执行时长达到 231.88ms，超过了一帧的工夫，在此期间主线程就没工夫执行 Paint 了：
总结
JS之所以阻塞渲染，是因为 JS 执行与 渲染相干工作 都在抢夺主线程无限的资源。
当 JS 执行工夫过长，渲染相干工作 就没工夫执行了。
