Canvas科技背景怎样降低CPU和内存占用

Canvas 科技背景如果直接堆 <canvas> 标签，把粒子数量、模糊半径和动画帧率都调到开发机上的“好看”水平，普通手机和低配服务器很快会吃不消。问题不在 Canvas 本身，而在绘制的内容有多少、绘制频率多高，以及浏览器何时真正执行了这些绘制。判断一个背景是否合格，不能只看自己的电脑，要看它在一台 2 核 2G 的服务器、一部中端安卓手机和一条不稳定的网络下，是否还能保持可用的帧率与内存占用。

先确认瓶颈在哪

Canvas 的 CPU 和内存占用主要来自三个方面：像素总量、对象数量和重绘次数。像素总量由画布尺寸和 devicePixelRatio 共同决定，对象数量对应粒子、连线或图形元素的个数，重绘次数则取决于动画循环是否在页面不可见时仍然运行。三者相互叠加，单独优化其中一项往往不够，但先找出当前最消耗资源的那一项，比盲目调参数更有效。

在动手前，可以打开浏览器的开发者工具，用 Performance 面板录制一段页面滚动和静止时的数据，观察 Scripting 和 Rendering 的耗时占比。如果 Scripting 时间远高于 Rendering，说明 JavaScript 侧的粒子计算或状态更新是瓶颈；如果 Rendering 占大头，则要考虑降低绘制分辨率或减少模糊效果。内存占用可以在 Memory 面板里拍几次堆快照，对比动画运行前后的对象数量变化，确认是否存在持续增长的未释放对象。

降低像素密度和绘制区域

最常见的浪费是画布尺寸超过屏幕实际需要的像素。高分辨率屏幕的 devicePixelRatio 可能达到 2 或更高，如果直接按物理像素创建画布，实际绘制的像素数会是 CSS 像素的四倍，而视觉上几乎没有差别。处理方式是把画布的 width 和 height 设为 CSS 尺寸乘以一个受限的像素比，例如 Math.min(window.devicePixelRatio, 2)，避免在超高分辨率设备上做无意义的绘制。

另一个容易忽略的点是画布覆盖的区域。如果科技背景只是页面顶部的一个装饰区块，就不应该让画布撑满整个视口高度。把画布的 CSS 尺寸限制在实际可见的容器内，并监听 resize 事件在容器尺寸变化时重新设置画布大小，可以减少大量无效像素的填充。这里容易出错的是 resize 事件触发频率过高，每次窗口大小变化都重建画布会导致卡顿，建议用 requestAnimationFrame 做节流，或设置一个短延时再执行重建。

控制对象数量和绘制频率

粒子数量不是越多越好。一个背景里同时存在 200 个粒子和 2000 个粒子，在视觉上可能差别不大，但 CPU 的负担会成倍增加。判断标准是：在低性能设备上把粒子数量逐步减少，观察画面是否仍然保持完整。如果减少到某个数量后视觉没有明显变化，就说明原来的数量超出了必要范围。可以用一个配置对象集中管理粒子数量、速度、连线距离等参数，方便在不同设备上切换不同档位。

动画循环是另一个关键点。最常见的错误是使用 setInterval 或 setTimeout 驱动动画，这两个方式在页面切换到后台时仍然会尝试执行，浪费 CPU。推荐使用 requestAnimationFrame，浏览器会在页面不可见时自动暂停回调。但要注意，requestAnimationFrame 在页面隐藏时确实会停止，但页面重新可见后会立即恢复，如果动画逻辑里没有处理时间差，可能会出现粒子瞬间跳动的现象。正确做法是在每次回调里计算时间增量，用增量来控制粒子的移动距离，而不是假设每帧间隔相同。

页面不可见时暂停一切绘制

即使使用了 requestAnimationFrame，在页面被浏览器标签页遮挡时，回调会停止，但如果有其他定时器或事件监听器在持续触发重绘，资源占用仍然降不下来。需要监听 visibilitychange 事件，在 document.hidden 为 true 时暂停动画循环并停止所有定时器，在页面重新可见时再恢复。

这段逻辑可以用一个简单的控制器实现：

```javascript
let running = false;

function startAnimation() {
if (running) return;
running = true;
requestAnimationFrame(tick);
}

function stopAnimation() {
running = false;
}

document.addEventListener('visibilitychange', () => {
if (document.hidden) {
stopAnimation();
} else {
startAnimation();
}
});
```

这里容易出错的地方是：如果页面上还有其他独立的动画或定时器，只暂停主循环还不够。比如粒子之间的连线检测用了独立的 setInterval，页面隐藏后它仍然在运行。需要统一管理所有定时器，或者全部改用 requestAnimationFrame 驱动，避免隐藏页面后仍有后台任务占用 CPU。另外，在窄屏设备上，画布尺寸变化会触发重绘，如果 resize 监听器在页面隐藏时仍然响应，也会造成无谓的绘制。

减少模糊和阴影效果

科技背景常用的模糊效果和阴影是 GPU 和 CPU 的双重负担。ctx.filter = 'blur(4px)' 或大量使用 shadowBlur 会让每一帧的绘制成本显著上升，尤其在低端设备上，模糊计算可能比粒子移动本身更消耗资源。处理方式是在低性能设备上检测 navigator.hardwareConcurrency 或通过一次简单的帧率测量来判断是否降级，但不要依赖固定的参数值，因为不同设备的性能差异很大。

更稳妥的做法是提供两档绘制配置：默认档使用少量粒子和简单的圆形填充，增强档才启用连线和模糊效果。通过 CSS 媒体查询或 JavaScript 检测用户是否开启了“减少动态效果”的系统偏好（prefers-reduced-motion），如果开启了，就直接显示静态背景或极低频率的动画。这个偏好是用户主动设置的，尊重它既符合可访问性要求，也能显著降低资源占用。

检查真实使用状态

完成优化后，不能只在开发者工具的模拟器里看效果。把页面部署到目标服务器上，用真实的中端手机通过 4G 或弱网环境访问，观察首屏加载时间、滚动时的帧率以及电池消耗。在 Chrome 的 Performance 面板里录制一段 10 秒的滚动和静止操作，查看长任务（Long Task）的数量和持续时间。如果长任务超过 50ms，说明主线程仍有阻塞，需要进一步减少每帧的计算量。

内存方面，连续滚动页面并反复切换标签页，然后拍摄堆快照，确认粒子数组和事件监听器的数量没有持续增长。如果发现内存只增不减，检查是否在每次重建画布时没有调用 ctx.clearRect() 或没有移除旧的事件监听器。另一个常见问题是 Canvas 的 width 或 height 属性被频繁重置，每次重置都会清空画布并重新分配内存，造成不必要的 GC 压力。

键盘操作和窄屏也是必须检查的边界。键盘用户通过 Tab 键切换焦点时，如果 Canvas 背景覆盖了整个页面且没有设置 tabindex，焦点可能无法进入背景区域，但背景的动画仍然在运行。窄屏下画布尺寸变小，粒子的密度会相对增加，如果不按容器尺寸调整粒子数量，小屏幕上反而比大屏幕更卡。

最后，记录下改动了哪些参数、检查过哪些设备和页面状态，以及出现异常时如何恢复。这些记录不需要很详细，但能帮助你在半年后重新打开这个项目时，快速理解当初为什么把粒子数量限制在某个范围，以及为什么在低性能设备上关闭了模糊效果。