应该知道的前端性能二三事：Reflow 和 Repaint_html/css_WEB-ITnose

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

啥是 Reflow 和 Repaint

Repaint

Repaint 就是「重绘」，它会在你改变 DOM 元素的视觉效果时进行，改变布局时不会触发。比如， opacity , background-color , visibility 和 outline 等都会触发，「重绘」的开销还是比较昂贵的，因为浏览器会在某一个 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 的 offsetWidth 和 offsetHeight 属性同样会触发一下 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:absolute 或 position:fixed 的，这样会让他们脱离文档流，不去影响其他的元素。

善用 display:none

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

批量更新元素

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

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

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

DEMO

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

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

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

避免大量 DOM 互相影响

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

性能永远比酷炫重要

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

长按上图，关注猿猿相抱

本篇作者：常鸣