Chrome 架构：打开一个页面，为什么有4个进程？

进程和线程

• 并行处理：同一时刻处理多个任务，使用并行处理能大大提升性能。
• 多线程可以并行处理任务，但是线程是不能单独存在的，它是由进程来启动和管理的。
• 一个进程就是一个程序的运行实例。详细解释就是，启动一个程序的时候，操作系统会为该程序创建一块内存，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的一个运行环境叫进程。

• 线程是依附于进程的，而进程中使用多线程并行处理能提升运算效率。
• 进程中的任意一线程执行出错，都会导致整个进程的崩溃。
• 线程之间共享进程中的数据。线程之间可以对进程的公共数据进行读写操作。
• 当一个进程关闭之后，操作系统会回收进程所占用的内存。当一个进程退出时，操作系统会回收该进程所申请的所有资源；即使其中任意线程因为操作不当导致内存泄漏，当进程退出时，这些内存也会被正确回收。
• 进程之间的内容相互隔离。进程隔离是为保护操作系统中进程互不干扰的技术，每一个进程只能访问自己占有的数据，也就避免出现进程 A 写入数据到进程 B 的情况。正是因为进程之间的数据是严格隔离的，所以一个进程如果崩溃了，或者挂起了，是不会影响到其他进程的。如果进程之间需要进行数据的通信，这时候，就需要使用用于进程间通信（IPC）的机制了。

单进程浏览器时代

单进程浏览器是指浏览器的所有功能模块都是运行在同一个进程里，这些模块包含了网络、插件、JavaScript 运行环境、渲染引擎和页面等。

如此多的功能模块运行在一个进程里，是导致单进程浏览器不稳定、不流畅和不安全的一个主要因素。

• 不稳定：早期浏览器需借助插件实现如web视频、游戏等功能，但插件容易出问题，并且还运行在浏览器进程中，所以一个插件的意外会引起整个浏览器崩溃。除此之外，还有渲染引擎模块也是不稳定的，遇到一些复杂的JavaScript容易导致渲染引擎崩溃，从而导致整个浏览器崩溃。
• 不流畅：所有页面的渲染模块、JavaScript 执行环境以及插件都是运行在同一个线程中的，这就意味着同一时刻只能有一个模块可以执行。如果有一个无限循环的js脚本在运行，那么其他模块都没有被执行的机会，这样会导致浏览器失去响应、变卡顿。除了脚本和插件，页面的内存泄漏也是单进程变慢的一个重要原因。通常浏览器的内核都是非常复杂的，运行一个复杂点的页面再关闭页面，会存在内存不能完全回收的情况，这样导致的问题是使用时间越长，内存占用越高，浏览器会变得越慢。
• 不安全：通过插件可以获取到操作系统的任意资源。页面脚本可以通过浏览器的漏洞来获取系统权限。

多进程浏览器时代

早期多进程架构

图中可以看出，Chrome 页面运行在单独的渲染进程中，页面里的插件运行在单独的插件进程中，进程之间通过 IPC 机制进行通信。

进程间相互隔离，一个页面或插件崩溃仅影响到当前页面进程或插件进程，不会影响到浏览器和其他页面，由此解决了单进程浏览器不稳定的问题。

JavaScript 也是运行在渲染进程中的，所以即使 JavaScript 阻塞了渲染进程，影响到的也只是当前的渲染页面，而并不会影响浏览器和其他页面。因为其他页面的脚本是运行在它们自己的渲染进程中的。当关闭一个页面时，整个渲染进程也会被关闭，之后该进程所占用的内存都会被系统回收。由此解决了不流畅的问题。

采用多进程架构可以使用安全沙箱，沙箱里的程序可以运行，但不能你的硬盘上写入任何数据，也不能在敏感位置读取任何数据，由此解决了不安全的问题。

目前的多进程架构

最新的 Chrome 浏览器包括：1 个浏览器（Browser）主进程、1 个 GPU 进程、1 个网络（NetWork）进程、多个渲染进程和多个插件进程。

• 浏览器进程。主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
• 渲染进程。核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
• GPU 进程。 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。
• 网络进程。主要负责页面的网络资源加载。
• 插件进程。主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

打开 1 个页面至少需要 1 个网络进程、1 个浏览器进程、1 个 GPU 进程以及 1 个渲染进程，共 4 个；如果打开的页面有运行插件的话，还需要再加上 1 个插件进程。

多进程模型提升了浏览器的稳定性、流畅性和安全性，但同样不可避免地带来了一些问题：

• 更高的资源占用：因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源。
• 更复杂的体系架构：浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了。

未来面向服务的架构（SOA)

原来的各种模块会被重构成独立的服务（Service），每个服务（Service）都可以在独立的进程中运行，访问服务（Service）必须使用定义好的接口，通过 IPC 来通信，从而构建一个更内聚、松耦合、易于维护和扩展的系统，更好实现 Chrome 简单、稳定、高速、安全的目标。

TCP协议：如何保证页面文件能被完整送达浏览器

互联网，实际上是一套理念和协议组成的体系架构。其中协议是一套众所周知的规则和标准，如果各方都同意使用，那么它们之间的通信将毫无障碍。

互联网中的数据是通过数据包来传输的。如果发送的数据很大，那么该数据就会被拆分为很多小数据包来传输。

1、IP：把数据包送达目的主机

• 数据包要在互联网上进行传输，就要符合网际协议（Internet Protocol，简称 IP）标准。互联网上不同的在线设备都有唯一的地址。
• 计算机的地址就称为 IP 地址，访问任何网站实际上只是你的计算机向另外一台计算机请求信息。
• IP 头是 IP 数据包开头的信息，包含 IP 版本、源 IP 地址、目标 IP 地址、生存时间等信息。

2、UDP：把数据包送达应用程序

• IP 是非常底层的协议，只负责把数据包传送到对方电脑，但是对方电脑并不知道把数据包交给哪个程序。因此，需要基于 IP 之上开发能和应用打交道的协议，最常见的是“用户数据包协议（User Datagram Protocol）”，简称 UDP。
• UDP 中一个最重要的信息是端口号，通过端口号 UDP 就能把指定的数据包发送给指定的程序。
• 和IP头一样，端口号会被装进 UDP 头里面，UDP 头再和原始数据包合并组成新的 UDP 数据包。UDP 头中除了目的端口，还有源端口号等信息
• 在使用 UDP 发送数据时，有各种因素会导致数据包出错，虽然 UDP 可以校验数据是否正确，但是对于错误的数据包，UDP 并不提供重发机制，只是丢弃当前的包，而且 UDP 在发送之后也无法知道是否能达到目的地。
• 虽说UDP 不能保证数据可靠性，但是传输速度却非常快，所以 UDP 会应用在一些关注速度、但不那么严格要求数据完整性的领域，如在线视频、互动游戏等。

3、TCP：把数据完整地送达应用程序

对于浏览器请求，或者邮件这类要求数据传输可靠性（reliability）的应用，如果使用 UDP 来传输会存在两个问题：

• 数据包在传输过程中容易丢失；
• 大文件会被拆分成很多小的数据包来传输，这些小的数据包会经过不同的路由，并在不同的时间到达接收端，而 UDP 协议并不知道如何组装这些数据包，从而把这些数据包还原成完整的文件。

由此引入 TCP。TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。相对于 UDP，TCP 有下面两个特点:

• 对于数据报丢失的情况，TCP 提供重传机制
• TCP 引入了数据包排序机制，用来保证把乱序的数据包组合成一个完整的文件

TCP 头除了包含了目标端口和本机端口号外，还提供了用于排序的序列号，以便接收端通过序号来重排数据包。

一个完整的 TCP 连接的生命周期包括了 “建立连接”、“传输数据” 和 “断开连接”三个阶段。

• 首先，建立连接阶段。这个阶段是通过“三次握手”来建立客户端和服务器之间的连接。TCP 提供面向连接的通信传输。面向连接是指在数据通信开始之前先做好两端之间的准备工作。所谓三次握手，是指在建立一个 TCP 连接时，客户端和服务器总共要发送三个数据包以确认连接的建立。
• 其次，传输数据阶段。在该阶段，接收端需要对每个数据包进行确认操作，也就是接收端在接收到数据包之后，需要发送确认数据包给发送端。所以当发送端发送了一个数据包之后，在规定时间内没有接收到接收端反馈的确认消息，则判断为数据包丢失，并触发发送端的重发机制。同样，一个大的文件在传输过程中会被拆分成很多小的数据包，这些数据包到达接收端后，接收端会按照 TCP 头中的序号为其排序，从而保证组成完整的数据。
• 最后，断开连接阶段。数据传输完毕之后，就要终止连接了，涉及到最后一个阶段“四次挥手”来保证双方都能断开连接。

TCP 为了保证数据传输的可靠性，牺牲了数据包的传输速度，因为“三次握手”和“数据包校验机制”等把传输过程中的数据包的数量提高了一倍。

HTTP请求流程：为什么很多站点第二次打开速度会很快？

HTTP 协议是建立在 TCP 连接基础之上的。HTTP 是一种允许浏览器向服务器获取资源的协议，是 Web 的基础。HTTP 也是浏览器使用最广的协议。

浏览器发起 HTTP 请求流程

1. 构建请求

首先，浏览器构建请求行信息（如下所示），构建好后，浏览器准备发起网络请求。

GET /index.html HTTP1.1

2. 查找缓存

在真正发起网络请求之前，浏览器会先在浏览器缓存中查询是否有要请求的文件。其中，浏览器缓存是一种在本地保存资源副本，以供下次请求时直接使用的技术。

当浏览器发现请求的资源已经在浏览器缓存中存有副本，它会拦截请求，返回该资源的副本，并直接结束请求，而不会再去源服务器重新下载。这样做的好处有：

• 缓解服务器端压力，提升性能（获取资源的耗时更短了）；
• 对于网站来说，缓存是实现快速资源加载的重要组成部分。

当然，如果缓存查找失败，就会进入网络请求过程了。

3. 准备 IP 地址和端口

HTTP与TCP的关系

• 浏览器使用HTTP 协议作为应用层协议，用来封装请求的文本信息；并使用TCP/IP作为传输层协议将它发送到网络。所以HTTP网络请求的第一步是服务器建立 TCP 连接。
• HTTP的内容是通过TCP的传输数据阶段来实现的。
• 前面说过建立TCP连接第一步就是需要准备IP地址和端口号
• 拿到一个URL地址，浏览器首先会请求 DNS 返回域名对应的 IP。浏览器还提供了DNS数据缓存服务，如果某个域名解析过了，那么浏览器会缓存解析的结果。
• 拿到 IP 之后，接下来就需要获取端口号了。通常情况下，如果 URL 没有特别指明端口号，那么 HTTP 协议默认是 80 端口。

4. 等待 TCP 队列

Chrome 有个机制，同一个域名同时最多只能建立 6 个 TCP 连接，如果在同一个域名下同时有 10 个请求发生，那么其中 4 个请求会进入排队等待状态，直至进行中的请求完成。当然，如果当前请求数量少于 6，会直接进入下一步，建立 TCP 连接。

5. 建立 TCP 连接

在 HTTP 工作开始之前，浏览器通过 TCP 与服务器建立连接

6. 发送 HTTP 请求

• 首先浏览器会向服务器发送请求行，它包括了请求方法、请求 URI（Uniform Resource Identifier）和 HTTP 版本协议。
• 在浏览器发送请求行命令之后，还要以请求头形式发送其他一些信息，把浏览器的一些基础信息告诉服务器。
• POST请求还会有请求体。

服务器端处理 HTTP 请求流程

1. 返回请求

一旦服务器处理结束，便可以返回数据给浏览器了。

• 首先服务器会返回响应行，包括协议版本和状态码。
• 并非所有请求都可被服务器处理，对于一些无法处理或错误的信息，服务器通过请求行的状态码告知浏览器处理结果。200表示成功，404表示没有找到页面，301表示重定向。
• 随后，服务器也会随同响应向浏览器发送响应头。响应头包含了服务器自身的一些信息，比如服务器生成返回数据的时间、返回的数据类型（JSON、HTML、流媒体等类型），以及服务器要在客户端保存的 Cookie 等信息。
• 发送完响应头后，服务器就可以继续发送响应体的数据，通常，响应体就包含了 HTML 的实际内容。

2. 断开连接

通常情况下，一旦服务器向客户端返回了请求数据，它就要关闭 TCP 连接。不过如果浏览器或者服务器在其头信息中加入了：

Connection:Keep-Alive

那么 TCP 连接在发送后将仍然保持打开状态，这样浏览器就可以继续通过同一个 TCP 连接发送请求。**保持 TCP 连接可以省去下次请求时需要建立连接的时间，提升资源加载速度。** 比如，一个 Web 页面中内嵌的图片就都来自同一个 Web 站点，如果初始化了一个持久连接，你就可以复用该连接，以请求其他资源，而不需要重新再建立新的 TCP 连接。

总览

为什么很多站点第二次打开速度会很快

第一次加载页面过程中，缓存了一些耗时的数据，DNS缓存和页面资源缓存这两块数据是会被浏览器缓存的。DNS 缓存比较简单，它主要就是在浏览器本地把对应的 IP 和域名关联起来。

浏览器资源缓存处理过程：

从上图的第一次请求可以看出，当服务器返回 HTTP 响应头给浏览器时，浏览器是**通过响应头中的 Cache-Control 字段来设置是否缓存该资源。**还需要设置一个缓存过期时长。

如果缓存过期了，浏览器则会继续发起网络请求，并且在 HTTP 请求头中带上：

If-None-Match:"4f80f-13c-3a1xb12a"

服务器收到请求头后，会根据 If-None-Match 的值来判断请求的资源是否有更新。如果没有更新，就返回 304 状态码，相当于服务器告诉浏览器：“这个缓存可以继续使用，这次就不重复发送数据给你了。”如果资源有更新，服务器就直接返回最新资源给浏览器。

简要来说，很多网站第二次访问能够秒开，是因为这些网站把很多资源都缓存在了本地，浏览器缓存直接使用本地副本来回应请求，而不会产生真实的网络请求，从而节省了时间。同时，DNS 数据也被浏览器缓存了，这又省去了 DNS 查询环节

登录状态是如何保持的

如果服务器端发送的响应头内有 Set-Cookie 的字段，那么浏览器就会将该字段的内容保持到本地。当下次客户端再往该服务器发送请求时，客户端会自动在请求头中加入 Cookie 值后再发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到该用户的状态信息。

导航流程：从输入URL到页面展示，这中间发生了什么？

流程大致描述：

• 首先，浏览器进程接收到用户输入的 URL 请求，浏览器进程便将该 URL 转发给网络进程。
• 然后，在网络进程中发起真正的 URL 请求。
• 接着网络进程接收到了响应头数据，便解析响应头数据，并将数据转发给浏览器进程。
• 浏览器进程接收到网络进程的响应头数据之后，发送“提交导航 (CommitNavigation)”消息到渲染进程；
• 渲染进程接收到“提交导航”的消息之后，便开始准备接收 HTML 数据，接收数据的方式是直接和网络进程建立数据管道；
• 最后渲染进程会向浏览器进程“确认提交”，这是告诉浏览器进程：“已经准备好接受和解析页面数据了”。
• 浏览器进程接收到渲染进程“提交文档”的消息之后，便开始移除之前旧的文档，然后更新浏览器进程中的页面状态。

这其中，用户发出 URL 请求到页面开始解析的这个过程，就叫做导航。

1. 用户输入

用户输入一个查询关键字，地址栏会判断输入的关键字是搜索内容，还是请求的 URL。

• 如果是搜索内容 ，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的 URL。
• 如果输入内容符合 URL 规则，地址栏会根据规则，把这段内容加上协议，合成完整的URL。

当用户输入关键字并键入回车之后，这意味着当前页面即将要被替换成新的页面，不过在这个流程继续之前，浏览器还给了当前页面一次执行 beforeunload 事件的机会，beforeunload 事件允许页面在退出之前执行一些数据清理操作，还可以询问用户是否要离开当前页面，比如当前页面可能有未提交完成的表单等情况，因此用户可以通过 beforeunload 事件来取消导航，让浏览器不再执行任何后续工作。

如果当前页面没有监听 beforeunload 事件或同意继续后续流程后，浏览器便开始加载URL。

2. URL请求过程

进入了页面资源请求过程后，浏览器进程会通过进程间通信（IPC）把 URL 请求发送至网络进程，网络进程接收到 URL 请求后，会在这里发起真正的 URL 请求流程。

首先，网络进程会查找本地缓存是否缓存了该资源。如果有缓存资源，那么直接返回资源给浏览器进程；如果在缓存中没有查找到资源，那么直接进入网络请求流程。请求前的第一步是要进行 DNS 解析，以获取请求域名的服务器 IP 地址。如果请求协议是 HTTPS，那么还需要建立 TLS 连接。

接下来就是利用 IP 地址和服务器建立 TCP 连接。连接建立之后，浏览器端会构建请求行、请求头等信息，并把和该域名相关的 Cookie 等数据附加到请求头中，然后向服务器发送构建的请求信息。

服务器接收到请求信息后，会根据请求信息生成响应数据（包括响应行、响应头和响应体等信息），并发给网络进程。等网络进程接收了响应行和响应头之后，就开始解析响应头的内容了。

（1）重定向

• 在接收到服务器返回的响应头后，网络进程开始解析响应头，如果发现返回的状态码是 301 或者 302，那么说明服务器需要浏览器重定向到其他 URL。这时网络进程会从响应头的 Location 字段里面读取重定向的地址，然后再发起新的 HTTP 或者 HTTPS 请求，一切又重头开始了。
• 在导航过程中，如果服务器响应行的状态码包含了 301、302 一类的跳转信息，浏览器会跳转到新的地址继续导航；如果响应行是 200，那么表示浏览器可以继续处理该请求。

（2）响应数据类型处理

• URL 请求的数据类型，有时候是一个下载类型，有时候是正常的 HTML 页面，那么浏览器是如何区分它们呢？
• 答案是 Content-Type。Content-Type 是 HTTP 头中一个非常重要的字段， 它告诉浏览器服务器返回的响应体数据是什么类型，然后浏览器会根据 Content-Type 的值来决定如何显示响应体的内容。
• 不同 Content-Type 的后续处理流程也截然不同。如果 Content-Type 字段的值被浏览器判断为**下载类型，那么该请求会被提交给浏览器的下载管理器，同时该 URL 请求的导航流程就此结束。**但如果是 HTML，那么浏览器则会继续进行导航流程。由于 Chrome 的页面渲染是运行在渲染进程中的，所以接下来就需要准备渲染进程了。

3. 准备渲染进程

默认情况下，Chrome 会为每个页面分配一个渲染进程，也就是说，每打开一个新页面就会配套创建一个新的渲染进程。但是，也有一些例外，在某些情况下，浏览器会让多个页面直接运行在同一个渲染进程中。

什么情况下多个页面会同时运行在一个渲染进程？

• Chrome 的默认策略是，每个标签对应一个渲染进程。但如果从一个页面打开了另一个新页面，而新页面和当前页面属于同一站点的话，那么新页面会复用父页面的渲染进程。
• 同一站点：根域名（如cdsy.xyz)+协议（https:// 或 http://)

  //一下都属于同一站点
  https://time.cdsy.xyz
  https://www.cdsy.xyz
  https://www.cdsy.xyz:8080
  

渲染进程准备好之后，还不能立即进入文档解析状态，因为此时的文档数据还在网络进程中，并没有提交给渲染进程，所以下一步就进入了提交文档阶段。

4. 提交文档

所谓提交文档，就是指浏览器进程将网络进程接收到的 HTML 数据提交给渲染进程，具体流程是这样的：

• 首先当浏览器进程接收到网络进程的响应头数据之后，便向渲染进程发起“提交文档”的消息；
• 渲染进程接收到“提交文档”的消息后，会和网络进程建立传输数据的“管道”；
• 等文档数据传输完成之后，渲染进程会返回“确认提交”的消息给浏览器进程；
• 浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括了安全状态、地址栏的 URL、前进后退的历史状态，并更新 Web 页面。

其中，当浏览器进程确认提交后，更新内容如下：

这也就解释了为什么在浏览器的地址栏里面输入了一个地址后，之前的页面没有立马消失，而是要加载一会儿才会更新页面。

5. 渲染阶段

一旦文档被提交，渲染进程便开始页面解析和子资源加载了。一旦页面生成完成，渲染进程会发送一个消息给浏览器进程，浏览器接收到消息后，会停止标签图标上的加载动画。至此，渲染结束，一个完整的页面就生成了。

渲染阶段详细内容，请看下篇。

渲染流程：HTML、CSS 和 JavaScript 是如何变成页面的？

渲染模块在执行过程中会被划分为很多子阶段，输入的 HTML 经过这些子阶段，最后输出像素。我们把这样的一个处理流程叫做渲染流水线。

按照渲染的时间顺序，流水线可分为如下几个子阶段：构建 DOM 树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。

每个阶段应该关注：开始每个子阶段都有其输入的内容；然后每个子阶段有其处理过程；最终每个子阶段会生成输出内容。

构建 DOM 树

浏览器无法直接理解和使用 HTML，所以需要将 HTML 转换为浏览器能够理解的结构——DOM 树

在控制台输入document即可查看DOM树，DOM 和 HTML 内容几乎是一样的，但是和 HTML 不同的是，DOM 是保存在内存中树状结构，可以通过 JavaScript 来查询或修改其内容。

样式计算（Recalculate Style）

样式计算阶段的目的是为了计算出 DOM 节点中每个元素的具体样式，在计算过程中需要遵守 CSS 的继承和层叠两个规则。这个阶段最终输出的内容是每个 DOM 节点的样式，并被保存在 ComputedStyle 的结构内。

样式计算的目的是为了计算出 DOM 节点中每个元素的具体样式，该阶段大体可分为三步完成。

1. 把 CSS 转换为浏览器能够理解的结构

浏览器无法直接理解这些纯文本的 CSS 样式，所以当渲染引擎接收到 CSS 文本时，会执行一个转换操作，将 CSS 文本转换为浏览器可以理解的结构——styleSheets。

在控制台输入document.styleSheets可以查看其结构。该结构同时具备了查询和修改功能，这会为后面的样式操作提供基础。

2. 转换样式表中的属性值，使其标准化

上面的 CSS 文本中有很多属性值，如 2em、blue、bold，这些类型数值不容易被渲染引擎理解，所以需要将所有值转换为渲染引擎容易理解的、标准化的计算值，这个过程就是属性值标准化。

3. 计算出 DOM 树中每个节点的具体样式

这就涉及到了 CSS 的继承规则和层叠规则了。

• CSS 继承就是每个 DOM 节点都包含有父节点的样式。
• 层叠是 CSS 的一个基本特征，它是一个定义了如何合并来自多个源的属性值的算法。它在 CSS 处于核心地位，CSS 的全称“层叠样式表”正是强调了这一点

布局阶段（Layout）

接下来就需要计算出 DOM 树中可见元素的几何位置，我们把这个计算过程叫做布局。

Chrome 布局阶段需要完成两个任务：创建布局树和布局计算

1. 创建布局树

DOM 树还含有很多不可见的元素，比如 head 标签，还有使用了 display:none 属性的元素。所以在显示之前，我们还要额外地构建一棵只包含可见元素布局树。

DOM 树中所有不可见的节点都没有包含到布局树中。为了构建布局树，浏览器大体上完成了下面这些工作：

• 遍历 DOM 树中的所有可见节点，并把这些节点加到布局树中；
• 而不可见的节点会被布局树忽略掉，如 head 标签下面的全部内容，再比如 body.p.span 这个元素，因为它的属性包含 dispaly:none，所以这个元素也没有被包进布局树。

2. 布局计算

现在我们有了一棵完整的布局树。那么接下来，就要计算布局树节点的坐标位置了。

在执行布局操作的时候，会把布局运算的结果重新写回布局树中，所以布局树既是输入内容也是输出内容，这是布局阶段一个不合理的地方，因为在布局阶段并没有清晰地将输入内容和输出内容区分开来。针对这个问题，Chrome 团队正在重构布局代码，下一代布局系统叫 LayoutNG，试图更清晰地分离输入和输出，从而让新设计的布局算法更加简单。

分层

浏览器的页面实际上被分成了很多图层，这些图层叠加后合成了最终的页面。

现在我们有了布局树，而且每个元素的具体位置信息都计算出来了，接下来并不是直接绘制页面。因为页面中有很多复杂的效果，如一些复杂的 3D 变换、页面滚动，或者使用 z-indexing 做 z 轴排序等，为了更加方便地实现这些效果，渲染引擎还需要为特定的节点生成专用的图层，并生成一棵对应的图层树（LayerTree）。正是这些图层叠加在一起构成了最终的页面图像。

图层与布局树节点之间的关系：

• 通常情况下，并不是布局树的每个节点都包含一个图层，如果一个节点没有对应的层，那么这个节点就从属于父节点的图层。
• 通常满足以下两点中任意一点的元素就可以被提升为单独的一个图层。
  • 拥有层叠上下文属性的元素会被提升为单独的一层：明确定位属性的元素、定义透明属性的元素、使用 CSS 滤镜的元素等，都拥有层叠上下文属性。（position，z-index，filter，opacity）
  • 需要剪裁（clip）的地方也会被创建为图层：比如在一个200*200px的div中放入较多的文字内容，当文字内容超出规定区域，就产生了剪裁，渲染引擎会把裁剪文字内容的一部分用于显示在div区域中。

图层绘制

完成图层树的构建之后，渲染引擎会对图层树中的每个图层进行绘制

渲染引擎实现图层的绘制会把一个图层的绘制拆分成很多小的绘制指令，然后再把这些指令按照顺序组成一个待绘制列表，如下图所示：

绘制一个元素通常需要好几条绘制指令，因为每个元素的背景、前景、边框都需要单独的指令去绘制。所以在图层绘制阶段，输出的内容就是这些待绘制列表。

可以打开“开发者工具”的“Layers”标签，选择“document”层，实际体验绘制列表。

栅格化（raster）操作

绘制列表只是用来记录绘制顺序和绘制指令的列表，而实际上绘制操作是由渲染引擎中的合成线程来完成的。当图层的绘制列表准备好之后，主线程会把该绘制列表**提交（commit）**给合成线程。

视口：通常一个页面可能很大，但用户只能看到其中一部分，我们把用户可以看到的这个部分叫做视口（viewport)。

在有些情况下，有的图层可以很大，比如有的页面你使用滚动条要滚动好久才能滚动到底部，但是通过视口，用户只能看到页面的很小一部分，所以在这种情况下，要绘制出所有图层内容的话，就会产生太大的开销，而且也没有必要。

基于这个原因，合成线程会将图层划分为图块（tile），这些图块大小通常为 256x256 或 512x512

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

而图块是栅格化执行的最小单位。渲染进程维护了一个栅格化的线程池，所有的图块栅格化都是在线程池内执行的。通常，栅格化过程都会使用 GPU 来加速生成，使用 GPU 生成位图的过程叫快速栅格化，或者 GPU 栅格化，生成的位图被保存在 GPU 内存中。

从图中可以看出，渲染进程把生成图块的指令发送给 GPU，然后在 GPU 中执行生成图块的位图，并保存在 GPU 的内存中。

合成和显示

• 一旦所有图块都被光栅化，合成线程就会生成一个绘制图块的命令——“DrawQuad”，然后将该命令提交给浏览器进程。
• 浏览器进程里面有一个叫 viz 的组件，用来接收合成线程发过来的 DrawQuad 命令，然后根据 DrawQuad 命令，将其页面内容绘制到内存中，最后再将内存显示在屏幕上。
• 到这里，经过这一系列的阶段，编写好的 HTML、CSS、JavaScript 等文件，经过浏览器就会显示出漂亮的页面了。

渲染流水线大总结

• 渲染进程将 HTML 内容转换为能够读懂的 DOM 树结构。
• 渲染引擎将 CSS 样式表转化为浏览器可以理解的 styleSheets，计算出 DOM 节点的样式。
• 创建布局树，并计算元素的布局信息。
• 对布局树进行分层，并生成分层树。
• 为每个图层生成绘制列表，并将其提交到合成线程。
• 合成线程将图层分成图块，并在光栅化线程池中将图块转换成位图。
• 合成线程发送绘制图块命令 DrawQuad 给浏览器进程。
• 浏览器进程根据 DrawQuad 消息生成页面，并显示到显示器上。

重排、重绘、合成

1. 更新了元素的几何属性（重排）

如果你通过 JavaScript 或者 CSS 修改元素的几何位置属性，例如改变元素的宽度、高度等，那么浏览器会触发重新布局，解析之后的一系列子阶段，这个过程就叫重排。无疑，重排需要更新完整的渲染流水线，所以开销也是最大的。

2. 更新元素的绘制属性（重绘）

如果修改了元素的背景颜色，那么布局阶段将不会被执行，因为并没有引起几何位置的变换，所以就直接进入了绘制阶段，然后执行之后的一系列子阶段，这个过程就叫重绘。相较于重排操作，重绘省去了布局和分层阶段，所以执行效率会比重排操作要高一些。

3. 直接合成阶段

那如果你更改一个既不要布局也不要绘制的属性，会发生什么变化呢？渲染引擎将跳过布局和绘制，只执行后续的合成操作，我们把这个过程叫做合成。

上图使用了 CSS 的 transform 来实现动画效果，这可以避开重排和重绘阶段，直接在非主线程上执行合成动画操作。这样的效率是最高的，因为是在非主线程上合成，并没有占用主线程的资源，另外也避开了布局和绘制两个子阶段，所以相对于重绘和重排，合成能大大提升绘制效率。