reflow（重排/回流）、repaint（重绘）及其优化

浏览器拿到HTML之后的渲染过程：

1. 生成DOM树；
2. 生成CSSOM树；
3. 生成render树；
4. 执行reflow（在render树的基础上计算页面真实显示dom的位置）；
5. 执行repaint（为真实显示的dom绘制不影响dom位置的样式，如设置dom的color等）。

reflow：

当页面发生的某些变化影响了布局，需要倒回去重新渲染，该过程称为reflow（重排/回流）。reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的reflow。只要这些变化引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们无法预估浏览器到底会reflow哪一部分的代码，它们彼此相互影响。

repaint：

如果页面的变化只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器repaint（重绘)。

简而言之，如果页面的变化会导致dom的位置(也就是结构)发生变化，则会触发reflow，如果不会导致dom的位置发生变化，则会触发repaint。如果触发了reflow则一定会触发repaint，而触发repaint则不一定会触发reflow。另外，reflow的成本比repaint高很多，dom树里每个结点的reflow都可能触发其子结点、祖先结点、兄弟结点的reflow。reflow过于频繁是导致页面性能下降的关键因素之一（也是页面性能优化的主要方向）。

---

要降低触发reflow的频率，首先要明确哪些情况会触发reflow，以下是会触发reflow的几种常见动作：

1. 改变窗囗大小；
2. 改变文字大小；
3. 内容的改变，如用户在输入框中输入信息；
4. 脚本操作dom；
   。。。。

reflow的部分常见优化：

1. 不要一条一条的修改dom的样式，最好通过设置class的方式。 避免重复触发reflow和repaint；

2. 经常reflow的元素，比如动画，position设为fixed或absolute，使其脱离文档流，不影响其它元素的布局；

3. 权衡速度的平滑。比如实现一个动画，以1px为单位移动这样最平滑，但reflow就会过于频繁，CPU很快就会被完全占用。如果以3个像素为单位移动就会好很多；

4. 不要用tables布局。tables中某个元素一旦触发reflow就会导致table里所有的其它元素reflow。在适合用table的场合，可以设置table-layout为auto或fixed，这样可以让table一行一行的渲染，这种做法也是为了限制reflow的影响范围；

5. 避免使用IE的css expression（每次都会重新计算）；