移动 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像素让动画的帧变得迟钝一些，也不要让页面的性能降下来。
长按上图，关注猿猿相抱
本篇作者：常鸣