前端性能优化：深入理解回流与重绘

大家好，我是你们的老朋友FogLetter，今天我们来聊一个前端性能优化中绕不开的话题------回流与重绘。这个话题看似基础，但真正理解它却能让你写出性能更好的代码，避免很多莫名其妙的性能问题。

从表格布局说起：为什么我们不再用table布局？

让我们从一个有趣的历史故事开始。在CSS还不那么强大的年代，前端开发者们常常使用<table>标签来实现页面布局。就像下面这样：

<table>
  <tr>
    <td class="sidebar">左侧边栏</td>
    <td class="main">主侧内容</td>
    <td class="sidebar">右侧边栏</td>
  </tr>
</table>

这种布局方式看起来简单直观，为什么我们现在不再推荐使用呢？原因有三：

1. 语义化问题 ：<table>本意是用来展示表格数据的，用它来做布局就像用勺子吃牛排------能用，但不合适。

2. 灵活性差：表格布局结构固定，难以适应现代响应式设计的需求。

3. 性能问题：这是今天要重点讨论的------表格布局会触发大量的回流(reflow)和重绘(repaint)。

理解渲染流程：从URL到像素

要理解回流和重绘，我们需要先了解浏览器是如何渲染页面的：

1. 构建DOM树：浏览器解析HTML，构建DOM（文档对象模型）树。

2. 构建CSSOM树：解析CSS，构建CSSOM（CSS对象模型）树。

3. 构建Render树：合并DOM和CSSOM形成渲染树(Render Tree)。

4. 布局(Layout)：计算每个元素在屏幕上的确切位置和大小（这就是回流发生的阶段）。

5. 绘制(Paint)：将渲染树转换为屏幕上的实际像素（这是重绘发生的阶段）。

6. 合成(Composite)：将不同图层合并显示在屏幕上。

这个过程就像建造一栋房子：DOM和CSSOM是设计图纸，Layout是确定每个房间的位置和大小，Paint是实际装修，Composite是把所有房间组合成一栋完整的房子。

回流(Reflow)：布局的重新计算

回流，也叫重排，是指浏览器需要重新计算元素在文档中的几何属性（位置和大小），导致部分或全部渲染树需要重新构建的过程。

什么会触发回流？

1. 页面首次渲染（最耗性能的一次）
2. 浏览器窗口大小改变
3. 元素尺寸或位置改变（注意：transform/opacity等属性创建新图层，不会触发回流）
4. 元素内容变化（如文本改变、添加/删除DOM节点）
5. 显示/隐藏元素 （如display: none会触发回流）
6. 字体大小改变
7. 激活CSS伪类（如:hover）
8. 读取某些属性或调用方法 （如offsetWidth、getComputedStyle()）

表格布局为什么会导致性能问题？

在表格布局中，即使只修改一个单元格的内容，浏览器也可能需要重新计算整个表格的布局。就像多米诺骨牌一样，一个小的改动可能导致连锁反应，这就是为什么表格布局在现代前端开发中被淘汰的原因。

重绘(Repaint)：样式的重新绘制

重绘发生在元素的样式改变但不影响其在文档流中的位置时。比如改变颜色、背景色、visibility等属性。

<div class="box vis_hid">123</div>  <!-- visibility: hidden -->
<div class="box dis_none">456</div> <!-- display: none -->

这里有个有趣的对比：

• visibility: hidden：元素仍占据空间，只是不可见（触发重绘）
• display: none：元素完全不渲染（触发回流，因为它从渲染树中移除了）

现代布局方案：Flex和Grid

现代CSS布局方案如Flexbox和Grid不仅更灵活，而且在性能上也更优，因为它们的设计考虑到了回流的问题：

.container {
  display: flex; /* 创建FFC（弹性格式化上下文） */
}

总结：性能优化的艺术

理解回流和重绘是前端性能优化的基础。记住以下原则：

1. 回流比重绘更昂贵：尽量减少回流次数
2. 读写分离：避免频繁的读写DOM样式
3. 合理使用现代布局：Flex/Grid优于浮动和定位
4. 善用图层：transform/opacity等属性可以创建新图层

性能优化是一门平衡的艺术，不是所有的优化都值得做。关键是要找到真正影响用户体验的瓶颈，有针对性地进行优化。

希望这篇文章能帮助你更好地理解回流和重绘的机制，写出更高效的代码。如果你有更多问题或想分享你的优化经验，欢迎在评论区留言讨论！