浏览器渲染

从输入URL到导航过程完成之后，浏览器进程把数据交给了渲染进程，渲染进程负责tab内的所有事情，核心目的就是将HTML/CSS/JS代码，转化为用户可进行交互的web页面。

渲染进程中，包含线程分别是：

• 一个主线程（main thread）
• 多个工作线程（work thread）
• 一个合成器线程（compositor thread）
• 多个光栅化线程（raster thread）

1、浏览器内核对内容渲染的大体步骤：

1. 解析html建立DOM树，解析css建立CSSOM树；
2. 结合DOM树和CSSOM树，构建render树；
3. 布局render树（Layout/reflow），负责各元素尺寸、位置的计算；
4. 绘制render树（paint），绘制页面像素信息；
5. 浏览器会将各层的信息发送给GPU，GPU会将各层合成（composite），显示在屏幕上；

浏览器渲染的目标区域，为标签栏下方区域即content。整个渲染过程我们的输入是前端的代码，输出是content区域的像素点。

为了构建渲染树，浏览器主要完成了以下工作：

1. 从DOM树的根节点开始遍历每个可见节点。
2. 对于每个可见的节点，找到CSSOM树中对应的规则，并应用它们。
3. 根据每个可见节点以及其对应的样式，组合生成渲染树。

第一步中说到了要遍历可见的节点，不可见的节点包括：

• 一些不会渲染输出的节点，比如script、meta、link等。
• 一些通过css进行隐藏的节点。比如display:none。注意，利用visibility和opacity隐藏的节点，还是会显示在渲染树上的。只有display:none的节点才不会显示在渲染树上。

2、css加载是否会阻塞dom树渲染？

css是由单独的下载线程异步下载的，头部引入css的情况下：

• css加载不会阻塞DOM树解析（异步加载时DOM照常构建）；
• 但会阻塞render树渲染（渲染时需等css加载完毕，因为render树需要css信息）；

为什么会阻塞渲染树？因为如果不阻塞的话，渲染树渲染之后又要重新渲染CSS的样式，所以干脆就先把DOM树的结构先解析完，把可以做的工作做完，然后等你css加载完之后，再根据最终的样式来渲染render树。

media query除外，不会阻塞渲染

3、CSS定位机制

在CSS中是有三种定位机制的：普通文档流、浮动和定位。

普通流就是正常的文档流，在HTML里面的写法就是从上到下，从左到右的排版布局。一旦给其中的某个div设置float或者absolute定位（不包括static/relative，这两个依然保持正常的文档流），则它完全脱离文档流，不占空间。

定位中，fixed和absolute定位会脱离文档流，元素原来的位置会被覆盖，而relative定位则不会脱离文档流，元素原来的位置还保留。浮动也会脱离文档流。

4、普通图层和复合图层

浏览器渲染的图层一般包含两大类：普通图层（渲染图层）以及复合图层；

渲染图层：是页面普通文档流。无论添加多少元素，还在在同一个默认复合层。虽然绝对定位（absolute），相对定位（fixed），浮动定位（float）会让元素成为脱离文档流，但它仍然属于默认复合层，共用同一个绘图上下文对象（GraphicsContext）。

复合图层：又称图形层，它会单独分配系统资源，每个复合图层都有一个独立的GraphicsContext。（当然也会脱离普通文档流，这样一来，不管这个复合图层中怎么变化，也不会影响默认复合层里的回流Reflow重绘Repaint）。

通过硬件加速就可以使渲染图层提升为复合图层，在GPU中，各个复合图层单独绘制，故互不影响。动画借助复合层，只渲染自己所在的复合层，而不影响其他复合层。从而提升性能。

如何变成复合图层：将元素变成一个复合图层，就是开启硬件加速技术

• 最常用的方式：translate3d、translateZ；
• opacity属性/过渡动画（需要动画执行的过程中才会创建合成层，动画没有开始或结束后元素还会回到之前的状态）；
• will-chang属性（这个比较偏僻），一般配合opacity与translate使用；

作用是提前告诉浏览器要变化，这样浏览器会开始做一些优化工作（这个最好用完后就释放）

• <video><iframe><canvas><webgl>等元素；
• 其它，譬如以前的flash插件；

absolute和硬件加速的区别：

！！！absolute虽然可以脱离普通文档流，但是无法脱离默认复合层。所以，就算absolute中信息改变时不会改变普通文档流中render树，但是，浏览器最终绘制时，是整个复合层绘制的，所以absolute中信息的改变，仍然会影响整个复合层的绘制。（浏览器会重绘它，如果复合层中内容多，absolute带来的绘制信息变化过大，资源消耗是非常严重的）

而硬件加速直接就是在另一个复合层了，所以它的信息改变不会影响默认复合层（当然了，内部肯定会影响属于自己的复合层），仅仅是引发最后的合成（输出视图）。

！！！所以，某些动画属性放到另一个复合层，独立于普通文档流中，是为了避免重绘，提高性能。

5、回流和重绘

回流：通过构造渲染树，我们将可见DOM节点以及它对应的样式结合起来，还需要计算它们在设备视口(viewport)内的确切位置和大小，这个计算的阶段就是回流。

重绘：通过构造渲染树和回流阶段，知道哪些节点是可见的，以及可见节点的样式和具体几何信息(位置、大小)，接着将渲染树的每个节点转换为屏幕上的实际像素，这个阶段叫做重绘节点。

！！！何时发生回流重绘？

回流主要是计算节点的位置和几何信息，当页面布局和几何信息发生变化时就需要回流。例如：

• 页面一开始渲染的时候；
• 浏览器的窗口尺寸变化（因为回流是根据视口的大小来计算元素的位置和大小的）；
• 添加或删除可见的DOM元素；
• 元素的位置发生变化；
• 元素的尺寸发生变化（包括外边距、内边框、边框大小、高度和宽度等）；
• 内容发生变化，比如文本变化或图片被另一个不同尺寸的图片所替代；

重绘主要是css树发生变化且对dom树没有节点上的影响，改变样式但并不影响节点在文档流中的位置。例如：

• 颜色、背景颜色
• visibility等

性能优化：避免频繁的样式操作，最好一次性重写style，或者一次性更改class，避免频繁操作dom，对具有复杂动画的元素使用绝对定位，使它脱离文档流，否则会引起父元素及后续元素频繁回流。或者启用硬件加速，如transform、opacity、filters、Will-change属性。

https://gist.github.com/paulirish/5d52fb081b3570c81e3a

6、事件循环机制

宏任务与微任务：

• macrotask（又称之为宏任务），可以理解是每次执行栈执行的代码就是一个宏任务（包括每次从事件队列中获取一个事件回调并放到执行栈中执行）；

  • 每一个task会从头到尾将这个任务执行完毕，不会执行其它；
  • 浏览器为了能够使得JS内部task与DOM任务能够有序的执行，会在一个task执行结束后，在下一个 task 执行开始前，对页面进行重新渲染；

（`task->渲染->task->...`）

• microtask（又称为微任务），可以理解是在当前 task 执行结束后立即执行的任务；

  • 也就是说，在当前task任务后，下一个task之前，在渲染之前；
  • 所以它的响应速度相比setTimeout（setTimeout是task）会更快，因为无需等渲染；
  • 也就是说，在某一个macrotask执行完后，就会将在它执行期间产生的所有microtask都执行完毕（在渲染前）；

宏任务类型：主代码块，setTimeout，setInterval等。

微任务类型：Promise，process.nextTick等。

7、async  defer脚本加载

普通script加载&执行：文档解析的过程中，如果遇到script脚本，就会停止页面的解析进行下载。其中蓝色为DOM解析，绿色为DOMContentLoaded；

！！！async：不会按着script在页面中的顺序来执行，而是谁先加载完谁执行。DOMContentLoaded事件的触发并不受async脚本加载的影响，在脚本加载完之前，就已经触发了DOMContentLoaded。

async脚本会在加载完毕后执行。async脚本的加载不计入DOMContentLoaded事件统计，也就是说下图两种情况都是有可能发生的：

！！！defer：浏览器会异步的下载该文件并且不会影响到后续DOM的渲染；如果有多个设置了defer的script标签存在，则会按照顺序执行所有的script；defer脚本会在文档渲染完毕后，DOMContentLoaded事件调用前执行。

文档解析时，遇到设置了defer的脚本，就会在后台进行下载，但是并不会阻止文档的渲染，当页面解析&渲染完毕后。会等到所有的defer脚本加载完毕并按照顺序执行，执行完毕后会触发DOMContentLoaded事件。

8、ready与onload

下载的资源：包含html，css，js文件，用于构建页面，时间与服务器性能，网络质量有关；

DOMContentLoaded：表示DOM生成完，解析完HTML文件，时间与HTML中js位置，HTML文件复杂度有关；

Load：表示加载完成，包含图片，字体，视频等资源，世间与资源大小有关。

渲染完毕后会触发load事件，load事件与DOMContentLoaded事件的先后顺序：DOMContentLoaded -> load

• 当 DOMContentLoaded 事件触发时，仅当DOM加载完成，不包括样式表，图片。(譬如如果有async加载的脚本就不一定完成)
• 当 onload 事件触发时，页面上所有的DOM，样式表，脚本，图片都已经加载完成了。（渲染完毕了）

DOMContentLoaded与Load的时间节点分别对应ready事件与onload事件。

！！！对于执行顺序来说：ready在DOMContentLoaded完成后触发；onload在Load完成后触发。

！！！对于执行次数来说：ready函数有几个会执行几个，不会冲突与覆盖；onload函数，后面的会覆盖前面的，也就是只会执行最后的onload函数一次。

参考：

https://www.cnblogs.com/jiasm/p/7683930.html

【Web】html中的async，defer；ready，onload的作用与区别 - 知乎

你真的了解回流和重绘吗 - 掘金