Canvas 2D代码雨实战：清凉视觉参数、拖尾原理与性能优化

1. 把“清凉”拆解为可执行的视觉参数盛夏做视觉最怕的就是画面上再加一堆高饱和暖色。眼睛在室外已经被晒了一整天打开屏幕再来一片橙红那种燥是不需要解释的。所以当我决定做一场夏日清凉主题的代码雨第一件事不是打开编辑器而是先在纸上把“清凉”这两个字拆成能做量化取值的指标。代码雨这个形态本身不新鲜实现难度也不高真正的门槛在于怎么让它看起来不像深秋的夜、不像机房的屏保、不像某个年代的复古滤镜而是真的有一种雨后青石板的凉意。我做大屏背景和活动页氛围层做过不少这套做法后来被反复用在网页首屏、线下展台的循环动画、课件背景和电子相框上算是一个可复用的“氛围层”基建。它的技术栈极浅一个 Canvas 加一百多行 JavaScript 就能跑起来但参数没调对出来的东西就是脏、糊、闪、卡。这篇就按我自己的实操顺序把从选型、原理、实现到调参和排错的完整链路摊开讲前端新手能照着抄做过视觉的老手也能从参数对照和后处理部分拿到点东西。1.1 三条必须同时满足的视觉硬指标“清凉”这个感觉不是靠一个蓝色就能交差的。我总结下来要同时满足三条缺一条味道就不对。第一条是冷感要锁死在色相环的固定区间。我把自己满意的几版截图丢进取色器量发现主色基本都落在色相 170 到 200 之间也就是青到蓝青这一段。往左走到 150 就偏绿会有种苔藓和水藻的潮湿感往右走到 220 就偏靛变成了深夜凉是凉了但那是冷不是清。所以我最终把主色定在rgb(56, 240, 208)这个青绿配合深底的#04121f一个偏暖的青、一个偏冷的深蓝黑两者拉扯出来的空间感最舒服。第二条是底色绝对不能是纯黑。纯黑#000000会把所有亮色衬得发灰而且屏幕在纯黑区域几乎是全暗的会和周围的白色网页形成一条生硬的分界线。我用的是#04121f红通道保留 4绿 18蓝 31肉眼看上去就是黑但在色彩关系上它带着一点蓝调跟青色的字符属于同一个色系家族过渡就顺了。第三条是节奏要比经典版本慢。经典的数字雨下落很快视觉冲击强但看三十秒就累。夏天的清凉感是“缓”出来的我把速度区间从常规的每秒 200 到 600 像素压到了每秒 40 到 150 像素最快的那一列也不过是一秒走完九分之一屏。慢下来之后字符的明灭、拖尾的衰减才有时间被感知到。1.2 四种实现路线的取舍与代价动手前我把能想到的方案都摆出来比了一遍这一步很关键选错了后面全是返工。方案实现成本万级字符表现交互能力适配难度我的结论Canvas 2D低100 行左右良好两千字符内稳 60 帧强可精确拾取坐标低只需处理像素比首选纯 CSS 动画中要写大量 keyframes差DOM 节点一多就掉帧弱只能做 hover中响应式要重写只适合静态装饰WebGL / 着色器高需要写 GLSL极强十万字符无压力中交互逻辑要自己搭中高需处理上下文丢失大屏且字符量巨大时再上DOM 定时器低很差重排重绘成本高强低不推荐选 Canvas 2D 的核心理由是性价比。这个效果的本质是“在同一块画布上不停地画字再蒙一层半透明色”它不需要三维变换、不需要复杂光照用不上 GPU 的算力。而 Canvas 2D 的fillText在如今的主流设备上画两千个字符完全扛得住同时它保留了完整的二维坐标系做鼠标涟漪、做触摸跟随都不用再绕一层。WebGL 那套我不是没试过。把字符预渲染成纹理图集用一个实例化绘制的批次去刷确实能做到十万级字符不掉帧但代价是要处理着色器编译失败、上下文丢失恢复、纹理图集打包这些额外问题对一个氛围背景来说属于用大炮打蚊子。我给自己定的判断标准是如果单屏字符数不超过三千就不要碰 WebGL。屏幕宽度 1920字号 16列间距约 22 像素一共也就 87 列每列平均 20 个字符总数不到两千Canvas 2D 绰绰有余。1.3 这个效果能被复用到哪些场景做的时候我没把它当成一个一次性玩具而是按“氛围层组件”的思路去设计的。落地下来的场景大概有这么几类。网页首屏背景是最直接的。把它放在一个固定定位的 Canvas 里z-index压到内容之下pointer-events设成none标题和按钮照常叠在上面。这时候要注意的是对比度青色的字符会和白色文字抢注意力解决办法是给内容区加一层从中心向外渐变的半透明遮罩把中间区域压暗视线自然集中。线下大屏和展台循环播放是第二类。这种场景往往是一块竖屏或者超宽屏比例很怪所以列数必须按实际宽度动态算不能写死。另外这类设备常常是低配的工控机性能预算比想象中紧我一般会主动把像素比上限压到 1.5宁可稍微软一点也不要有卡顿。第三类是课件和演示文稿的动态背景或者直播画面的氛围层。这类场景的特点是“长时间静态观看”所以运动幅度要更收敛速度上限再降一半避免观众看久了头晕。第四类是生成类用途比如把某一帧导出成图片做海报底图或者社交媒体的配图。这就需要在绘制循环里留一个snapshot的入口等画面跑到某个满意状态时停帧导出。做这个的时候要注意 Canvas 的toDataURL在跨域资源参与绘制后会污染画布纯文字绘制没有这个问题但如果后面加了图片纹理就要小心。2. 代码雨的本质一场“没有擦干净”的动画很多人第一次看这个效果会以为每一帧都在完整地重绘一整列字符然后靠某种动画曲线控制透明度。真拆开来看会发现完全不是那么回事。代码雨的核心技巧只有一句话每帧只画最前面那一个字符然后用半透明底色把整块画布蒙一层旧的东西自然就淡下去了。2.1 拖尾的数学为什么我最终选了 0.08这个“蒙一层”的透明度是整个效果里最关键的一个参数我用trailAlpha表示。它的作用类似摄影里的长曝光每帧覆盖一次旧像素就按比例衰减一次。假设某一帧画下了一个纯青色的字符亮度记为 1。下一帧被蒙上一层透明度为a的底色后它残留的亮度变成1 - a。再过一帧变成(1 - a)²。也就是说一个字符从画下到几乎看不见需要经过的帧数是n ln(阈值) / ln(1 - a)我取的“几乎看不见”阈值大概是 0.02也就是亮度剩 2% 时人眼基本分辨不出。代入a 0.08ln(0.02) / ln(0.92) ≈ 46帧。按 60 帧每秒算一个字符的完整生命周期大约 0.77 秒。这个 0.77 秒是我反复试出来的。如果按经典的a 0.05生命周期会拉到 76 帧大概 1.27 秒拖尾太长整屏会糊成一片雾字符之间分不开看着像信号不好的老电视。如果贪清爽把a提到 0.15生命周期只剩 24 帧0.4 秒拖尾短得像一根根竖着的光棍完全没有“雨”的流动感。这里有个容易忽略的陷阱这个公式里的帧数假设是稳定 60 帧。如果设备掉到 30 帧同样的a值会让拖尾在时间上拉长一倍看起来就变糊了。所以正确的做法不是固定a而是让a跟着实际的时间步长走。我的处理方式是把a换算成“每秒衰减率”再乘上实际帧间隔// 目标是每秒衰减到原来的 0.6% const decayPerSecond 0.006; const alpha 1 - Math.pow(decayPerSecond, dt);这样无论 30 帧还是 120 帧视觉上的拖尾长度都是一致的。这个小改动解决了我早期在低端安卓设备上“同一个页面两种观感”的问题。2.2 一列就是一条独立的数据流理解了拖尾接下来要想清楚数据怎么组织。最直觉的方式是“每个字符一个对象”维护一个几千个元素的数组每帧遍历、更新 y 坐标、判断越界、回收复用。我一开始就是这么写的跑起来也没问题但代码读起来很啰嗦而且对象数量多的时候垃圾回收压力会上升。后来我改成了“一列一个对象”的模型清爽很多。每一列只记录四个东西横向位置x、头部纵坐标head、下落速度speed、拖尾长度len。绘制的时候从头部往上每隔一个字高画一个字符一共画len个越往上透明度越低。头部那一个用高亮色其余用主色按比例衰减。这种模型有个隐含的假设拖尾里的每个字符位置是稳定的只是亮度在变。而字符的“内容”我是每帧重新随机取的这会造成一点点闪烁感但你别说这个闪烁恰好让画面有了呼吸反而不呆板。如果追求极致稳定可以给每个位置缓存一个 glyph每隔若干帧才换一次我在后面的调参部分会讲这个技巧。顺手提一句len这个值我是随机化的范围 8 到 30 之间。如果所有列长度一样画面上会出现整齐的横线边缘像梳子一样非常假。随机化之后各列的“雨丝”长短不一视觉上就有了层次。2.3 速度必须用每秒像素不能用每帧像素这是新手最容易踩的坑我早期也栽过。如果你写this.y 3那这个 3 就是“每帧 3 像素”。在 60 帧的电脑上这一列每秒下落 180 像素同一份代码在 120 帧的高刷屏上每秒下落 360 像素直接快了一倍。用户换了台设备你的作品就变了样。正确的做法是把速度定义成px/s然后每帧按时间步长积分column.head column.speed * dt; // dt 单位是秒dt的获取要注意两件事。一是必须做上限截断浏览器在标签页切到后台时会暂停requestAnimationFrame切回来的时候两次时间戳可能差了好几秒不截断的话所有雨滴会瞬间飞出屏幕。我一般截到 0.05 秒也就是最多按 20 帧每秒去补视觉上不会察觉但能避免跳变。二是用performance.now()而不是Date.now()。后者精度只有毫秒且受系统时间调整影响前者是单调递增的高精度计时做动画必须用它。这两行代码看起来微不足道但它决定了你的作品在别人机器上是不是还长那个样子。3. 完整实现从空画布到第一滴雨理论讲完进入能跑的部分。我把代码拆成 HTML 骨架和 JavaScript 主逻辑两块整个项目不需要任何构建工具双击打开就能看方便你边改边看效果。3.1 画布初始化与高分屏适配先解决一个绕不过去的问题视网膜屏模糊。在像素比为 2 的设备上如果你只按 CSS 尺寸设置canvas.width浏览器会把一张一半分辨率的图放大两倍显示字符边缘会糊成一团。解决办法是把画布的物理像素尺寸乘以像素比再用setTransform把绘制坐标系缩回逻辑尺寸。!DOCTYPE html html langzh-CN head meta charsetutf-8 meta nameviewport contentwidthdevice-width, initial-scale1 style html, body { margin: 0; height: 100%; background: #04121f; overflow: hidden; } #rain { display: block; width: 100%; height: 100%; } /style /head body canvas idrain/canvas script srcrain.js/script /body /htmlconst canvas document.getElementById(rain); const ctx canvas.getContext(2d, { alpha: false }); let W 0, H 0, dpr 1; function resize() { // 像素比封顶 2再高对观感提升有限对性能损耗很大 dpr Math.min(window.devicePixelRatio || 1, 2); W canvas.clientWidth; H canvas.clientHeight; canvas.width Math.floor(W * dpr); canvas.height Math.floor(H * dpr); ctx.setTransform(dpr, 0, 0, dpr, 0, 0); // 首次铺底色注意 alpha:false 的画布初始是黑的 ctx.fillStyle #04121f; ctx.fillRect(0, 0, W, H); rebuildColumns(); }这里有两个细节值得说。第一个是getContext的alpha: false选项它告诉浏览器这块画布不需要透明通道渲染时可以走更快的合成路径。代价是你不能用clearRect得到透明效果但对这个项目来说完全无所谓因为我们本来就是不透明底。实测下来在部分集成显卡上能省 10% 到 15% 的绘制时间。第二个是ctx.setTransform(dpr, 0, 0, dpr, 0, 0)这一行它的作用是把后续所有绘制操作按像素比放大。这样你在写fillText(ch, 100, 200)的时候用的仍然是逻辑坐标不用到处乘 dpr代码可读性高很多。3.2 字符集设计为什么我放弃了全角字符经典的数字雨用的是半角片假名那种细长的竖条感特别适合。但这个项目是“夏日清凉”主题纯片假名读起来有点冷硬我想混入一些更贴近主题的符号。试了几轮之后字符池定成这样const POOL 01 ~-_/\\|*°.,: 0123456789;排在最前面的是0和1因为它们视觉重量轻、辨识度高出现频率我刻意调高了让画面有一层“数据流”的底味。中间是半角片假名负责那种密集的竖线质感。后面跟了一串符号~和°是刻意加的它们本身就带有“水汽”“涟漪”的联想配合青色在深底上看着就凉。最后再补一组数字增加随机分布的密度。这里踩过的坑是全角字符。我一开始把中文的“雨”“水”“凉”这些字塞进去了想着更有主题感结果画面立刻乱了。原因是全角字符的宽度大致是半角的两倍而我的列是按固定间距排的全角字符一出现就会压到相邻的列上重叠处糊成一团。更麻烦的是不同字体的全角字符宽度还有细微差异textAlign: center也救不回来。所以结论很明确这个效果的字符池必须是等宽的。要么全用半角要么老老实实用measureText动态测宽。前者简单可靠后者我只在需要混排中英文的定制项目里用过。我的建议是除非甲方明确要求否则别碰全角。还有一个隐蔽的坑有些系统字体在渲染某些符号时会触发字体回退回退到的字体宽度不一致。所以font里一定要写上备选字体链比如16px Courier New, Noto Sans Mono, monospace并且测试的时候至少在 Windows 和 macOS 上各看一遍。3.3 主循环与绘制顺序主循环的结构很固定一共四步蒙层、更新位置、绘制字符、请求下一帧。顺序不能变一旦变了效果就不对。const CFG { fontSize: 16, lineRatio: 1.15, // 行高 字号 × 1.15 speedMin: 40, speedMax: 150, decayPerSecond: 0.006, windX: 14, colorBg: 4, 18, 31, colorBody: 56, 240, 208, colorHead: 217, 255, 245 }; let columns []; let lastTime 0; function rebuildColumns() { ctx.font ${CFG.fontSize}px Courier New, Noto Sans Mono, monospace; const charW ctx.measureText(M).width; const gap Math.ceil(charW * 1.4); // 列间距略大于字宽留出呼吸感 const count Math.ceil(W / gap) 1; columns []; for (let i 0; i count; i) { columns.push({ x: i * gap gap * 0.5, head: -Math.random() * H, // 初始位置随机避免整齐起步 speed: CFG.speedMin Math.random() * (CFG.speedMax - CFG.speedMin), len: 8 Math.floor(Math.random() * 22), phase: Math.random() * Math.PI * 2 }); } } function frame(now) { if (!lastTime) lastTime now; // 时间步长截断防止切后台回来时瞬间飞屏 const dt Math.min((now - lastTime) / 1000, 0.05); lastTime now; // 第一步半透明蒙层制造拖尾 const cover 1 - Math.pow(CFG.decayPerSecond, dt); ctx.fillStyle rgba(${CFG.colorBg}, ${cover}); ctx.fillRect(0, 0, W, H); // 第二步绘制 ctx.font ${CFG.fontSize}px Courier New, Noto Sans Mono, monospace; ctx.textAlign center; ctx.textBaseline middle; const step CFG.fontSize * CFG.lineRatio; for (const col of columns) { col.head col.speed * dt; // 整列离开屏幕后重置到顶部 if (col.head - col.len * step H) { col.head -Math.random() * H * 0.6; col.speed CFG.speedMin Math.random() * (CFG.speedMax - CFG.speedMin); col.len 8 Math.floor(Math.random() * 22); } // 横向摆动模拟风 const sway Math.sin(now / 2600 col.phase) * CFG.windX; for (let i 0; i col.len; i) { const y col.head - i * step; if (y -step || y H step) continue; const t 1 - i / col.len; // 0 到 1越靠头部越大 const alpha Math.pow(t, 1.6); // 指数衰减让尾巴掉得更快 const ch POOL[(Math.random() * POOL.length) | 0]; if (i 0) { ctx.fillStyle rgba(${CFG.colorHead}, 0.95); } else { ctx.fillStyle rgba(${CFG.colorBody}, ${(alpha * 0.85).toFixed(3)}); } ctx.fillText(ch, col.x sway * t, y); } } requestAnimationFrame(frame); } window.addEventListener(resize, resize); resize(); requestAnimationFrame(frame);几个位置的设计意图需要挑明。alpha Math.pow(t, 1.6)这里的指数 1.6 不是随便写的。如果指数取 1也就是线性衰减整列字符的亮度是均匀过渡的看起来像一根渐变的棍子缺乏“头部爆发”的感觉。指数大于 1 之后靠近头部的几个字符迅速亮起来尾部快速掉暗形成了明显的“头重尾轻”这才是雨滴的视觉结构。我试过 1.2、1.6、2.0、2.4 四个值1.6 最平衡2.4 会让拖尾只剩三四个字符可见太秃。sway * t这个乘法也很重要。如果整列一起横移那就是刚体平移看着像一根棍子在漂乘上t之后头部摆幅最大、尾部几乎不动形成了一种柔软的弯曲像水草在水流里晃这才是“夏夜的风”该有的形态。3.4 交互指尖划过的那圈涟漪静态的氛围层已经能用了但加一点交互会让它活过来。我选的是最低成本、最高观感的一种触摸或鼠标划过时在指针附近让字符短暂提亮并向外扩散。实现思路是维护一个“扰动源”数组每个元素记录坐标和剩余寿命。绘制每个字符时计算它到所有扰动源的距离落在半径内的字符按距离加权提升亮度。const ripples []; function addRipple(x, y) { ripples.push({ x, y, born: performance.now(), life: 900 }); } canvas.addEventListener(pointermove, e { const rect canvas.getBoundingClientRect(); addRipple(e.clientX - rect.left, e.clientY - rect.top); }); // 在字符绘制循环内取最大扰动强度 let boost 0; for (const r of ripples) { const age performance.now() - r.born; if (age r.life) continue; const radius 40 age * 0.12; // 涟漪持续扩散 const dx col.x - r.x; const dy y - r.y; const dist Math.hypot(dx, dy); if (dist radius) { boost Math.max(boost, 1 - dist / radius); } } const finalAlpha Math.min(1, alpha * 0.85 boost * 0.8);性能上要注意两点。一是pointermove在高频鼠标上每秒能触发上百次如果每次都往数组里塞一个新对象几秒钟就能堆到几千个遍历成本会飙升。所以必须做节流我一般限制在每 40 毫秒最多触发一次同时每帧清理掉已经过期的扰动源。二是Math.hypot在旧设备上比较慢如果对性能极度敏感可以换成Math.sqrt(dx*dx dy*dy)实测能快 20% 左右。这个优化的意义在于这段代码在字符循环内部会被执行上百万次任何一点小开销都会被放大。4. 调参现场从“能跑”改到“耐看”代码跑通和画面好看之间隔着几十次反复调参。这一节我把压箱底的参数表和调整逻辑摊开你照着改基本能省掉大半天试错。4.1 关键参数对照表参数我的取值作用调大后的表现调小后的表现fontSize16字符大小字符变粗列数变少气势足但细腻度差细节多但小屏上会糊成噪点lineRatio1.15行高倍率拖尾稀疏有空隙感字符重叠黏成一片speedMin/Max40 / 150下落速度急促冲击力强缓慢但太慢会显得凝滞decayPerSecond0.006每秒残留率拖尾变短画面清爽拖尾变长画面起雾windX14横向摆幅摆动明显柔软笔直下落机械感强len范围8 ~ 30拖尾字符数雨丝长瀑布感雨丝短像光点直落列间距系数1.4密度稀疏透气密集压迫感强这张表里最容易调翻车的是fontSize和列间距的配合。字号调大之后如果不跟着调列间距列与列之间会挤到一起横向的字符重叠会形成一片难看的色块。我的经验关系是列间距至少是字宽的 1.3 倍1.4 是甜点值1.5 就有点散了。还有decayPerSecond这个值很多人会直接抄别人的0.05或者0.1当每帧的 alpha 值但在我们这套按时间步长计算的方案里这个量纲完全不一样。0.006的意思是“一秒之后只剩 0.6%”换算成每帧大概就是0.075左右跟我前面算的 0.08 基本对得上。迁移代码的时候一定要看清量纲否则拖尾长度会差出十倍。4.2 亮度分配的三个层级画面耐不耐看很大程度上取决于亮度层次有没有拉开。我给字符分了三级各级承担不同的叙事功能。最亮的是头部字符用rgba(217, 255, 245, 0.95)接近白但带一点青。它的作用是提供视觉锚点让眼睛有地方落。如果头部不够亮整个画面会显得灰蒙蒙没精神但要是亮到纯白又会刺眼跟“清凉”的诉求背道而驰。217 这个红通道值是慢慢试出来的再高一点就显得燥了。中间层是拖尾主体用rgba(56, 240, 208, 0.85)再乘透明度系数。这个青色的绿通道很高、蓝通道也不低所以它在深蓝底上呈现出一种发光的质感但又不像霓虹灯那么艳。最暗的是远端残留靠拖尾的衰减自然形成落在 0.05 到 0.2 之间。这一层几乎不承担信息传递纯粹是画面的“湿度”。没了它画面会显得干枯生硬太强了又会糊。一个小技巧如果想强调某个区域的视觉重心可以在画布上方再叠一层径向渐变遮罩中心透明、边缘压暗。这层遮罩用 CSS 的radial-gradient实现就行不消耗 Canvas 性能但在大屏上能把注意力牢牢锁在中间边缘的字符自然虚化空间纵深立刻就出来了。4.3 性能预算与移动端降级在桌面端跑得飞起的东西到手机上未必。我按 60 帧每帧 16.7 毫秒的预算去掐把开销拆成了三块蒙层fillRect占不到 1 毫秒文本绘制占大头剩下的就是循环逻辑。移动端我做了三档降级。第一档是降低像素比上限从 2 降到 1.5绘制面积直接少了 44%。第二档是增大列间距从 1.4 提到 1.7列数减少约 18%。第三档是限制帧率用累加器把绘制锁在 30 帧虽然流畅度下降但发热和耗电改善非常明显。const isMobile /Android|iPhone|iPad/i.test(navigator.userAgent); const TARGET_FPS isMobile ? 30 : 60; const FRAME_MS 1000 / TARGET_FPS; let acc 0; function frame(now) { const elapsed now - lastTime; lastTime now; acc elapsed; if (acc FRAME_MS) return requestAnimationFrame(frame); const dt Math.min(acc / 1000, 0.05); acc 0; // ... 绘制逻辑 }这套锁帧逻辑有个细节要注意acc用完必须清零而不是减去FRAME_MS。减去的话累加器会一直往上涨最终导致帧率失控。我一开始就是写错了这一行在低端机上表现为“前几秒正常之后越来越快”排查了半天才发现。还有一个更彻底的优化手段是字符纹理图集。把字符池里每个字符预先渲染到一张离屏 Canvas 上做成精灵图绘制时用drawImage代替fillText。实测在低端安卓上能提升 30% 到 50%代价是需要处理不同字号下的重渲染以及图集本身的显存占用。如果你的项目要跑在性能极差的设备上这个优化值得做。5. 排查实录那些文档里不会写的坑这一节全部来自实际调试时的翻车记录按现象、原因、解决三段式整理遇到问题可以直接对号入座。5.1 画面类问题速查现象最可能的原因解决方式一片纯黑什么都没有没做首次底色填充或列初始 y 全在屏幕外初始化时fillRect全屏列初始head用负随机值有一条条横向亮纹每帧绘制的坐标带小数抗锯齿累积成条纹坐标取整或把lineRatio调成整数倍字符糊成一团像素比没处理或字号太小检查setTransform调用字号不低于 14整体像蒙了一层雾拖尾残留率太高提高decayPerSecond或减少len拖尾短得像光棍拖尾残留率太低降低decayPerSecond注意时间量纲列与列之间字符重叠列间距小于字宽用measureText实测字宽间距取 1.4 倍以上字符竖着能连上横着错位字体不是等宽回退到了比例字体字体链最后必须兜底monospace横纹那个问题值得展开说。在早期版本里我让每列的头部坐标做连续的浮点累加fillText的 y 值带着小数。理论上抗锯齿会把边缘柔化但因为每一帧的坐标增量几乎一致柔化的结果也在每一帧几乎一致叠加几十帧之后那些半透明的边缘就累积成了一条条清晰可见的横线整屏看过去像老式显示器的扫描线。解决办法有两个。一是把绘制的 y 坐标取整Math.round(y)代价是运动会有轻微的跳跃感但在这个尺度下根本看不出来。二是干脆接受它把它当成一种风格化的处理我在某个版本里就保留了这个特征反而有人反馈说“有做旧显示器的味道”。选择哪种取决于你的整体调性。字符糊那个问题我遇到过好几次不同原因。有一次是忘了在resize里重设setTransform改了窗口大小之后缩放矩阵丢了。还有一次是字体链写错Courier New在某个系统上没有回退到了一个比例字体字符宽度不一致抗锯齿也跟着乱。所以字体链一定要在目标系统上实测别想当然。5.2 性能与适配类问题速查现象排查思路处理方式桌面流畅手机发烫卡顿看像素比、列数、字符总数像素比封顶 1.5列间距放大锁 30 帧切到后台再回来画面突跳时间步长没有截断dt上限设 0.05 秒滚轮滚动时画面撕裂绘制没跟随用户滚动用固定定位的 Canvas或改用requestAnimationFrame对齐长时间运行越来越卡对象池没复用垃圾回收抖动列对象只修改属性不重新创建高刷屏上速度异常快速度按每帧计算改成每秒像素乘以dt窗口拉伸后画面变形只改 CSS 尺寸没改画布分辨率resize里同步更新canvas.width/height内存抖动这个坑我吃过一次大亏。最早的实现里每次重置一列我都是columns[i] makeColumn(x)创建新对象、丢弃旧对象。短时间看不出来但挂着跑了几个小时的展台大屏之后页面会明显变卡DevTools 里能看到垃圾回收的锯齿非常密。改成就地修改属性之后对象数量恒定回收压力几乎归零连续跑一整天都稳。还有一个问题是指针事件在触摸设备上的重复触发。pointermove在触屏上会跟着手指的采样率高频触发如果不做节流涟漪数组的增长速度远超清理速度。我的做法是加一个时间戳判断距离上次添加不足 40 毫秒就直接返回。let lastRippleAt 0; function tryAddRipple(x, y) { const now performance.now(); if (now - lastRippleAt 40) return; lastRippleAt now; ripples.push({ x, y, born: now, life: 900 }); }清理也要跟上每帧遍历时把过期的元素剔除。我用的方式是原地压缩数组而不是filter新建数组因为后者每帧都会产生一个新数组又是一笔垃圾回收开销。5.3 几个只有动手才会知道的小经验第一条别在循环里创建渐变色对象。createLinearGradient这类调用看着轻但它每次都会返回一个新对象放在每帧循环里能直接把帧率拉低。如果确实需要渐变就在初始化时创建一次存成变量反复用。第二条首屏第一帧最好手动描一遍。requestAnimationFrame在页面刚加载时可能延迟几十毫秒这期间画布是空白的用户会看到一闪。我的做法是在resize之后立刻跑一次绘制把画面填满这样从加载到第一帧之间是无缝的。第三条给效果加一个prefers-reduced-motion的判断。有些用户会在系统里关闭动画这时候应该直接渲染一帧静态画面然后停掉循环而不是继续跑。这既是体验问题也是无障碍的基本要求。const reduceMotion window.matchMedia((prefers-reduced-motion: reduce)).matches; if (reduceMotion) { drawOnce(); } else { requestAnimationFrame(frame); }第四条导出的静态帧记得先跑够时间。如果要做海报或者配图别在刚加载的时候截那时候雨滴还没铺满屏幕。我的做法是等大约 3 秒让整个画面进入稳态再调用canvas.toDataURL(image/png)。如果要更高的清晰度可以临时把像素比调到 3 渲染一帧导出后再调回来。我自己在这个项目上折腾最久的其实不是代码而是坐远了看。屏幕前盯着调参数觉得差不多了退到三米外一看整个画面的密度和亮度完全是另一回事。所以后来我形成了一个固定动作每改完一轮参数就站起来后退几步看十秒再回到电脑前继续。这个习惯帮我避开了一堆“局部看着挺美、整体一塌糊涂”的方案。夏天的凉意是个整体感受它不在某一个参数里而在所有参数凑在一起的那个平衡点上。