问题描述 #

我在测试Canvas绘制相同线条的耗时，理论上每次绘制的时间应该接近，但在Chrome中，每绘制43692条线就会出现一次比正常慢200000倍的延迟。Firefox中这个问题出现得更晚，但频率更高。我想知道：

• 浏览器是否会人为限制Canvas的绘制速度？用的是什么算法/规则？
• 还是垃圾回收器会在绘制一定数量的线条后确定性地触发？
  这对项目规划和基准测试非常重要——典型屏幕尺寸下的帧率会受此影响，很容易被基准测试误导。

复现代码 #

HTML

<div>
  <input id="input" type="number" value="200000">
  <button onclick="run()">Run</button>
</div>
<canvas id="canvas"></canvas>
<div>Number of operations as a function of time (should be diagonal, but instead has plateaus in Chrome):</div>
<canvas id="chart"></canvas>

CSS

#canvas {
  display: none;
}

JavaScript

const ctx = canvas.getContext('2d');
const chartCtx = chart.getContext('2d');

function run() {
  const n = +input.value;
  const times = [];
  
  // Repeatedly draw identical lines and time that
  const start = performance.now();
  for (let i = 0; i < n; i++) {
    ctx.beginPath();
    ctx.moveTo(0, 0);
    ctx.lineTo(100, 100);
    ctx.stroke();
    times.push(performance.now() - start);
  }
  
  // Draw chart: x = time, y = iteration count
  const maxTime = times[times.length - 1];
  chartCtx.clearRect(0, 0, chart.width, chart.height);
  chartCtx.beginPath();
  chartCtx.moveTo(0, chart.height);
  for (let i = 0; i < times.length; i++) {
    const x = (times[i] / maxTime) * chart.width;
    const y = chart.height - ((i + 1) / n) * chart.height;
    chartCtx.lineTo(x, y);
  }
  chartCtx.stroke();
}

run();

我的分析与解答 #

我太懂你这种在性能测试里撞见诡异周期性延迟的糟心了——这种情况直接坑基准测试结果，还能把项目的帧率预估全带偏，尤其是做Canvas可视化或者动画的时候，完全摸不准真实的性能底线。结合你的代码和现象，我来拆解下Chrome里出现这个问题的核心原因，以及对你的项目规划的影响：

一、核心原因：Skia渲染引擎的内部资源清理（而非V8垃圾回收）

你看到的每43692次绘制就出现大延迟，这个数字其实指向Chrome Canvas底层的Skia渲染引擎的内部阈值，而非V8的GC停顿：

• Chrome的2D Canvas是用Skia来处理所有绘制指令的，Skia会在内部维护路径缓存、渲染状态缓冲区、笔触合成队列这些临时资源。
• 你每次调用beginPath()+stroke()，都会在Skia里生成一个新的路径几何对象，并且加入到渲染队列中。当这些临时资源累积到某个固定阈值（刚好对应你看到的43692次操作），Skia会触发一次同步的资源清理与管线刷新——这个操作会阻塞主线程，因为它需要把累积的渲染指令提交到GPU，同时清理过期的缓存对象，所以会产生远超单次绘制的延迟。
• 为什么排除V8 GC？V8的GC停顿通常是毫秒级的，而你说的是200000x的延迟，量级上更接近渲染管线的同步阻塞，而非JS层面的内存回收。

二、为什么是43692这个特定数字？

这个数值是Skia内部的硬编码阈值或者动态计算的内存阈值：

• Skia会根据当前的内存占用、绘制指令复杂度来计算何时需要清理缓存，对于你这种简单的直线绘制，刚好在43692次操作后触发了清理条件（比如路径缓存的条目数达到上限，或者累积的渲染数据达到了某个内存块大小）。
• 不同浏览器的阈值不同（比如Firefox用的是Gecko的Canvas实现，阈值更高但清理更频繁），这也是你在Firefox里看到不同现象的原因。

三、对项目和基准测试的影响

这个机制会直接影响两类场景：

1. 基准测试：如果你的测试只跑了几千次绘制，完全没触及这个阈值，得到的帧率数据会严重失真——真实场景下，当绘制次数累积到阈值，帧率会突然暴跌。
2. 实际项目：比如在做高频率的Canvas动画（比如数据可视化的实时更新），如果每帧的绘制次数接近这个阈值，或者连续多帧的绘制操作累积触发清理，就会出现毫无预兆的掉帧，直接影响用户体验。

四、如何规避或缓解这个问题

针对你的代码和场景，有几个实用的优化方向：

1. 批量绘制，减少重复的状态操作

你当前的代码每次循环都调用beginPath()，其实可以把重复的状态操作提取到循环外，减少Skia的临时资源生成：

// 优化后的绘制逻辑（适合实际项目，不影响测试的话可以用）
ctx.beginPath();
for (let i = 0; i < n; i++) {
  ctx.moveTo(0, 0);
  ctx.lineTo(100, 100);
  ctx.stroke();
}

如果是单纯测试单次绘制耗时，这个优化可能不适用，但实际项目里可以大幅减少内部资源的累积，延迟清理触发的时机。

2. 分帧绘制，利用requestAnimationFrame拆分任务

不要在一个同步循环里一次性完成所有绘制，把任务拆分到不同的帧里，让Skia的资源清理可以在帧间隙异步完成，避免主线程阻塞：

function run() {
  const n = +input.value;
  const times = [];
  const start = performance.now();
  let i = 0;

  function drawFrame() {
    if (i >= n) {
      // 绘制完成，处理图表
      const maxTime = times[times.length - 1];
      chartCtx.clearRect(0, 0, chart.width, chart.height);
      chartCtx.beginPath();
      chartCtx.moveTo(0, chart.height);
      for (let j = 0; j < times.length; j++) {
        const x = (times[j] / maxTime) * chart.width;
        const y = chart.height - ((j + 1) / n) * chart.height;
        chartCtx.lineTo(x, y);
      }
      chartCtx.stroke();
      return;
    }
    // 每帧绘制1000次，拆分任务
    const batchSize = 1000;
    const end = Math.min(i + batchSize, n);
    for (; i < end; i++) {
      ctx.beginPath();
      ctx.moveTo(0, 0);
      ctx.lineTo(100, 100);
      ctx.stroke();
      times.push(performance.now() - start);
    }
    requestAnimationFrame(drawFrame);
  }
  requestAnimationFrame(drawFrame);
}

这样可以把大的停顿拆分成多个小的、用户感知不到的间隙，避免掉帧。

3. 主动清理缓存，拆分大延迟

在累积一定次数的绘制后，主动调用ctx.reset()或者ctx.clearRect()，强制Skia清理内部缓存，把大的延迟拆分成可控的小停顿：

for (let i = 0; i < n; i++) {
  ctx.beginPath();
  ctx.moveTo(0, 0);
  ctx.lineTo(100, 100);
  ctx.stroke();
  times.push(performance.now() - start);
  // 每40000次操作主动重置一次，提前触发清理
  if (i % 40000 === 0) {
    ctx.reset();
  }
}

这样可以提前触发清理，避免等到阈值时的超大延迟。

总结

浏览器并没有“人工限速”Canvas，这个延迟是底层渲染引擎的资源缓存与清理机制导致的，是为了防止内存无限增长而设计的必要操作。对你来说，关键是：

• 基准测试要覆盖到阈值点，跑足够多的次数（比如20万次，就像你现在的测试），才能得到真实的性能数据；
• 实际项目里避免在单次主线程任务里累积过多的绘制操作，利用分帧、批量绘制来规避大停顿；
• 不同浏览器的阈值不同，做跨浏览器兼容时要留有余量，不要卡着阈值设计功能。