渲染机制

97 阅读4分钟

浏览器的渲染机制一般分为以下几个步骤

处理 HTML 并构建 DOM 树。

处理 CSS 构建 CSSOM 树。

将 DOM 与 CSSOM 合并成一个渲染树。

根据渲染树来布局,计算每个节点的位置。

调用 GPU 绘制,合成图层,显示在屏幕上

在构建 CSSOM 树时,会阻塞渲染,直至 CSSOM 树构建完成。并且构建 CSSOM
树是一个十分消耗性能的过程,所以应该尽量保证层级扁平,减少过度层叠,
越是具体的 CSS 选择器,执行速度越慢

当 HTML 解析到 script 标签时,会暂停构建 DOM,完成后才会从暂停的地方
重新开始。也就是说,如果你想首屏渲染的越快,就越不应该在首屏就加载 JS 
文件。并且 CSS 也会影响 JS 的执行,只有当解析完样式表才会执行 JS,所以
也可以认为这种情况下,CSS 也会暂停构建 DOM

图层

一般来说,可以把普通文档流看成一个图层。特定的属性可以生成一个新的图层。不同的图层渲染互不影响,所以对于某些频繁需要渲染的建议单独生成一个新图层,提高性能。但也不能生成过多的图层,会引起反作用

通过以下几个常用属性可以生成新图层

3D 变换:translate3d、translateZ
will-change
videoiframe 标签
通过动画实现的 opacity 动画转换
position: fixed

重绘(Repaint)和回流(Reflow)

重绘是当节点需要更改外观而不会影响布局的,比如改变 color 就叫称为重绘

回流是布局或者几何属性需要改变就称为回流

回流必定会发生重绘,重绘不一定会引发回流。回流所需的成本比重绘高的多,改变深层次的节点很可能导致父节点的一系列回流

所以以下几个动作可能会导致性能问题:

改变 window 大小
改变字体
添加或删除样式
文字改变
定位或者浮动
盒模型

很多人不知道的是,重绘和回流其实和 Event loop 有关

当 Event loop 执行完 Microtasks 后,会判断 document 是否需要更新。
因为浏览器是 60Hz 的刷新率,每 16ms 才会更新一次。

然后判断是否有 resize 或者 scroll ,有的话会去触发事件,所以 resize 和
scroll 事件也是至少 16ms 才会触发一次,并且自带节流功能。

判断是否触发了 media query

更新动画并且发送事件

判断是否有全屏操作事件

执行 requestAnimationFrame 回调

执行 IntersectionObserver 回调,该方法用于判断元素是否可见,可以用于
懒加载上,但是兼容性不好

更新界面

以上就是一帧中可能会做的事情。如果在一帧中有空闲时间,就会去执行 
requestIdleCallback 回调

减少重绘和回流

使用 translate 替代 top

使用 visibility 替换 display: none ,因为前者只会引起重绘,后者
会引发回流(改变了布局)

不要使用 table 布局,可能很小的一个小改动会造成整个 table 的重新布局

动画实现的速度的选择,动画速度越快,回流次数越多,也可以选择使用 
requestAnimationFrame

CSS 选择符从右往左匹配查找,避免 DOM 深度过深

将频繁运行的动画变为图层,图层能够阻止该节点回流影响别的元素。比如对于 
video 标签,浏览器会自动将该节点变为图层

解释:

IntersectionObserver:

www.ruanyifeng.com/blog/2016/1…

requestAnimationFrame:

告诉浏览器——你希望执行一个动画,并且要求浏览器在下次重绘之前调用指定的
回调函数更新动画。该方法需要传入一个回调函数作为参数,该回调函数会在
浏览器下一次重绘之前执行

注意:若你想在浏览器下次重绘之前继续更新下一帧动画,那么回调函数自身
必须再次调用window.requestAnimationFrame()

requestIdleCallback

developer.mozilla.org/zh-CN/docs/…