​
我有一个同门认为SVG里元素的改变不会触发重排，但是我觉得会，所以这篇文章需要被扩展一下，想要深入讨论一下这个问题。

一、什么是重绘和重排？

1.1 浏览器渲染的过程

1. 根据html文件构建DOM树和CSSOM树。构建DOM树期间，如果遇到JS，阻塞DOM树及CSSOM树的构建，优先加载JS文件，加载完毕，再继续构建DOM树及CSSOM树。
2. 构建渲染树（render Tree）。
3. 页面的重绘（repaint）与重排/回流（webkit引擎—Safari称作reflow，Blink引擎—Chrome称作layout）。页面渲染完成后，若JS操作了DOM节点，根据JS对DOM操作动作的大小，浏览器对页面进行重绘或是重排。

重绘：某些元素的外观被改变，例如：元素的填充颜色。
重排：重新生成布局，重新排列元素。当DOM的变化影响了元素的几何信息(元素的的位置和尺寸大小)，浏览器需要重新计算元素的几何属性，将其安放在界面中的正确位置，这个过程叫做重排。

1.2 减少重排的传统方法

1. 样式集中改变
2. 批量修改DOM元素
3. 离线DOM元素，display:none
4. 使用 absolute 或 fixed 脱离文档流

虽然修改元素的几何属性会导致浏览器触发重排或重绘时。但现代浏览器优化了这个过程，它会把这些操作放进渲染队列，等到队列中的操作到了一定的数量或者到了一定的时间间隔时，浏览器就会批量执行（flush）这些操作。

但有些操作会引起浏览器提前flush队列，比如，当我们向浏览器请求以下style信息时，就会提前让浏览器flush队列：

• offsetTop,offsetLeft,offsetWidth,offsetHeight
• scrollTop/Left/Width/Height
• clientTop/Left/Width/Height
• width,height
• 请求了getComputedStyle()或者IE的currentStyle

原因：
请求以上这些值时，浏览器需要清空队列，计算出最新的元素尺寸和位置样式信息（重绘回流），因为浏览器认为队列中的某些操作会造成我们获取的值并不是最精确的！

1.3 减少重排的现代方法

1.3.1 Document.Fragment

在使用JavaScript来操作DOM元素时，比如使用appendChild()方法。每次调用该方法时，浏览器都会重新渲染页面。如果大量的更新DOM节点，则会非常消耗性能，影响用户体验。
JavaScript提供了一个文档片段DocumentFragment的机制。如果将文档中的节点添加到文档片段中，就会从文档树中移除该节点。把所有要构造的节点都放在文档片段中执行，这样可以不影响文档树，也就不会造成页面渲染。当节点都构造完成后，再将文档片段对象添加到页面中，这时所有的节点都会一次性渲染出来，这样就能减少浏览器负担，提高页面渲染速度。(实际上还是一种批量修改DOM的方法）

1.3.2 requestAnimationFrame

网页的动画效果主要有两种实现方式：

1. CSS3动画
   – CSS是关键帧动画，补间动画部分由浏览器完成，便于浏览器进行优化，可以更好控制动画执行过程
   – CSS的动画执行在合成线程，专事专干，不阻塞主线程，合成线程的动画也不会触发回流和重绘
   – CSS动画允许在GPU，专注渲染，更快（复合图层的概念，后面会提到）
2. JS动画
   – JS是逐帧动画，每一帧都是由代码控制，操作不当，极易引发回流
   – JS的动画执行在主线程，主线程还有其他任务要执行，容易引发阻塞和等待，降低动画执行效率
   – JS动画运行在CPU，但CPU还有其他任务，易受影响

既然JS动画看上去这么拉，为什么要使用JS动画？因为可以通过编程实现复杂的动画效果。通常会使用setTimeout或者setInterval，以及requestAnimationFrame。

然而相比于setTimeout和setInterval而言，requestAnimationFrame有两个优点：

1. requestAnimationFrame 会把每一帧中的所有DOM操作集中起来，在一次重绘或回流中就完成，并且重绘或回流的时间间隔紧紧跟随浏览器的刷新频率，一般来说，这个频率为每秒60帧。
2. 在隐藏或不可见的元素中，requestAnimationFrame将不会进行重绘或回流，这当然就意味着更少的的CPU、GPU和内存使用量。

二、Canvas会触发重绘和重排吗？

除非Canvas本身的位置或者大小发生变化，影响了render tree，才会发生重排和回流。

理由是：重绘和回流都是相对于render tree上的元素而言的，而对canvas本身进行绘制并未对页面任何其他元素做更改，故只会引起Canvas画布本身的重绘。

credit to.

html canvas 改变,html5 –
每当有任何变化时,Canvas会重绘自己吗？
Canvas vs HTML DOM?
操作canvas 会不会导致页面reflow？

三、SVG会触发重绘和重排吗？

首先说结论：我现在觉得SVG其实并不会触发重排，因为SVG内存在一个坐标系，所有的SVG内的元素在SVG画布上是绝对定位的（除<g>内的子元素是相对于<g>定位的，aka相对定位）。仅仅更新SVG内部的元素，只会相对于SVG（root），对其所有子元素进行布局的计算，不能称作浏览器的重排。但SVG内的DOM元素还是还会在DOM树里，也会在Render树里，只不过针对文档流而言，不会有位置的改变，所以不会引起重排？
至于为什么当SVG内的元素多了之后，效率相比于Canvas会低很多：

1. Immediate Mode（即时模式）：Canvas没有DOM或文档对象模型。在使用Canvas绘制像素时，绘图指令执行了就不管了，减少了维护图形内部模型所需的额外内存。
2. Retained Mode（保留模式）：在使用SVG绘制图像的时候，绘制的每个对象都会添加到浏览器的内部模型中，使得性能降低。除此之外，SVG依旧依赖于Render树进行渲染，只不过不存在“重排”。

3.2 浏览器渲染时，产生图层

浏览器在渲染一个页面时，会将页面分为很多个图层，图层有大有小，每个图层上有一个或多个节点。在渲染DOM的时候，浏览器所做的工作实际上是：

1. 获取DOM后分割为多个图层
2. 对每个图层的节点计算样式结果 （recalculate style–样式重计算）
3. 为每个节点生成图形和位置 （layout–重排,回流）
4. 将每个节点绘制填充到图层位图中 （paint–重绘）
5. 图层作为纹理上传至GPU
6. 组合多个图层到页面上生成最终屏幕图像 （Composite Layers–图层重组）

产生图层的条件：

1. 拥有具有3D变换的CSS属性：transform:rotate(7deg); rotateX()、rotateY()、rotateZ()
2. 使用加速视频解码的节点
3. <canvas>节点
4. CSS3动画的节点
5. 拥有CSS加速属性的元素(will-change)
   ​
   https://www.cnblogs.com/lichuntian/p/8616107.html

credit to
浅谈浏览器的图层与重绘重排（详细），以及如何用于性能优化
层叠上下文 渲染图层 复合图层（硬件加速）区别与联系

四、如何减少SVG所带来的重绘和重排?

针对SVG的性能优化

https://www.w3.org/TR/SVG11/struct.html#Head

Canvas 最常见的用途是渲染动画。渲染动画的基本原理，无非是反复地擦除和重绘。为了动画的流畅，留给我渲染一帧的时间，只有短短的 16ms。在这 16ms 中，我不仅需要处理一些游戏逻辑，计算每个对象的位置、状态，还需要把它们都画出来。如果消耗的时间稍稍多了一些，用户就会感受到「卡顿」。所以，在编写动画（和游戏）的时候，我无时无刻不担忧着动画的性能，唯恐对某个 API 的调用过于频繁，导致渲染的耗时延长。

计算与渲染

把动画的一帧渲染出来，需要经过以下步骤：

1. 计算：处理游戏逻辑，计算每个对象的状态，不涉及 DOM 操作（当然也包含对 Canvas 上下文的操作）。
2. 渲染：真正把对象绘制出来。
   2.1. JavaScript 调用 DOM API（包括 Canvas API）以进行渲染。
   2.2. 浏览器（通常是另一个渲染线程）把渲染后的结果呈现在屏幕上的过程。

之前曾说过，留给我们渲染每一帧的时间只有 16ms。然而，其实我们所做的只是上述的步骤中的 1 和 2.1，而步骤 2.2 则是浏览器在另一个线程（至少几乎所有现代浏览器是这样的）里完成的。动画流畅的真实前提是，以上所有工作都在 16ms 中完成，所以 JavaScript 层面消耗的时间最好控制在 10ms 以内。

虽然我们知道，通常情况下，渲染比计算的开销大很多（3~4 个量级）。除非我们用到了一些时间复杂度很高的算法（这一点在本文最后一节讨论），计算环节的优化没有必要深究。

我们需要深入研究的，是如何优化渲染的性能。而优化渲染性能的总体思路很简单，归纳为以下几点：

1. 在每一帧中，尽可能减少调用渲染相关 API 的次数（通常是以计算的复杂化为代价的）。
2. 在每一帧中，尽可能调用那些渲染开销较低的 API。
3. 在每一帧中，尽可能以「导致渲染开销较低」的方式调用渲染相关 API。

Canvas 上下文是状态机

Canvas API 都在其上下文对象 context 上调用。

var context = canvasElement.getContext('2d');

我们需要知道的第一件事就是，context 是一个状态机。你可以改变 context 的若干状态，而几乎所有的渲染操作，最终的效果与 context 本身的状态有关系。比如，调用 strokeRect 绘制的矩形边框，边框宽度取决于 context 的状态 lineWidth，而后者是之前设置的。

context.lineWidth = 5;
context.strokeColor = 'rgba(1, 0.5, 0.5, 1)';

context.strokeRect(100, 100, 80, 80);

说到这里，和性能貌似还扯不上什么关系。那我现在就要告诉你，对 context.lineWidth 赋值的开销远远大于对一个普通对象赋值的开销，你会作如何感想。

当然，这很容易理解。Canvas 上下文不是一个普通的对象，当你调用了 context.lineWidth = 5 时，浏览器会需要立刻地做一些事情，这样你下次调用诸如 stroke 或 strokeRect 等 API 时，画出来的线就正好是 5 个像素宽了（不难想象，这也是一种优化，否则，这些事情就要等到下次 stroke 之前做，更加会影响性能）。

我尝试执行以下赋值操作 106 次，得到的结果是：对一个普通对象的属性赋值只消耗了 3ms，而对 context 的属性赋值则消耗了 40ms。值得注意的是，如果你赋的值是非法的，浏览器还需要一些额外时间来处理非法输入，正如第三/四种情形所示，消耗了 140ms 甚至更多。

somePlainObject.lineWidth = 5;  // 3ms (10^6 times)
context.lineWidth = 5;  // 40ms
context.lineWidth = 'Hello World!'; // 140ms
context.lineWidth = {}; // 600ms

对 context 而言，对不同属性的赋值开销也是不同的。lineWidth 只是开销较小的一类。下面整理了为 context 的一些其他的属性赋值的开销，如下所示。

与真正的绘制操作相比，改变 context 状态的开销已经算比较小了，毕竟我们还没有真正开始绘制操作。我们需要了解，改变 context 的属性并非是完全无代价的。我们可以通过适当地安排调用绘图 API 的顺序，降低 context 状态改变的频率。

分层 Canvas

分层 Canvas 在几乎任何动画区域较大，动画较复杂的情形下都是非常有必要的。分层 Canvas 能够大大降低完全不必要的渲染性能开销。分层渲染的思想被广泛用于图形相关的领域：从古老的皮影戏、套色印刷术，到现代电影/游戏工业，虚拟现实领域，等等。而分层 Canvas 只是分层渲染思想在 Canvas 动画上最最基本的应用而已。

分层 Canvas 的出发点是，动画中的每种元素（层），对渲染和动画的要求是不一样的。对很多游戏而言，主要角色变化的频率和幅度是很大的（他们通常都是走来走去，打打杀杀的），而背景变化的频率或幅度则相对较小（基本不变，或者缓慢变化，或者仅在某些时机变化）。很明显，我们需要很频繁地更新和重绘人物，但是对于背景，我们也许只需要绘制一次，也许只需要每隔 200ms 才重绘一次，绝对没有必要每 16ms 就重绘一次。

对于 Canvas 而言，能够在每层 Canvas 上保持不同的重绘频率已经是最大的好处了。然而，分层思想所解决的问题远不止如此。

使用上，分层 Canvas 也很简单。我们需要做的，仅仅是生成多个 Canvas 实例，把它们重叠放置，每个 Canvas 使用不同的 z-index 来定义堆叠的次序。然后仅在需要绘制该层的时候（也许是「永不」）进行重绘。

var contextBackground = canvasBackground.getContext('2d');
var contextForeground = canvasForeground.getContext('2d');

function render(){
  drawForeground(contextForeground);
  if(needUpdateBackground){
    drawBackground(contextBackground);
  }
  requestAnimationFrame(render);
}

记住，堆叠在上方的 Canvas 中的内容会覆盖住下方 Canvas 中的内容。

绘制图像

目前，Canvas 中使用到最多的 API，非 drawImage 莫属了。（当然也有例外，你如果要用 Canvas 写图表，自然是半句也不会用到了）。

drawImage 方法的格式如下所示：

context.drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight);

数据源与绘制的性能

由于我们具备「把图片中的某一部分绘制到 Canvas 上」的能力，所以很多时候，我们会把多个游戏对象放在一张图片里面，以减少请求数量。这通常被称为「精灵图」。然而，这实际上存在着一些潜在的性能问题。我发现，使用 drawImage 绘制同样大小的区域，数据源是一张和绘制区域尺寸相仿的图片的情形，比起数据源是一张较大图片（我们只是把数据扣下来了而已）的情形，前者的开销要小一些。可以认为，两者相差的开销正是「裁剪」这一个操作的开销。

我尝试绘制 104 次一块 320x180 的矩形区域，如果数据源是一张 320x180 的图片，花费了 40ms，而如果数据源是一张 800x800 图片中裁剪出来的 320x180 的区域，需要花费 70ms。

虽然看上去开销相差并不多，但是 drawImage 是最常用的 API 之一，我认为还是有必要进行优化的。优化的思路是，将「裁剪」这一步骤事先做好，保存起来，每一帧中仅绘制不裁剪。具体的，在「离屏绘制」一节中再详述。

视野之外的绘制

有时候，Canvas 只是游戏世界的一个「窗口」，如果我们在每一帧中，都把整个世界全部画出来，势必就会有很多东西画到 Canvas 外面去了，同样调用了绘制 API，但是并没有任何效果。我们知道，判断对象是否在 Canvas 中会有额外的计算开销（比如需要对游戏角色的全局模型矩阵求逆，以分解出对象的世界坐标，这并不是一笔特别廉价的开销），而且也会增加代码的复杂程度，所以关键是，是否值得。

我做了一个实验，绘制一张 320x180 的图片 104 次，当我每次都绘制在 Canvas 内部时，消耗了 40ms，而每次都绘制在 Canvas 外时，仅消耗了 8ms。大家可以掂量一下，考虑到计算的开销与绘制的开销相差 2~3 个数量级，我认为通过计算来过滤掉哪些画布外的对象，仍然是很有必要的。

离屏绘制

上一节提到，绘制同样的一块区域，如果数据源是尺寸相仿的一张图片，那么性能会比较好，而如果数据源是一张大图上的一部分，性能就会比较差，因为每一次绘制还包含了裁剪工作。也许，我们可以先把待绘制的区域裁剪好，保存起来，这样每次绘制时就能轻松很多。

drawImage 方法的第一个参数不仅可以接收 Image 对象，也可以接收另一个 Canvas 对象。而且，使用 Canvas 对象绘制的开销与使用 Image 对象的开销几乎完全一致。我们只需要实现将对象绘制在一个未插入页面的 Canvas 中，然后每一帧使用这个 Canvas 来绘制。

// 在离屏 canvas 上绘制
var canvasOffscreen = document.createElement('canvas');
canvasOffscreen.width = dw;
canvasOffscreen.height = dh;
canvasOffscreen.getContext('2d').drawImage(image, sx, sy, sw, sh, dx, dy, dw, dh);

// 在绘制每一帧的时候，绘制这个图形
context.drawImage(canvasOffscreen, x, y);

离屏绘制的好处远不止上述。有时候，游戏对象是多次调用 drawImage 绘制而成，或者根本不是图片，而是使用路径绘制出的矢量形状，那么离屏绘制还能帮你把这些操作简化为一次 drawImage 调用。

第一次看到 getImageData 和 putImageData 这一对 API，我有一种错觉，它们简直就是为了上面这个场景而设计的。前者可以将某个 Canvas 上的某一块区域保存为 ImageData 对象，后者可以将 ImageData 对象重新绘制到 Canvas 上面去。但实际上，putImageData 是一项开销极为巨大的操作，它根本就不适合在每一帧里面去调用。

避免「阻塞」

所谓「阻塞」，可以理解为不间断运行时间超过 16ms 的 JavaScript 代码，以及「导致浏览器花费超过 16ms 时间进行处理」的 JavaScript 代码。即使在没有什么动画的页面里，阻塞也会被用户立刻察觉到：阻塞会使页面上的对象失去响应——按钮按不下去，链接点不开，甚至标签页都无法关闭了。而在包含较多 JavaScript 动画的页面里，阻塞会使动画停止一段时间，直到阻塞恢复后才继续执行。如果经常出现「小型」的阻塞（比如上述提及的这些优化没有做好，渲染一帧的时间超过 16ms），那么就会出现「丢帧」的情况，

CSS3 动画（transition 与 animate）不会受 JavaScript 阻塞的影响，但不是本文讨论的重点。

偶尔的且较小的阻塞是可以接收的，频繁或较大的阻塞是不可以接受的。也就是说，我们需要解决两种阻塞：

• 频繁（通常较小）的阻塞。其原因主要是过高的渲染性能开销，在每一帧中做的事情太多。
• 较大（虽然偶尔发生）的阻塞。其原因主要是运行复杂算法、大规模的 DOM 操作等等。

对前者，我们应当仔细地优化代码，有时不得不降低动画的复杂（炫酷）程度，本文前几节中的优化方案，解决的就是这个问题。

而对于后者，主要有以下两种优化的策略。

• 使用 Web Worker，在另一个线程里进行计算。
• 将任务拆分为多个较小的任务，插在多帧中进行。

Web Worker 是好东西，性能很好，兼容性也不错。浏览器用另一个线程来运行 Worker 中的 JavaScript 代码，完全不会阻碍主线程的运行。动画（尤其是游戏）中难免会有一些时间复杂度比较高的算法，用 Web Worker 来运行再合适不过了。

然而，Web Worker 无法对 DOM 进行操作。所以，有些时候，我们也使用另一种策略来优化性能，那就是将任务拆分成多个较小的任务，依次插入每一帧中去完成。虽然这样做几乎肯定会使执行任务的总时间变长，但至少动画不会卡住了。

看下面这个 Demo，我们的动画是使一个红色的 div 向右移动。Demo 中是通过每一帧改变其 transform 属性完成的（Canvas 绘制操作也一样）。

然后，我创建了一个会阻塞浏览器的任务：获取 4x106 次 Math.random() 的平均值。点击按钮，这个任务就会被执行，其结果也会打印在屏幕上。

如你所见，如果直接执行这个任务，动画会明显地「卡」一下。而使用 Web Worker 或将任务拆分，则不会卡。

以上两种优化策略，有一个相同的前提，即任务是异步的。也就是说，当你决定开始执行一项任务的时候，你并不需要立刻（在下一帧）知道结果。比如，即使战略游戏中用户的某个操作触发了寻路算法，你完全可以等待几帧（用户完全感知不到）再开始移动游戏角色。
另外，将任务拆分以优化性能，会带来显著的代码复杂度的增加，以及额外的开销。有时候，我觉得也许可以考虑优先砍一砍需求。

小结

正文就到这里，最后我们来稍微总结一下，在大部分情况下，需要遵循的「最佳实践」。

1. 1. 将渲染阶段的开销转嫁到计算阶段之上。
   2. 使用多个分层的 Canvas 绘制复杂场景。
   3. 不要频繁设置绘图上下文的 font 属性。
   4. 不在动画中使用 putImageData 方法。
   5. 通过计算和判断，避免无谓的绘制操作。
   6. 将固定的内容预先绘制在离屏 Canvas 上以提高性能。
   7. 使用 Worker 和拆分任务的方法避免复杂算法阻塞动画运行。

一、什么是重排和重绘
要说清重排(reflow)和重绘(repaint)，首先要理解排列和绘制，浏览器渲染页面时，在获取完html、css资源之后，会大致经过以下步骤。
(1) html生成html树
(2) css形成css规则
(3) 两者形成一个渲染树
(4) 去文档当中找寻各自的布局位置----- 排列
(5) 将内容填充到文档上 ----- 绘制
【排列】就是计算位置调整布局的过程，而【绘制】就是把它画上去的过程。【重排】也就是除了最开始排列的布局，后续经过一些操作而使得dom元素重新找寻位置的过程，【重绘】就是重新绘制内容的过程。

二、什么情况会引发重排和重绘
1、先来说重排，重排和位置的移动布局的变化有关，主要有以下几种情况会引发重排
(1) 浏览器的窗口发生变化，每放大、缩小一次浏览器的窗口，该页面的所有元素都要进行重排重绘
(2) 增加、删除、移动dom元素，更改dom元素的宽高内外边距、内容，修改dom元素的样式
(3) 进行dom元素宽高等属性的查询，因为每查询一次，浏览器都会对所有的元素进行重新计算，以确保计算的值是正确的

2、再来说重绘，重绘主要是元素的外观发生变化，不会重新布局，有以下情况会引发重绘
元素的背景(background)、文字颜色(color)、边框样式(outline)发生变化

3、重排和重绘的关系
重绘不一定需要重排，因为可能只是元素修改文字颜色，不需要重新布局，重排大多数情况都需要重绘，因为重新排列元素之后要绘制到屏幕上。

以下显示重排和重绘的耗时，方块两秒之后右移了100px

三、为什么要优化

因为重排和重绘不只是对单个的dom元素进行操作，而是对整个【图层】进行操作，需要花费时间，如果频率高，非常的影响性能。

那什么是图层？如下图所示

因为每一次的重排重绘都是操作整个图层，那么我们可以将需要频繁操作的dom元素另外建立一个图层，这样可以尽可能少的触发重排重绘。

那么什么情况可以开启图层？
针对频繁操作的行为，chrome浏览器自动开启了图层，主要有以下几种情况
1、css 3D变化的图形 ---- transform: translateX(0)
2、html5中的<video>标签
3、canvas绘图中的节点
4、css 动画的节点 --- keyframes animation
5、拥有css加速属性 --- will-change: transform

除此之外，还可以使用以下方式进行优化
1、对元素进行移动时，使用transform替代对元素top、left、right的操作，因为css3的整个操作是对图层的组合来实现的，所以不会引发重绘重排。

#node{
  // position: relative; 
  transform: translateX(0);
  width: 100px;
  height: 100px;
  background: pink;
}
var node = document.querySelector("#node");
setTimeout(function(){
    //   node.style.left="100px";
   node.style.transform="translateX(100px)";
},2000);

同样是对一个元素两秒后移动100px，可以看到对比下图对比

2、将多次对样式的操作合并成一次
不要一次一次的修改样式，而是预先定义好class，直接修改DOM的className，这样只会引发一次重排重绘
3、将dom离线后修改
如果要对dom元素进行多次操作，首先将dom设置为不可见，然后再对dom操作，操作完成后再将dom元素设置为可见，这样只会有两次重排重绘
4、利用文档碎片 documentFragment
documentFragment 不是真实 dom树的一部分，它的变化不会触发dom树的重新渲染，且不会导致性能等问题，将创建的新元素全部添加到documentFragment上，最后让documentFragment一起插入到dom元素中

const list = ['哈尔的移动城堡', '千与千寻的神隐', '起风了']
const ul = document.getElementsByTagName("ul")[0]
let fragment = document.createDocumentFragment()
for(let i in list){
    fragment.appendChild(list[i])
}
ul.appendChild(fragment)