转载

应该知道的前端性能二三事:Reflow 和 Repaint

移动 Web 前端开发,目前是火的不能再火了。到处都在招什么 H5 工程师、Hybrid App 开发工程师,主要负责的其实就是一些移动 Web 前端开发的工作。稍微有过一些前端经验的人都知道,手机上的开销比 PC 上要大的多,你在 PC 的模拟器上调试的很顺畅,等到手机上时,就会卡,这是为什么呢?其实这就是性能问题,有其他的开销占用了你的计算资源啦,那么是哪些开销占用了呢?抛开后端接口慢啊、网络状态差啊什么的不说,咱们今天聊聊浏览器本身的细节,Reflow 和 Repaint。尤其是在添加一些 CSS3 动画或者批量操作多个 DOM 元素的时候,Reflow 和 Repaint 的影响就会更加大。

啥是 Reflow 和 Repaint

Repaint

Repaint 就是「重绘」,它会在你改变 DOM 元素的视觉效果时进行,改变布局时不会触发。比如, opacity , background-color , visibilityoutline 等都会触发,「重绘」的开销还是比较昂贵的,因为浏览器会在某一个 DOM 元素的视觉效果改变后去 check 这个 DOM 元素内的所有节点。

Reflow

Reflow 就是「回流」,它的影响更大。它会在某一个 DOM 元素的位置发生改变后触发,而且它会重新计算所有元素的位置和在页面中的占有的面积,这样的话将会引起页面某一个部分甚至整个页面的重新渲染。改变某一个元素会影响它所有的子节点 (children)、祖先节点 (ancestors) 及兄弟节点(siblings)。

Reflow 和 Repaint 都是浏览器慢的元凶

用户和Web页面都不能在 Reflow 和 Repaint 执行时做任何操作和响应,而且在极端的情况下,CSS 会拖慢 JS 的执行速度,这就是浏览器有的时候就是在操作之后没反应的原因之一。

什么时候 Reflow 会触发

Reflow 的开销更加昂贵,那么具体哪些时候会触发 Reflow?

  • 添加、删除或者改变 DOM 元素的可见性时:使用 JS 去改变 DOM 元素时会触发 Reflow。

  • 添加、删除或者改变 CSS 样式:直接改变 CSS Style 或者元素的 class 可能会影响布局,还有改变一个元素的宽度能够影响它所在的 DOM 节点中的所有元素,以及它周围的那些元素。

  • CSS3 动画(animation)和过渡(transition): 动画的每一 frame 都会触发 Reflow。

  • 使用 offsetWidth 和 offsetHeight:这一点很特别,你读一个 DOM 的 offsetWidthoffsetHeight 属性同样会触发一下 Reflow,因为这两个属性需要依赖一些元素去计算。

  • 用户交互:用户可以通过 hover 一下 a 链接,在 input 里面输入文字,拖动浏览器的大小,改变字体大小,更换样式表或者字体等都会触发 reflow。

一些常用的提高性能的原则

布局

不要用 inline style 或 table 布局, flexbox 布局也会给性能带来一些小困扰。 inline style 会在 html 下载完后进行一次额外的 Reflow,table布局的开销远比其他 DOM 元素的布局开销要大。 flexbox 的 item 会在 HTML 下载完成后改变尺寸。

简写 CSS

尽量简写 CSS,避免使用复杂的 CSS 选择器,使用 Unused CSS (https://unused-css.com/), uCSS (https://github.com/oyvindeh/ucss), gulp-uncss (https://github.com/ben-eb/gulp-uncss)可以有效的减少样式的定义和文件的大小。

优化 DOM

减少 DOM 的层级,减少 DOM 的数量,如果不需适配老浏览器,删掉一些无用的 wrapper 性质的 DOM 元素,总之越少越好。

慎改 class

在一个 DOM 树中,尽可能改那些没有特别多子元素 DOM 的 class,子元素少的可以改,多的不推荐。

避免复杂动画

删掉复杂的动画,运用动画的元素尽量是 position:absoluteposition:fixed 的,这样会让他们脱离文档流,不去影响其他的元素。

善用 display:none

display:none 的元素不会引发 Reflow 和 Repaint,可以在让这些元素在 display 之前进行一些诸如颜色、尺寸什么的改变。

批量更新元素

比如下面这个例子会触发3次 reflow:

应该知道的前端性能二三事:Reflow 和 Repaint

可以用这种方式来优化上面的代码:

应该知道的前端性能二三事:Reflow 和 Repaint 应该知道的前端性能二三事:Reflow 和 Repaint

此外,还可以在生成新 DOM 时可以使用 DOM fragment,然后先在内存中构建 DOM:

应该知道的前端性能二三事:Reflow 和 Repaint

DEMO

再给大家看一个例子,下面有两个性能比较图,第一张是批量在页面插入1000个div,仅仅是div噢,第二张是一个个在页面插入1000个 div。这两种的性能差距在最新版 chrome 下居然都长达 1秒 之多,1秒啊亲们,还是最新版 chrome 啊,所以咱们在写 JS 的时候,不要再排脑袋了,我展示的这个还仅仅是纯 div,没有任何复杂嵌套,如果在正式的场景中,这种性能问题会放大数倍不止,一旦出现对你的产品简直是要命的事儿,不说了,乃们感受下吧。

批量更新,耗时 34ms,从图中可以看出,reflow 和 paint 各执行一次

应该知道的前端性能二三事:Reflow 和 Repaint

分别更新,耗时 1118ms,从图中可以看出,一个叫 Parse HTML 的东西累积起来,使得总时间直接比批量上升了1000倍,这个 Parse HTML 实际上就是 Paint 和 Reflow 的结合体, Parse HTML 是 chrome 中的一个算法的名称。

应该知道的前端性能二三事:Reflow 和 Repaint

避免大量 DOM 互相影响

比如 Tabs 这种场景,如果你点击一个 Tab 会显示它控制的区块,显示的那个区块会影响其他的区块,这样可能会引起 Reflow,因为它们的高度不一样,可以通过定个高度来优化这种场景。

性能永远比酷炫重要

记住一个原则,你网页的动画再牛逼,性能还是第一位的,如果每一帧移动1个像素会造成你的页面卡顿,那宁愿每一帧移动10像素让动画的帧变得迟钝一些,也不要让页面的性能降下来。

应该知道的前端性能二三事:Reflow 和 Repaint

长按上图,关注猿猿相抱

本篇作者:常鸣

原文  https://mp.weixin.qq.com/s?__biz=MzI2NzExNTczMw==&mid=2653284861&idx=1&sn=9bf3b8b5dd3108cdb4cafea101432366
正文到此结束
Loading...