JS中DOM、Canvas与SVG绘制黑白棋盘格的性能对比

在 JavaScript 中绘制黑白棋盘格时，DOM、SVG 与 Canvas 的性能表现存在本质差异。在几十到几百格的小规模场景下，三者渲染耗时均在数毫秒内，肉眼完全不可感知；但当格子数量攀升至数千乃至数万时，Canvas 展现出压倒性的吞吐优势，其初始化耗时与内存增长几乎保持微弱平稳，而 DOM 与 SVG 会因为海量节点对象与场景树的维护，导致耗时指数级增加、内存剧烈膨胀甚至引发页面卡死。本文通过严谨的基准测试、原理剖析与量化数据，帮助开发者准确理解各方案的性能瓶颈并做出技术选型。

缩略图：DOM、Canvas 与 SVG 绘制棋盘格的底层图元架构与特性概览

一、棋盘格渲染问题的技术背景与对比维度

黑白棋盘格是前端图形与排版渲染中的经典基准测试用例。其特征非常清晰：由 $N \times N$ 个尺寸相等、黑白两色交替排列的正方形图元平铺填充一个固定大小的容器。

在现代 Web 技术中，实现该功能主要有三条路径：

• DOM 方案：在容器中插入 $N^2$ 个 <div> 标签，利用 CSS Grid、Flexbox 或绝对定位配合背景颜色实现棋盘。
• Canvas 方案：创建一个单一的 <canvas> 容器，使用 Canvas 2D 上下文在循环中调用 fillRect() 往像素位图直接写入色块。
• SVG 方案：创建一个 <svg> 根节点，在命名空间下创建 $N^2$ 个 <rect> 矢量矩形元素追加到场景树中。

在对比这三者时，核心的关注维度包括：

1. 初始创建与挂载耗时（Scripting & Mounting）：JS 执行创建操作到元素就绪的时间。
2. 排版与渲染管线开销（Layout & Rasterization）：浏览器从计算图元几何坐标到最终把像素提交给 GPU 显示的总耗时。
3. 内存占用（JS Heap & DOM Memory）：对象树及渲染表面在内存中所占的物理开销。
4. 动态缩放与交互成本：当视口缩放或需要检测鼠标悬浮/点击时所需的额外计算代价。

二、基准性能测试流程与实验环境

为了保证对比的公平性与科学性，测试必须排查外部干扰，消除网络延迟与偶发垃圾回收（Garbage Collection）带来的影响。测试应在固定的宿主容器尺寸（例如 800px × 800px）下进行，依次递增网格阶梯：$10 \times 10$（100格）、$50 \times 50$（2,500格）、$100 \times 100$（10,000格）以及 $200 \times 200$（40,000格）。

图 1：黑白棋盘格性能基准测试与指标采集流水线

三、核心实现代码与测试用例

在对比性能之前，必须保证三种实现均采用了各自技术体系内的标准优化写法，避免低级代码失误导致不公平的偏差。

1. DOM 批量渲染实现

在 DOM 方案中，若直接在循环内部调用 parent.appendChild()，会触发巨量的多次重排。必须使用 DocumentFragment 在内存中组装完毕后一次性挂载，或者使用绝对定位配合一次性 innerHTML 生成字符串。这里采用最高效的原生 DocumentFragment 节点创建法：

function renderCheckerboardDOM(container, n, size) {
  container.innerHTML = '';
  const fragment = document.createDocumentFragment();
  const cellSize = size / n;

  for (let r = 0; r < n; r++) {
    for (let c = 0; c < n; c++) {
      const cell = document.createElement('div');
      cell.style.position = 'absolute';
      cell.style.width = `${cellSize}px`;
      cell.style.height = `${cellSize}px`;
      cell.style.left = `${c * cellSize}px`;
      cell.style.top = `${r * cellSize}px`;
      cell.style.backgroundColor = (r + c) % 2 === 0 ? '#FFFFFF' : '#000000';
      fragment.appendChild(cell);
    }
  }
  container.appendChild(fragment);
}

2. Canvas 2D 即时渲染实现

Canvas 方案只需要一个画布节点，JS 在循环中通过 2D 上下文连续绘制矩形。为了提高性能，通常一次性绘制所有黑色方块，跳过白色方块以减少一半的 fillRect 指令调用：

function renderCheckerboardCanvas(canvas, n, size) {
  canvas.width = size;
  canvas.height = size;
  const ctx = canvas.getContext('2d');
  const cellSize = size / n;

  // 1. 底色铺白
  ctx.fillStyle = '#FFFFFF';
  ctx.fillRect(0, 0, size, size);

  // 2. 批量填充黑色块
  ctx.fillStyle = '#000000';
  for (let r = 0; r < n; r++) {
    for (let c = 0; c < n; c++) {
      if ((r + c) % 2 !== 0) {
        ctx.fillRect(c * cellSize, r * cellSize, cellSize, cellSize);
      }
    }
  }
}

3. SVG 矢量场景树实现

SVG 属于保留模式矢量图，需要严格调用 document.createElementNS 创建命名空间下的 <rect> 元素。为了避免重复挂载，同样先将所有子元素在内存中集中处理或直接拼装为结构化字符串后挂载到 <svg>：

function renderCheckerboardSVG(container, n, size) {
  const cellSize = size / n;
  let rects = '';
  
  for (let r = 0; r < n; r++) {
    for (let c = 0; c < n; c++) {
      const fill = (r + c) % 2 === 0 ? '#FFFFFF' : '#000000';
      const x = c * cellSize;
      const y = r * cellSize;
      rects += `<rect x="${x}" y="${y}" width="${cellSize}" height="${cellSize}" fill="${fill}" />`;
    }
  }

  container.innerHTML = `
    <svg xmlns="http://www.w3.org/2000/svg" width="${size}" height="${size}" viewBox="0 0 ${size} ${size}">
      ${rects}
    </svg>
  `;
}

四、底层渲染管线与内存模型深度剖析

理解三者性能差异的根源，必须深入浏览器的内部渲染管道与底层对象模型。关键的区别在于保留模式（Retained Mode）与即时模式（Immediate Mode）的运作机制。

图 2：DOM/SVG 与 Canvas 的底层渲染模型与内存机制差异

从架构上看：

• DOM 的“节点税”：每一个 <div> 在 Chrome 的 Blink 引擎中都是一个完整的 HTMLDivElement C++ 实例。它附带样式计算缓存、事件监听器链表、盒子模型几何属性及层叠上下文信息。在 40,000 格的场景下，仅节点本身的分配就会耗去 60MB~100MB 堆内存，样式计算与布局树（Layout Tree）构建开销巨大。
• SVG 的轻量保留模式：虽然 <rect> 比普通的 <div> 略轻，免去了部分复杂的通用盒模型计算，但它依然是标准 DOM 节点，每个图元都作为场景树的一部分存留在内存中，浏览器依然需要维护它的几何属性和层级拓扑。
• Canvas 的“画后即忘”：Canvas 属于即时渲染模式。一旦 ctx.fillRect 将色块写入画布底层的像素缓冲区，具体的“矩形”概念便不复存在，JavaScript 引擎和渲染引擎无需保留任何矩形对象。整块画布在内存中仅仅是一块大小恒定的 RGBA 像素矩阵（$800 \times 800 \times 4 \text{ bytes} \approx 2.56\text{MB}$），哪怕格子数量从 100 增加到 100,000，内存几乎保持恒定不变。

五、多规模指标实测数据对比

在配备标准主流硬件的现代浏览器（Chrome V8 引擎）环境下，执行上述三组代码测试。我们统计首次完整上屏时间（包括 JS 循环、挂载与 Layout/Paint）以及JS 堆内存增量（Heap Used）。

图 3：不同技术路线在各规模等级下的首屏耗时增长曲线对比

六、动态缩放、重绘与交互特性的性能差异

在实际应用场景中，棋盘格往往不仅仅是一张静态图片，还涉及到放大缩小、平移拖拽或单元格悬浮变色等动态交互。三者在这一环节的性能表现发生反转：

• CSS 视口缩放（Transform / Zoom）：
  • SVG：表现最优。由于具备原生矢量特性，当对 <svg> 容器应用 CSS Transform 缩放或修改 viewBox 时，浏览器无需重新在 JS 中重新计算坐标，矢量栅格化硬件加速保证画面永不模糊且丝滑流畅。
  • Canvas：如果仅缩放 canvas 元素尺寸，会导致像素位图被插值放大而模糊失真；若为了清晰度在 JS 内部按设备像素比（DPR）重新 fillRect 重绘，虽然重绘极快，但需要手动编写矩阵换算逻辑。
  • DOM：应用 CSS 缩放同样清晰，但如果频繁触发改变元素大小属性（如修改 width/height 而非 transform），会导致成千上万个子节点连续发生回流。
• 单元格点击与悬停交互（Event Delegation）：
  • DOM / SVG：天然支持给每个格子挂载事件，或利用事件冒泡机制通过单个父容器监听 e.target，轻松取得当前点击的行和列。
  • Canvas：不保留任何子元素，无法直接监听单个格子事件。必须通过监听画布上的鼠标坐标 offsetX 与 offsetY，通过数学算式 Math.floor(x / cellSize) 逆向推导被点击的行与列。若要实现悬停变色，需要重绘脏矩形区域或整块画布。

七、技术选型决策依据与总结

在明确了各方案在静态渲染和动态交互上的边界后，开发者可依据以下决策图谱来选择最匹配业务需求的技术实现：

图 4：棋盘格技术选型与业务场景匹配决策模型

综上所述，三者不存在绝对的优劣，而是取决于具体的业务约束：

1. 对于常规的 8×8 国际象棋、五子棋或围棋（19×19，361格），DOM 方案开发成本最低，且能够直接享受 CSS 的伪类、动画效果和事件冒泡机制，性能完全满足 60FPS 要求；
2. 对于需要高保真打印、矢量图表导出或任意比例平滑缩放的棋盘背景，格数在数百到一两千之间时，SVG 是兼具矢量精度与节点控制力的平衡解；
3. 对于热力图、大型数据网格、生命游戏模拟或几万格以上的高密度网格，Canvas 是唯一具备实用价值的方案。其通过即时模式绕过浏览器的 DOM 对象体系与重排管线，以极低的系统资源实现了最高性能的图元绘制。