canvas和svg的性能对比

约 1411 字大约 5 分钟

2025-10-17

简单来说，Canvas 性能优于 SVG 的核心原因在于它们不同的渲染模型。

我们可以用一个生动的比喻来理解：

SVG 像是一个用 Word 文档画的矢量图。图中的每个元素（圆形、矩形、路径）都是文档中的一个独立对象。你可以随时选中其中一个圆，修改它的颜色、大小，而不会影响其他元素。浏览器需要维护所有这些对象的详细信息。
Canvas 像是一块画布，你用画笔在上面作画。你画上去的每一笔都变成了画布的一部分，浏览器不再记得你画的是一个“圆”还是一个“矩形”，它只看到最终生成的像素点阵图。

下面我们从技术层面详细拆解这个区别：

这是最根本的区别。

SVG采用保留模式
- 原理：SVG 是基于 XML 的，它在内存中构建并维护了一个文档对象模型。屏幕上的每个图形元素（如 <circle>, <path>）都是 DOM 树中的一个节点。
- 开销：当你移动一个 SVG 元素时，浏览器需要：
  1. 识别出对应的 DOM 节点。
  2. 计算新的样式和位置。
  3. 触发浏览器的重绘流程，重新合成整个图层。
- 后果：图形元素越多，DOM 树就越复杂，浏览器需要管理和计算的开销就越大。当发生大量、高频的动画或变化时，这个开销会迅速成为性能瓶颈。
Canvas采用立即模式
- 原理：Canvas 提供了一个二维绘图 API（通过 JavaScript）。你通过脚本命令（如 fillRect(), arc()）直接告诉浏览器“在某个坐标画什么”。命令执行完毕后，浏览器不会保留任何关于你所画图形的信息，它只保存了最终生成的像素位图。
- 开销：要移动一个图形，你必须：
  1. 清除整个画布或一部分。
  2. 重新绘制所有需要显示的图形（包括移动后的那个）。
- 后果：性能开销与你绘制的复杂度和频率直接相关，而与屏幕上“有多少个图形对象”无关。因为浏览器没有对象管理的负担，所以对于大量像素的操作可以非常高效。

SVG：作为 DOM 的一部分，SVG 元素可以方便地绑定事件（如 onclick, onmouseover），因为浏览器知道每个元素的边界和位置。但这同样是性能负担，因为事件监听器需要附加到成千上万个 DOM 节点上。
Canvas：Canvas 本身只是一个 DOM 节点（<canvas> 元素）。它只有一个总的事件监听器。如果你想知道用户点击了画布上的哪个“图形”，你必须手动计算鼠标坐标落在了哪个图形的数学范围内。这增加了编程复杂度，但换来了极低的 DOM 开销。

Canvas：现代浏览器对 Canvas 2D 进行了大量优化，尤其是在处理动画和大量重绘时。它能够更好地利用GPU进行光栅化（将矢量指令转换为像素），特别是当操作涉及图像、变换和合成时。因为 Canvas 输出的本质是一张位图，非常适合 GPU 处理。
SVG：SVG 的渲染同样可以被硬件加速，但其加速过程更复杂。因为浏览器需要先将 SVG 的 DOM 树解析并光栅化，这个过程涉及更多的 CPU 计算和布局计算。当 SVG 结构非常复杂时，GPU 的优势会被前期的 CPU 计算所抵消。

特性	Canvas	SVG
渲染模型	立即模式	保留模式
底层技术	JavaScript API + 像素位图	XML/DOM
内存管理	由开发者控制（需要手动重绘）	由浏览器自动管理（DOM 树）
事件处理	单一事件，需手动计算命中	原生支持每个图形元素的事件
可访问性	差（纯像素，需额外工作）	好（是 DOM 的一部分）
缩放能力	放大后会模糊（位图）	无限缩放不失真（矢量）
适合场景	大量数据点、像素操作、游戏、高性能动画	交互式地图、图标、数据图表（元素数量适中）、需要SEO和可访问性的静态或简单动画图形

选择 Canvas ：
- 你需要处理成千上万个图形对象（如粒子系统、复杂图表）。
- 你需要进行像素级操作（如图像滤镜、实时视频处理）。
- 你在开发游戏，需要高频重绘和流畅的动画。
- 你对性能有极致要求，且可以接受更复杂的事件处理逻辑。
选择 SVG ：
- 你处理的图形元素数量在几百个以内。
- 你需要图形中的每个元素都能独立响应事件。
- 你需要矢量图的无损缩放特性。
- 你希望图形能够被搜索引擎索引，或者需要良好的可访问性。
- 你的开发更倾向于声明式编程，并且希望利用 CSS 来设置样式和动画。

现代实践：在很多复杂的可视化项目中，可以采用混合模式，例如使用 Canvas 来渲染海量的、动态的数据背景，同时用 SVG 来绘制上层的、需要交互的标注和控件，从而兼顾性能与交互体验。