深化浏览器之烘托进程与原理

本文首要叙述web前端的根底知识：浏览器是如何来烘托页面的？

浅显了解，文中若有过错，欢迎您的批评指正！

依据上期的文章， 深化浏览器原理之事情循环，咱们持续来学习浏览器相关的中心知识。

经典问题：从输入一个网址到网页显示，这个进程背后都发生了什么？

这是个老生常谈的问题，如下面这张图所示：

依据上期的文章，咱们知道浏览器会敞开一个网络进程，每一个标签页也会对应一个烘托主线程。

1. 咱们翻开某个浏览器，输入某个网址，这个网址在经过 url 解析、DNS 解析等操作后得到了服务器的IP地址。

2. 浏览器的网络线程调用 Socket 库，托付操作体系中的协议栈作业，经过 TCP 三次握手，与服务器树立衔接之后，向这个服务器地址发送 http 恳求，服务器会将浏览器需求的 HTML 文档等资源发送给咱们客户端这边的协议栈，交付给网络线程。

3. 浏览器的网络线程在接收到 HTML 文档之后开端解析，会发生一个烘托使命，并将其传递给烘托主线程的音讯行列。

4. 在事情循环机制的作用下，烘托主线程取出音讯行列中的烘托使命，敞开烘托流程。完结烘托后，才到了咱们终究看到的页面。

这个进程前两个进程其实是网络恳求与呼应进程，后边两个进程其实是烘托进程。以下我就从这两个角度来简单阐述一下，重点还是解说烘托进程。

想直接学习了解浏览器烘托进程的掘友，能够直接点击目录中的烘托进程解析。

网络进程解析

网络恳求与呼应这个进程，信任各位掘友们都挺了解的了，有一篇带佬的文章写得比较详细。 乱星海传送大阵已敞开！ 输入一个网址到网页进程中都发生了什么？

下面就以我个人的了解，简单阐述一下这个网络进程中的知识点：

DNS解析

DNS，Domain Name System，也称为域名体系，首要功能便是将域名解析为相应的 IP 地址。

先看如下图的 DNS 查询进程：

这张图片能够新开一个标签页翻开看，图片太大，缩放之后有点糊。

1. 以 www.baidu.com 为例，咱们浏览器这一端，也便是 DNS 客户端，会先检查浏览器缓存，也便是本地 host 文件；

2. 假如查询未果，DNS 客户端则会将查询恳求提交到本地 DNS 服务器，本地 DNS 服务器会先查找自己的 DNS 缓存；

3. 假如查询未果，本地 DNS 则会向根域名服务器提交查询申请；

4. 根域名服务器则会向本地 DNS 回来 .com 域的 DNS 服务器地址；

5. 本地 DNS 收到之后，则会向 .com 域名的尖端域名服务器提交查询申请；

6. .com 域名的尖端域名服务器则会向本地 DNS 回来 baidu.com 域 DNS 的地址；

7. 本地 DNS 向 baidu.com 域的次级域名服务器发送查询申请；

8. 该次级域名服务器则会回来查询成果，告知他对应的服务器 IP 地址；

9. 本地 DNS 在收到回来成果后，则会本地先缓存一份，然后再向客户端回来查询成果。

总结这个查询次序：客户端 ————> 本地主机表 —— 递归查询 ——> 本地 DNS —— 迭代查询 ——> 根、尖端、次级 DNS。

在 DNS 体系中，有两种查找记载的办法：递归查询和迭代查询。

递归查询：由 DNS 客户端发起，逐级提交查询使用，直至查询停止（上述描绘流程中的2和9进程）；

迭代查询：通常在 DNS 服务器之间完结，即本地 DNS 将查询提交给上层 DNS。上层 DNS 不会直接回来查询成果，但会告知本地 DNS 在哪里查找（上述描绘流程中的3-8进程）。

如总结的次序中所指，客户端向本地 DNS 服务器是递归查询，本地 DNS 服务器向根、尖端、次级 DNS 是迭代查询。

TCP三次握手

TCP协议是牢靠传输（UDP是不牢靠传输），该协议中客户端与服务器树立衔接的进程，一般比较形象的称之为三次握手；断开衔接的进程，则是四次挥手。

http数据是依据TCP协议传输的。经过域名解析，客户端知道了 www.baidu.com 的服务器地址，因而需求先与该 IP 地址树立衔接，然后再传递 http 恳求等数据。

sequenceDiagram
客户端->>服务端: 我想和你树立衔接！
服务端-->>客户端: 行啊!我也想和你树立衔接！
客户端-)服务端: 行啊！

三次握手这个进程，如上面这张图所示，比较简单形象的说法：

1. 客户端向服务器发送一个尝试衔接的恳求。

2. 服务器收到恳求之后，回来给客户端一个相应的承认衔接恳求（“行啊！”），可是这个时分还仅仅客户端到服务器的单向衔接。因而，服务器还会向客户端发送一个衔接恳求。

3. 客户端收到服务器的承认信息和衔接恳求，先检查承认信息是不是自己想要的最新的衔接恳求所对应的承认信息。承认没错的话，也得承认一下服务器的衔接恳求（“行啊！”），这时才树立了能够双向传输的衔接。

从上面这个进程中，你差不多能够明白树立衔接需求三次握手就够了吧，两次不行，四次糟蹋且没必要！最重要的是：三次握手的首要/首要原因是为了防止旧的重复衔接初始化构成混乱。

那么断开衔接，为啥就得四次呢？你能够这样看，断开一个单向衔接就得两次挥手，那么双向的话就得四次。其间两次挥手包括：一个恳求断开，另一个承认断开。当客户端自动恳求断开时，比及双方都承认断开后，客户端会进入Time-wait状况，服务器首先进入close状况，过会客户端才进入close状况。

握手、挥手进程，有一篇带佬的文章写得超超超详细。乱星海传送大阵再次敞开！ 超超超详细解说TCP三次握手与四次挥手（大图解），值得保藏

IP协议和ARP协议

IP协议是网际互连协议，是 TCP/IP 体系中的网络层协议，是 TCP/IP 协议簇的中心，是网络互联互通的根底。

DNS域名解析后得到的服务器地址也便是IP地址，而由IP地址解析得到MAC地址的则是经过ARP协议（地址解析协议）。

网络进程大约如此，讲的比较糙，咱们还是将本文重心放在烘托进程上。

烘托进程解析⭐⭐⭐

烘托进程首要由相应的标签页的烘托主线程来主导履行，整个烘托流程分为多个阶段，分别是：解析HTML、款式核算、布局、分层、制作、分块、光栅化、组成。

以下就分别对烘托进程的各个阶段作原理性说明：

解析HTML

烘托主线程从音讯行列中获取烘托使命，开端进行HTML文档的解析。如下面这张图所示，解析进程中遇到 CSS 则解析 CSS，遇到 JS 则履行 JS ，终究会得到 DOM 树和 CSSOM 树，浏览器的默认款式、内部款式、外部款式、行内款式均会包括在 CSSOM 树中。

由烘托主线程解析 HTML 生成 CSSOM 树和 DOM 树的进程中，首要包括符号化和构建 DOM 树两个进程。

1. 符号化：

   两个进程：词法剖析（符号）、创立符号行列。

   • 词法剖析： 主线程会将原始的 HTML 文档分解成一个个的符号（HTML 文档中的最小单元，例如一个标签、一个特点、文本内容等）。
   • 创立符号行列： 主线程会创立一个符号行列，将 HTML 文档中的一切符号依照它们在文档中的次序排列到行列中。

2. 构建 DOM 树：

   主线程先创立一个 DOM 树的根节点，然后依照符号行列的次序遍历每个符号，依据符号的类型和内容构建 DOM 树的节点。例如：关于元素符号（如 <div>、<p> 等），主线程创立相应的元素节点并设置标签名和特点，然后添加到 DOM 树；关于文本内容符号，主线程创立文本节点，并将其附加到适当的元素节点上。此外，还会依据符号的嵌套联系，树立父子联系，构成完好的 DOM 树结构。

为了进步解析功率和页面加载速度，浏览器在开端解析前，还会发动一个预解析线程，首先检查HTML，识别出需求提早加载的外部资源，其间包括外部 CSS 文件和 外部的 JS 文件，并告诉网络线程下载这些外部资源。预解析的目的是在用户恳求页面之前提早获取并加载页面所需的资源，然后加快页面的烘托进程。

假如烘托主线程解析到link方位（也便是外部款式表），此刻外部的 CSS 文件还没有下载解析好，主线程不会等候，持续解析后续的 HTML。这是因为下载和解析 CSS 的作业是在预解析线程中进行的。因而，CSS 不会阻塞 HTML 的解析！！！

如上面这张图所示，预解析线程识别 HTML 文档中外部 CSS 文件，然后告诉网络线程下载，下载完结后由预解析线程做一些衬托作业，然后由烘托主线程生成 CSSOM 树。

当烘托主线程解析到script方位（也便是JS/TS代码），则会暂停解析 HTML，等候网络线程 JS 文件下载好，并且将全局代码履行完结后，才干持续解析 HTML。因而，JS 会阻塞 HTML 的解析！！！

同样的，如上面这张图所示，预解析线程还会识别 HTML 文档中外部 JS 文件，然后告诉网络线程下载，下载完结后由预解析线程交还给烘托主线程立即履行。当烘托主线程完结 JS 代码履行后，才会持续解析 HTML ，生成 DOM 树。

为什么必定要暂停解析，等候JS文件下载完结呢？

这是因为 JS 代码中，可能会存在修改当时 DOM 树的操作。你假如想等当时烘托使命完结的话，再去履行JS，假如修改了当时的dom树，是不是就肯定得 reflow 或许 repaint ？这岂不是会违反进步烘托功率和页面显示等初衷？所以 DOM 树的生成有必要暂停，先履行完 JS 代码。

核算款式

烘托主线程会遍历得到的 DOM 树，顺次核算每个元素使用的款式，包括从CSS文件中获取并解析构建出款式表规则，核算出终究的款式信息（Computed Style），并将这些规则分别放到对应的DOM树节点上。这一步完结后，会得到一棵带有款式特点的 DOM 树。

在这一进程中，许多预设值会变成绝对值，比方red会变成rgb(255,0,0)；相对单位会变成绝对单位，比方em会变成px。

布局

布局阶段会顺次遍历 DOM 树的每一个节点，结合上一步核算出的终究款式信息，核算每个节点的几许信息（每个元素在屏幕上的方位和大小）。例如节点的宽高、相对包括块的方位。

可是咱们得留意，大部分时分，DOM 树和布局树其实并非一一对应，下面举例说明：

• 比方，DOM 树中display:none的隐藏节点，它没有几许信息，因而不会生成到布局树。
• 又比方，使用了伪元素选择器，尽管 DOM 树中不存在这些伪元素节点，但它们具有几许信息，所以会生成到布局树中。
• 还有匿名行盒、匿名块盒等等也都会导致 DOM 树和布局树无法一一对应。

回流（Reflow）

其本质便是从头核算布局树。当进行了会影响布局树的操作后，需求从头核算布局树。

因而，为了防止连续多次操作导致布局树反复核算，浏览器会合并这些操作，当 JS 代码悉数完结后再进行一致核算。所以，改动特点构成的 reflow 是异步完结的。

那么，紧接着，因为 reflow 是异步完结的，当 JS 获取布局特点时，就可能会构成无法获取到最新的布局信息。

因而，浏览器在反复权衡下，终究决议获取特点时立即 reflow。

分层

烘托主线程会使用一套杂乱的战略，依据布局树将页面划分为多个图层，这些图层能够独立制作和重绘。这样做的首要优点便是，可独自处理每个图层，优化烘托功能。假如某一个层将来改变了，那么也仅会对该层进行后续处理，而不必从头制作整个页面，然后提升功率。

微信截的图，有点糊，右边的预览页面没截，截出来这图直接没法看了，掘友见谅！

这是我写这篇文章时的页面的烘托图层截图，咱们能够看到当时选中的图层是写文章的预览页面，不了解的掘友能够了解了解。

至于如何分层，滚动条、堆叠上下文、transform、opacity 等款式都会或多或少的影响分层成果，也能够经过will-change特点更大程度的影响分层成果（该特点相当于告知浏览器某个元素将会发生一些变化，以便更好分层，做好功能优化）。

制作页面

烘托主线程会依据核算好的款式和布局信息，为每个图层独自生成制作指令集（或许叫构建制作树），用于描绘这一层的内容该如何画出来。以浏览器可见区域为画布，左上角为(0,0)根底坐标，从左到右，从上到下，从 DOM 树的根节点开端，将页面内容制作到各个图层上。

比方，上面这张图中的图层部分，点击烘托后，咱们能够从剖析器中能够看到选中图层的制作指令等。

上面的图比较糊，从头放个清楚的，选中图层如下：

蓝色框符号的那个图层，其实也便是当时看的这篇文章的页面，而不是右边个人中心等其他图层。

该图层制作指令如下：

指令许多，由此也能看到这个浏览器的设计与完结真的是！

重绘（Repaint）

repaint 的本质便是从头依据分层信息核算制作指令（或构建制作树）。

当改动了可见款式后，就会引发 repaint，从头核算。

因为元素的布局信息也属于可见款式，所以reflow 必定会引起 repaint。

分块

完结制作后，烘托主线程将每个图层的制作信息提交给组成线程，剩余作业将由组成线程完结。

sequenceDiagram
烘托主线程->>组成线程: 截止现在，我已经将每个图层都制作完了，后边的使命就交给你了。
组成线程-->>烘托主线程: 收到! 从分块开端，后边这三个阶段的使命就由我来当 Leader 吧！

组成线程会从线程池中拿取多个线程，然后将每个图层分割成小块，甚至划分为更多的小区域，以便更高效地处理和显示。说到底，这也是有助于进步烘托功率的。

上面这张图中便是对当时的写文章标签页的烘托进程的取样，其间蓝色边框框选的进程便是组成线程Compositer。

光栅化

完结分块之后，进入光栅化阶段。光栅化则是将每个块中信息转换为像素（将矢量图形转化为屏幕上的像素），构成终究的位图。

如上面这张图所示，组成线程将块信息交给 GPU 进程，而 GPU 进程会敞开多个线程以极高的速度完结光栅化，并且优先处理靠近视口区域的块。然后， GPU 进程再将这一块一块的位图交还给组成线程。

组成

该阶段是将不同图层依照正确的次序制作到屏幕上，组成为终究的屏幕图画。

大致原理是这样：组成线程拿到每个图层、每个分块的位图后，生成一个个指引（quad）信息。组成线程会把这个指引提交给 GPU 进程，由 GPU 进程发生体系调用，提交给 GPU 硬件，完结终究的屏幕成像。

上述中提到的指引信息会标识出每个位图应该画到屏幕的哪个方位，以及反映旋转、缩放等变形信息。

为什么transform的功率，相比较 Reflow 和 Repaint 要高许多呢？

因为transform特点的变形操作就发生在烘托进程的组成阶段，由组成线程主导履行，与烘托主线程无关，无需从头履行组成前面的阶段。

至此，由 HTML 文档到浏览器页面的烘托进程就履行完结了。

总结

总结浏览器的烘托进程，依照次序首要分为这几个阶段：

解析HTML ————>核算款式————> 布局 ————>分层 ————>制作 ————>分块 ————>光栅化 ————>组成。

咱们能够依据文章中的了解，依据下面的思想导图，来记忆这个烘托进程。

mindmap
      烘托进程
          「解析HTML」，生成DOM树和CSSOM树
            遍历DOM树并「核算款式」，得到带有终究款式的DOM树
             遍历DOM树，核算节点的几许信息，得到「布局」树（留意：布局树和DOM树并不一一对应）
              对布局树「分层」
               为每个图层生成制作指令集，完结各图层的「制作」
                对每个图层进行「分块」，由组成线程将分块组成
                 「光栅化」，优先处理靠近视口区域的块，得到一块块的位图
                   生成指引信息，「组成」图层，由GPU完结终究成像显示

此外，从解析HTML到制作阶段一直由烘托主线程主导履行，而分块到组成阶段则一直由组成线程主导履行。