通过这篇文章，能够让你重新认识浏览器，并把JavaScript，网络，页面渲染，浏览器安全等知识串联起来，从而让你对整个前端体系有全新的认识。
这篇文章是上篇文章的追加从输入URL到页面展示，这中间发生了啥

渲染流程

渲染引擎

  • 渲染引擎：它是浏览器最核心的部分是 “Rendering Engine”，不过我们一般习惯将之称为 “浏览器内核”；
  • 渲染引擎主要包括的线程：GUI渲染线程、JavaScript引擎线程、事件触发线程、定时器触发线程、HTTP异步请求线程；如下图
  • GUI渲染线程：GUI 渲染线程负责渲染浏览器界面，解析 HTML，CSS，构建 DOM 树和 RenderObject 树，布局和绘制等。当界面需要重绘（Repaint）或由于某种操作引发回流（Reflow）时，该线程就会执行。
  • JavaScript引擎线程: JavaScript 引擎线程主要负责解析 JavaScript 脚本并运行相关代码。 JavaScript 引擎在一个Tab页（Renderer 进程）中无论什么时候都只有一个 JavaScript 线程在运行 JavaScript 程序。需要提起一点就是，GUI线程与JavaScript引擎线程是互斥的，这也是就是为什么JavaScript操作时间过长，会造成页面渲染不连贯，导致页面出现阻塞的原理。
  • 事件触发线程：当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JavaScript 引擎的处理。 通常JavaScript引擎是单线程的，所以这些事件都会排队等待JS执行。
  • 定时器触发器：我们日常使用的setInterval 和 setTimeout 就在该线程中，原因可能就是：由于JS引擎是单线程的，如果处于阻塞线程状态就会影响记时的准确，所以需要通过单独的线程来记时并触发响应的事件这样子更为合理。
  • Http请求线程：在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求，这个线程就Http请求线程，它 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到 JavaScript 引擎的处理队列中等待处理。

    简略的渲染流程

  1. 处理 HTML 并构建 DOM 树。
  2. 处理 CSS 构建 CSSOM 树。
  3. 将 DOM 与 CSSOM 合并成一个渲染树。
  4. 根据渲染树来布局，计算每个节点的位置。
  5. 调用 GPU 绘制，合成图层，显示在屏幕上。
    流程如下图：
    相关说明：
  • 在构建 CSSOM 树时，会阻塞渲染，直至 CSSOM 树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢。
  • 当 HTML 解析到 script 标签时，会暂停构建 DOM，完成后才会从暂停的地方重新开始。也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件。并且 CSS 也会影响 JS 的执行，只有当解析完样式表才会执行 JS，所以也可以认为这种情况下，CSS 也会暂停构建 DOM。
  • Load 和 DOMContentLoaded 区别
    Load 事件触发代表页面中的 DOM，CSS，JS，图片已经全部加载完毕。DOMContentLoaded 事件触发代表初始的 HTML 被完全加载和解析，不需要等待 CSS，JS，图片加载。

    图层

  • 一般来说，可以把普通文档流看成一个图层。特定的属性可以生成一个新的图层。不同的图层渲染互不影响，所以对于某些频繁需要渲染的建议单独生成一个新图层，提高性能。但也不能生成过多的图层，会引起反作用。
  • 通过以下几个常用属性可以生成新图层：
  1. 变换：translate3d、translateZ；
  2. will-change；
  3. video、iframe 标签；
  4. 通过动画实现的 opacity 动画转换；
  5. position: fixed；

    重绘（Repaint）和回流（Reflow）

  • 回流是布局或者几何属性需要改变就称为回流。
    另外一个叫法是重排，回流触发的条件就是:对 DOM 结构的修改引发 DOM 几何尺寸变化的时候,会发生回流过程。
    会发生回流的情况有如下：
  1. 一个 DOM 元素的几何属性变化，常见的几何属性有width、height、padding、margin、left、top、border 等等；
  2. 使 DOM 节点发生增减或者移动；
  3. 读写 offset族、scroll族和client族属性的时候，浏览器为了获取这些值，需要进行回流操作。
  4. 调用 window.getComputedStyle 方法。

回流的过程
依照上面的渲染流水线，触发回流的时候，如果 DOM 结构发生改变，则重新渲染 DOM 树，然后将后面的流程(包括主线程之外的任务)全部走一遍。

  • 重绘是当节点需要更改外观而不会影响布局的，比如改变 color 就叫称为重绘
    当页面中元素样式的改变并不影响它在文档流中的位置时（例如：color、background-color、visibility等），浏览器会将新样式赋予给元素并重新绘制它，这个过程称为重绘。
    根据概念，我们知道由于没有导致 DOM 几何属性的变化，因此元素的位置信息不需要更新，从而省去布局的过程，流程如下：
    跳过了布局树和建图层树,直接去绘制列表，然后在去分块,生成位图等一系列操作。
  • 可以看到，重绘不一定导致回流，但回流一定发生了重绘。回流所需的成本比重绘高的多，改变深层次的节点很可能导致父节点的一系列回流。
  • 很多人不知道的是，重绘和回流其实和Event loop 有关。
  1. Event loop 执行完微任务（Microtasks ）后，会判断 document 是否需要更新。因为浏览器是 60Hz 的刷新率，每(1000/60) = 16ms 才会更新一次。
  2. 然后判断是否有 resize 或者 scroll ，有的话会去触发事件，所以 resize 和 scroll 事件也是至少 16ms 才会触发一次，并且自带节流功能。
  3. 判断是否触发了 media query
  4. 更新动画并且发送事件
  5. 判断是否有全屏操作事件
  6. 执行 requestAnimationFrame 回调
  7. 执行 IntersectionObserver 回调，该方法用于判断元素是否可见，可以用于懒加载上，但是兼容性不好
  8. 更新界面
    以上就是一帧中可能会做的事情。如果在一帧中有空闲时间，就会去执行 requestIdleCallback 回调。

减少重绘和回流

  • 使用 translate 替代 top，在修改定位时，使用translate代替；
  • 使用 visibility 替换 display: none ，因为前者只会引起重绘，后者会引发回流（改变了布局）；
  • 把 DOM 离线后修改，比如：先把 DOM 给 display:none (有一次 Reflow)，然后你修改100次，然后再把它显示出来；
  • 不要把DOM结点的属性值放在一个循环里当成循环里的变量;
    1
    2
    3
    4
    for(let i = 0; i < 1000; i++) {
        // 获取 offsetTop 会导致回流，因为需要去获取正确的值
        console.log(document.querySelector('.test').style.offsetTop)
    }
  • 不要使用 table 布局，可能很小的一个小改动会造成整个 table 的重新布局;
  • 动画实现的速度的选择，动画速度越快，回流次数越多，也可以选择使用 requestAnimationFrame;
  • CSS 选择符从右往左匹配查找，避免 DOM 深度过深;
  • 将频繁运行的动画变为图层，图层能够阻止该节点回流影响别的元素。比如对于 video 标签，浏览器会自动将该节点变为图层。

    详细的渲染流程

    构建DOM树 ==> 样式计算 ==> 布局阶段 ==> 分层 ==> 绘制 ==> 分块 ==> 光栅化 ==> 合成;
    从0，1字节流到最后页面展现在你面前，这里面渲染机制肯定很复杂，所以渲染模块把执行过程中化为很多的子阶段，渲染引擎从网络进程拿到字节流数据后，经过这些子阶段的处理，最后输出像素，这个过程可以称为渲染流水线 ，我们从一张图上来看👇

    构建DOM树

    数据类型改变： 字节 ==> 字符 ==> 令牌 ==> 节点 ==> 对象模型
    转化过程：
    1. 转换:浏览器从磁盘或网络读取 HTML 的原始字节，并根据文件的指定编码（例如 UTF-8）将它们转换成各个字符。
    2. 令牌化：浏览器将字符串转换成 W3C HTML5 标准规定的各种令牌，例如，“html”、“head”，以及其他尖括号内的字符串。每个令牌都具有特殊含义和一组规则。
    3. 词法分析：发出的令牌转换成定义其属性和规则的“对象”。
    4. DOM构建：最后，由于 HTML 标记定义不同标记之间的关系（一些标记包含在其他标记内），创建的对象链接在一个树数据结构内，此结构也会捕获原始标记中定义的父项-子项关系：HTML 对象是 body 对象的父项，body 是 paragraph 对象的父项，依此类推。

      样式计算

  • 格式化样式表*
    我们拿到的也就是0，1字节流数据，浏览器无法直接去识别的，所以渲染引擎收到CSS文本数据后，会执行一个操作，转换为浏览器可以理解的结构styleSheets；
    通过浏览器的控制台document.styleSheets可以来查看这个最终结果。通过JavaScript可以完成查询和修改功能,或者说这个阶段为后面的样式操作提供基石。
  • 标准化样式表*
    有些时候，我们写CSS 样式的时候，会写font-size:2em;color:red;font-weight:bold,像这些数值并不容易被渲染引擎所理解，因此需要在计算样式之前将它们标准化，如em->px,red->rgba(255,0,0,0),bold->700等等。
    我们来看看标准化的变化过程，如下图
  • 计算每个DOM节点具体样式*
    通过之前的格式化和标准化后，接下来就是计算每个节点具体样式信息了。
    计算规则：继承和层叠
  • 继承*：每个子节点会默认去继承父节点的样式，如果父节点中找不到，就会采用浏览器默认的样式，也叫UserAgent样式。
  • 层叠*：样式层叠，是CSS一个基本特征，它定义如何合并来自多个源的属性值的算法。
    不过值得注意的是，在计算完样式之后，所有的样式值会被挂在到window.getComputedStyle当中，也就是可以通过JS来获取计算后的样式，非常方便。
    这个阶段，完成了DOM节点中每个元素的具体样式，计算过程中要遵循CSS的继承和层叠两条规则，最终输出的内容是每个节点DOM的样式，被保存在ComputedStyle中。

生成布局树

上述过程已经完成DOM树（DOM树）构建，以及样式计算（DOM样式），接下来就是要通过浏览器的布局系统确定元素位置，也就是生成一颗布局树（Layout Tree）,之前说法叫渲染树。
创建布局树
在DOM树上不可见的元素，head元素，meta元素等，以及使用display:none属性的元素，最后都不会出现在布局树上，所以浏览器布局系统需要额外去构建一棵只包含可见元素布局树。
我们直接结合图来看看这个布局树构建过程：

主要流程：

  1. 遍历DOM树可见节点，并把这些节点加到布局树中；
  2. 对于不可见的节点，head,meta标签等都会被忽略。对于body.p.span 这个元素，它的属性包含display:none,所以这个元素没有被包含进布局树。

布局计算
这个请看从Chrome源码看浏览器如何layout布局
一张图看懂渲染前三步流程：

分层

首先需要知道的就是，浏览器在构建完布局树后，还需要进行一系列操作，这样子可能考虑到一些复杂的场景，比如一些些复杂的 3D 变换、页面滚动，或者使用 z-index做 z 轴排序等，还有比如是含有层叠上下文如何控制显示和隐藏等情况。
生成图层树
浏览器的页面实际上被分成了很多图层，这些图层叠加后合成了最终的页面。
我们来看看图层与布局树之间关系，如下图👇

通常情况下，并不是布局树的每个节点都包含一个图层，如果一个节点没有对应的层，那么这个节点就从属于父节点的图层。
那什么情况下，渲染引擎会为特定的节点创建新图层呢？
有两种情况需要分别讨论，一种是显式合成，一种是隐式合成。
显式合成
需要剪裁(clip)的地方或者拥有层叠上下文的节点。层叠上下文也基本上是有一些特定的CSS属性创建的，一般有以下情况:

  1. HTML根元素本身就具有层叠上下文。
  2. 普通元素设置position不为static并且设置了z-index属性，会产生层叠上下文。
  3. 元素的 opacity 值不是 1
  4. 元素的 transform 值不是 none
  5. 元素的 filter 值不是 none
  6. 元素的 isolation 值是isolate
  7. will-change指定的属性值为上面任意一个。

隐式合成
这是一种什么样的情况呢，通俗意义上来说，就是z-index比较低的节点会提升为一个单独的途图层，那么层叠等级比它高的节点都会成为一个独立的图层。
在一个大型的项目中，一个z-index比较低的节点被提升为单独图层后，层叠在它上面的元素统统都会提升为单独的图层，我们知道，上千个图层，会增大内存的压力，有时候会让页面崩溃。这就是层爆炸;

绘制

完成了图层的构建，接下来要做的工作就是图层的绘制了。图层的绘制跟我们日常的绘制一样，每次都会把一个复杂的图层拆分为很小的绘制指令，然后再按照这些指令的顺序组成一个绘制列表，类似于下图👇

分块

接下来我们就要开始绘制操作了，实际上在渲染进程中绘制操作是由专门的线程来完成的，这个线程叫合成线程。
绘制列表准备好了之后，渲染进程的主线程会给合成线程发送commit消息，把绘制列表提交给合成线程。接下来就是合成线程一展宏图的时候啦。

你想呀，有时候，你的图层很大，或者说你的页面需要使用滚动条，然后页面的内容太多，多的无法想象，这个时候需要滚动好久才能滚动到底部，但是通过视口，用户只能看到页面的很小一部分，所以在这种情况下，要绘制出所有图层内容的话，就会产生太大的开销，而且也没有必要。
基于上面的原因，合成线程会讲图层划分为图块(tile);这些块的大小一般不会特别大，通常是 256 * 256 或者 512 * 512 这个规格。这样可以大大加速页面的首屏展示。
首屏渲染加速：
因为后面图块（非视口内的图块）数据要进入 GPU 内存，考虑到浏览器内存上传到 GPU 内存的操作比较慢，即使是绘制一部分图块，也可能会耗费大量时间。针对这个问题，Chrome 采用了一个策略: 在首次合成图块时只采用一个低分辨率的图片，这样首屏展示的时候只是展示出低分辨率的图片，这个时候继续进行合成操作，当正常的图块内容绘制完毕后，会将当前低分辨率的图块内容替换。这也是 Chrome 底层优化首屏加载速度的一个手段。

光栅化

接着上面的步骤，有了图块之后，合成线程会按照视口附近的图块来优先生成位图，实际生成位图的操作是由栅格化来执行的。所谓栅格化，是指将图块转换为位图。

  • 图块是栅格化执行的最小单位
  • 渲染进程中专门维护了一个栅格化线程池，专门负责把图块转换为位图数据
  • 合成线程会选择视口附近的图块(tile)，把它交给栅格化线程池生成位图
  • 生成位图的过程实际上都会使用 GPU 进行加速，生成的位图最后发送给合成线程
    通常，栅格化过程都会使用 GPU 来加速生成，使用 GPU 生成位图的过程叫快速栅格化，或者 GPU 栅格化，生成的位图被保存在 GPU 内存中。

    合成和显示

    栅格化操作完成后，合成线程会生成一个绘制命令，即”DrawQuad”，并发送给浏览器进程。
    浏览器进程中的viz组件接收到这个命令，根据这个命令，把页面内容绘制到内存，也就是生成了页面，然后把这部分内存发送给显卡
    两张图总结渲染过程，如下图：
    感觉好多东西还没有接触，越细越多，此时我的心情如下