Canvas数字背景性能调优思路

Canvas 数字背景的卡顿，通常不是某一个操作造成的，而是绘制数量、每帧计算量和设备性能三者叠加的结果。手机端尤其明显，粒子一多，帧率立刻掉下来，手指滑动页面时能感到明显迟滞。处理这类问题，先要确认瓶颈在哪一层，再决定是减少绘制对象、降低计算精度，还是干脆换一种实现方式。

先分清瓶颈在绘制还是布局

Canvas 性能问题分两类。一类是绘制本身太重，比如每帧要更新上千个粒子的位置、颜色和透明度，CPU 或 GPU 忙不过来。另一类是布局抖动，窗口尺寸变化时没有正确重置画布，导致浏览器反复重排，或者 Canvas 层遮挡了页面其他元素的点击事件，用户感觉“页面不响应”。

判断方法很简单：打开浏览器开发者工具的性能面板，录制一小段动画过程，看帧记录里是脚本执行时间过长，还是绘制（Paint）时间过长。如果是脚本问题，优化方向是减少每帧的计算量；如果是绘制问题，重点检查画布尺寸是否与显示尺寸一致，以及是否用了过多的高成本绘图操作，比如阴影、模糊滤镜或大面积的半透明叠加。

控制绘制数量，而不是盲目优化算法

粒子系统的性能瓶颈，绝大多数时候出在数量上。一个粒子每帧至少要更新位置、判断边界、绘制图形，假设每帧需要 0.1 毫秒，100 个粒子就是 10 毫秒，已经接近 60 帧的预算上限。粒子数量翻倍，计算量基本也翻倍，优化单个粒子的计算逻辑往往不如直接限制数量来得有效。

实际处理时，可以给粒子数量设置一个上限，比如根据屏幕宽度动态计算，窄屏设备上减少到宽屏的一半左右。这个上限不是拍脑袋定的，而是要在目标设备上实测——打开性能面板，观察帧率稳定在 60 帧还是掉到 30 帧以下，再调整数量阈值。

线条的绘制成本比粒子更高。粒子只是一个圆点，线条需要计算两个点之间的路径，还要处理透明度渐变。如果背景是粒子之间连线的那种效果，连线的数量会随着粒子数呈指数级增长——100 个粒子理论上最多有 4950 条连线，实际当然不会全画，但每增加一个粒子，需要判断的连线对就多出一批。常见的做法是限制每个粒子只与距离最近的若干粒子连线，或者干脆用网格分区，只检查相邻区域内的粒子。

requestAnimationFrame 的正确用法

动画循环用 requestAnimationFrame 是基本要求，它能让浏览器在下次重绘前调用你的更新函数，帧率与屏幕刷新率同步。但这里有一个容易出错的地方：回调函数里拿到的 timestamp 参数是页面加载以来的毫秒数，不是本次帧与上一帧的间隔。如果直接用这个时间戳驱动粒子运动，不同刷新率的设备上速度会不一样。

```javascript
let lastTime = 0;
function animate(timestamp) {
const delta = Math.min(timestamp - lastTime, 50); // 防止切回页面时跳帧
lastTime = timestamp;
updateParticles(delta);
draw();
requestAnimationFrame(animate);
}
requestAnimationFrame(animate);
```

delta 表示距离上一帧过去了多少毫秒，用它乘以速度系数，粒子移动的距离就和帧率无关了。Math.min 限制最大间隔为 50 毫秒，是为了避免用户切换浏览器标签页再回来时，delta 值过大导致粒子瞬间跳出一大段距离。

另一个容易忽略的点是页面隐藏时的处理。浏览器标签页切到后台后，requestAnimationFrame 会自动暂停，但如果你的代码里还有独立的定时器或事件监听在触发计算，后台耗电的问题依然存在。可以在 visibilitychange 事件里检测页面状态，隐藏时暂停动画循环，显示时重新启动。

窗口缩放与设备像素比

窗口尺寸变化时，Canvas 的行为和普通 DOM 元素不一样。CSS 设置的宽高只是元素的显示尺寸，画布内部有一个独立的绘图缓冲区，由 canvas.width 和 canvas.height 属性决定。如果只改了 CSS 尺寸而没改这两个属性，画布内容会被拉伸或压缩，看起来模糊，而且浏览器要额外做一次缩放，性能反而更差。

处理方式是在窗口 resize 事件里重新读取容器尺寸，同时更新 canvas.width、canvas.height 和 CSS 尺寸。这里要注意 resize 事件在拖动窗口过程中会高频触发，每次都重新计算粒子位置和画布尺寸会造成抖动。常见的做法是加一个防抖函数，等窗口停止变化后再执行重置逻辑。

设备像素比（DPR）是另一个容易踩坑的地方。高 DPR 屏幕上，一个 CSS 像素对应多个物理像素，如果画布缓冲区只按 CSS 尺寸创建，绘制出来的内容会发虚。解决办法是把画布缓冲区尺寸乘以 window.devicePixelRatio，但这也意味着实际绘制的像素数量增加了，性能开销随之上升。移动端粒子数量需要降级，部分原因就在这里——不是粒子本身算不动，而是高 DPR 下每个粒子占用的物理像素更多，绘制成本更高。

透明叠层与合成成本

Canvas 背景如果叠在页面内容下方，本身不会阻塞交互，但要注意透明区域的合成成本。浏览器需要把 Canvas 的像素和下层页面的像素做混合，如果 Canvas 上绘制了大量半透明图形，每一帧的合成工作量都会增加。

一个实用的检查方法是打开开发者工具的“渲染”面板，开启“绘制边框”或“图层边框”显示，看看 Canvas 是否被浏览器提升为独立的合成层。如果 Canvas 和页面其他内容在同一个层里，每次动画更新都可能触发整页重绘，这时候给 Canvas 容器加上 transform: translateZ(0) 或 will-change: transform 可以强制创建独立层，把动画限制在 Canvas 自己的层内。

但独立层不是越多越好。每个合成层都会占用额外的内存，移动端内存本来就紧张，层多了反而可能触发浏览器降级。判断标准是：动画区域是否足够大、是否频繁更新。如果只是一个小角落的粒子效果，没必要单独提升图层。

降级策略要分设备、分场景

降级不是把所有设备都降到同一个档次，而是根据设备能力动态调整。常见的分级方式有三种：按屏幕宽度、按设备类型、按实际帧率。

按屏幕宽度最简单，窄屏设备直接减少粒子数量，但这种方法不准确——一台低端大屏手机可能比高端小屏手机性能差得多。按设备类型区分也类似，navigator.userAgent 判断是否移动端，但同一台手机在不同负载下的表现差异很大。

更可靠的方式是按实际帧率动态调整。启动动画后，记录最近几十帧的平均耗时，如果帧率持续低于某个阈值，比如 45 帧，就自动减少粒子数量或降低绘制精度，直到帧率恢复。这种自适应策略的优点是能应对不同设备的真实性能，缺点是逻辑更复杂，需要处理降级过程中的状态同步。

实际项目中，可以先用屏幕宽度做一个粗略分级，再叠加帧率监测做精细调整。降级过程要平滑，不要让用户看到粒子数量突然减少的跳变，可以逐步减少，或者用透明度过渡掩盖变化。

边界情况检查

Canvas 动画在窄屏、低性能设备上最容易出问题，但还有几个边界场景值得单独检查。

页面加载时，如果 Canvas 脚本在 DOM 结构准备好之前执行，获取容器宽度会得到 0，画布尺寸设置错误，动画就画不出来。把脚本放在 DOMContentLoaded 之后执行，或者用 setTimeout 延迟初始化，可以避免这个问题。

用户开启“减少动态效果”系统设置时，Canvas 动画应该响应。可以通过 window.matchMedia('(prefers-reduced-motion: reduce)') 检测，匹配时直接显示静态背景或完全不启动动画。这不是可选的加分项，而是可访问性的基本要求。

键盘操作方面，如果 Canvas 背景上有可交互的元素，比如点击粒子触发跳转，需要确保这些元素能被 Tab 键聚焦，并且有可见的焦点样式。Canvas 本身绘制的内容不在无障碍树里，屏幕阅读器读不到，所以交互功能不能只靠 Canvas 实现，需要配合真实的 DOM 元素或 ARIA 属性。

验证与维护

调优完成后，验证不能只在开发者工具的模拟器里做。模拟器的性能数据和真实设备差距很大，尤其是 GPU 相关的绘制操作。至少要在两三台不同档次的真机上测试，一台高端机、一台中端机、一台低端机，覆盖不同的屏幕尺寸和 DPR。

性能面板的记录要保留下来，和修改前后的代码版本对应，这样下次出现类似问题时能快速定位是哪个改动影响了性能。代码结构上，把粒子系统、画布管理、降级策略拆成独立的模块，每个模块只负责一件事，后续调整参数或替换算法时不需要动其他部分。

Canvas 数字背景的性能调优，本质上是在视觉密度和设备能力之间找平衡。限制数量、控制帧率、处理窗口变化、做好降级，这些步骤没有一步是“必须这样做”的绝对规则，每一步都需要根据实际页面、实际设备、实际用户场景来调整。保留好测试记录和修改原因，比记住某个具体的参数值更有用。