“静态图表是一个下午的活动态图表是一个迭代周期的活。”这话我跟不少人说过每次说完对方都半信半疑直到自己上手做动态数据可视化才发现——画出来只是起点让它在一秒刷新十次、数据量涨到十万条、用户还在上面拖拽缩放的同时保持不掉帧才是真正的工程量。用 JavaScript 做动态数据可视化的门槛从来不在“会不会画柱状图”而在数据流、坐标映射、帧调度、交互时序这几件事能不能咬合上。我这次拆的是原生 JavaScript 从零搭一层动态可视化渲染的完整思路不绑定某个具体图表库。原因很简单库能帮你省掉画图的样板代码但省不掉上面那些底层问题换了库它们一样在。这篇适合已经能用现成图表库画出图、但一遇到“卡”“抖”“数据丢了”“跑一晚上内存爆了”就不知道从哪下手的人也适合想自己造一层渲染抽象、不想被库的默认行为绑死的开发者。下面的代码片段都是能直接跑起来的不是伪代码参数和阈值我也会说明是怎么定出来的。1. 动态可视化的成本到底花在哪把需求拆开看1.1 静态图表是快照映射动态图表是持续循环静态图表的处理链路很短拿到一份数据快照算一遍值域建立比例尺把数据点映射成像素坐标一次性画完结束。整条链路上没有“时间”这个变量所以你不用考虑状态一致性不用担心第 3 帧和第 4 帧之间数据变了怎么办。动态图表把时间维度加进来之后链路变成一个闭环数据持续进来进缓冲区滑动窗口裁剪聚合降采样重算坐标清屏重绘等待下一帧。每一环都可能有延迟每一环都可能成为瓶颈更麻烦的是每一环的状态必须对齐——如果数据缓冲区已经推到了第 5000 条而画布上还在渲染第 4800 条对应的坐标域你看到的就是曲线在跳变。我在实际项目里最常遇到的一个现象是图表单独跑 Demo 流畅得像丝绸接进真实页面就开始一顿一顿的。原因通常是渲染循环和页面上其它动画、滚动、图片加载抢主线程。动态可视化的性能问题八成不在画图那一步而在“什么时候画”和“画多少”。1.2 SVG、Canvas、WebGL 三条路先选对再谈优化这个选型如果一开始选错后面所有优化都是在填坑。我按实际经验给个对照渲染路径适合的规模动态刷新表现交互成本主要坑点SVG数百到两千个元素中等DOM 节点多时明显掉帧最低事件直接绑元素节点数一多样式重算开销陡增Canvas 2D数千到十万级数据点好可控需要自己做命中检测高 DPI 缩放容易糊重绘范围控制不好会全屏刷WebGL十万级以上很好需要自己写拾取逻辑上手成本高文字渲染麻烦判断标准不是什么“高级用什么”而是每秒需要重绘的图元数量。如果你的动态图表是一张 30 根柱子的实时排行每秒刷新一次SVG 完全够用而且悬停高亮、点击下钻这些交互写起来最省事如果是十万点的时间序列滚动波形Canvas 是性价比最高的选择只有当你需要同时渲染几十万个图元还要保持 60 帧才值得上 WebGL。我个人的默认选择是 Canvas 2D。它处在“性能够用”和“心智负担可控”的交叉点上而且一旦你把渲染抽成“每帧重画一遍画布”的模型动画、缩放、过渡都能统一到同一套逻辑里不用维护一堆 DOM 状态。1.3 先分清你要的是“动画”还是“实时”这两个词经常被混着用但技术方案完全不同。动画是确定性的起点、终点、时长都已知中间每一帧的值可以预计算或用缓动函数推出来。你可以放心地做 800 毫秒的柱状图生长效果因为你知道它一定会结束。实时是不可预测的下一秒来几条数据、数值多大、有没有尖峰你事前都不知道。这种情况下任何“等数据到齐再画”的思路都会失败你必须假设数据随时在变画布永远处于“当前已知最新状态”的渲染中。分不清这两者最典型的翻车现象是给实时数据加了入场动画结果数据每 200 毫秒推一次动画时长 800 毫秒动画永远播不完一直在被打断重来视觉上就是柱子疯狂抽搐。判断方法很简单——问一句“这个动效有没有可能在播完之前被新数据打断”如果有就别用补间动画改成位置插值跟随。2. 数据进渲染层之前有三件事必须做掉2.1 按像素列聚合别把原始点直接丢给画布这是性能优化里性价比最高的一刀。假设画布宽 1000 像素你有 20 万个数据点那不管你画得多快横向 1000 个像素里塞了 20 万个点平均每个像素列 200 个点画出来的视觉效果和只画 1000 个点几乎没区别但开销是 200 倍。正确做法是按像素列分箱把 x 轴范围平均切成等于画布宽度的份数每个箱子里只保留最小值和最大值两个点有时再加上首尾。这样无论原始数据多少绘制量都被压到2 × 画布宽度这个量级。对于趋势曲线min/max 保留法能保住尖峰不会像平均值那样把异常抹平。function binByPixel(data, xScale, pixelWidth) { const bins new Array(pixelWidth); for (let i 0; i data.length; i) { const px Math.floor(xScale(data[i].x)); if (px 0 || px pixelWidth) continue; const bin bins[px]; if (!bin) { bins[px] { min: data[i], max: data[i] }; } else { if (data[i].y bin.min.y) bin.min data[i]; if (data[i].y bin.max.y) bin.max data[i]; } } const out []; for (let i 0; i pixelWidth; i) { if (!bins[i]) continue; const a bins[i].min, b bins[i].max; out.push(a.x b.x ? a : b, a.x b.x ? b : a); } return out; }注意这里有个细节输出必须按 x 排序否则连线会来回穿插。上面用a.x b.x做了简单排序如果两个点的 x 完全相等顺序就无所谓了。2.2 比例尺自己实现一遍比调库更省心很多人习惯用现成的比例尺工具但动态场景下自己写一个线性比例尺只要十几行还能顺手把invert反向映射一起带上后面做交互的时候直接就能用。function linearScale(domain, range) { const [d0, d1] domain; const [r0, r1] range; const k (r1 - r0) / (d1 - d0 || 1); const fn v r0 (v - d0) * k; fn.invert p d0 (p - r0) / k; fn.domain domain; fn.range range; return fn; }d1 - d0 || 1这个写法是为了防止分母为零——当所有数据值都相同时比如监控接口刚启动返回的全是 0值域宽度是 0除法会得到Infinity整个画布就空白了。这个坑我在早期项目里踩过排查了半天以为是渲染 bug。时间轴的比例尺要特别小心时间戳的间隔不是均匀的如果业务要求“按真实时间间隔排布”就直接用毫秒数做线性映射如果要求“等距展示”比如每天一个点不管间隔几天那就是序数比例尺两者不能混。混了之后你会看到曲线在某一段莫名其妙变密。2.3 用环形缓冲区管理滑动时间窗口实时数据一般只看最近 N 秒或最近 N 条用数组shift()会引发 O(n) 的元素搬移数据量大了之后这个开销能占到整个帧时间的两成以上。环形缓冲区把插入和淘汰都做成 O(1)。class RingBuffer { constructor(capacity) { this.capacity capacity; this.buf new Array(capacity); this.head 0; this.size 0; } push(item) { this.buf[this.head] item; this.head (this.head 1) % this.capacity; if (this.size this.capacity) this.size; } toArray() { const out new Array(this.size); const start (this.head - this.size this.capacity) % this.capacity; for (let i 0; i this.size; i) { out[i] this.buf[(start i) % this.capacity]; } return out; } }toArray()每次调用都会新建数组这在每帧都调用的情况下会产生可观的垃圾回收压力。如果缓冲区容量固定且数据量大更好的做法是提供一个forEach遍历接口直接复用同一个数组做输出缓冲区避免每帧分配。2.4 缺失值和异常值要有明确的处置规则而不是靠运气实时数据里出现null、NaN、突然跳到十万的脏值几乎是必然的。我的处理规则是三层第一层null和NaN直接跳过不参与比例尺计算但在绘制时把曲线断开moveTo而不是lineTo让用户能看出这里缺了一段而不是被一条直线蒙混过去。第二层偏离历史中位数超过某个倍数的值标记为可疑但仍然绘制只是换一种颜色或者加个标记点。直接丢弃是危险的因为真实的业务尖峰和异常值在数值上没法区分。第三层如果可疑值连续出现超过阈值才认为数据源出问题触发降级——比如暂停滚动、在图表上打一个提示条。这种“先展示再判断”的思路比“先过滤再展示”更符合监控场景的实际需求。3. 帧调度rAF 用不对再好的渲染代码也白搭3.1 setInterval 是动态图表的第一号杀手我见过太多代码用setInterval(render, 100)做刷新。它的问题不止是“不准”更麻烦的是它和浏览器的绘制节奏完全脱钩有可能两次定时器回调落在同一帧里做了无用功也有可能一帧里没有回调画面撕裂页面切到后台之后定时器还在跑回来的时候积压了一堆任务一次性执行。requestAnimationFrame的价值在于它由浏览器统一调度回调时机和屏幕刷新对齐页面不可见时自动暂停。但它也不是拿来直接用就完事。3.2 一个能长期用的渲染循环模板下面这个结构我在多个项目里用过核心是三件事限制刷新频率、限制单帧耗时、处理时间跳变。const TARGET_INTERVAL 1000 / 30; // 30fps 对大多数看板足够 let rafId null; let lastTs 0; let acc 0; function frame(now) { rafId requestAnimationFrame(frame); // 时间跳变保护后台切回、系统休眠后 now 会大幅跳变 let delta now - lastTs; if (delta 0 || delta 1000) delta TARGET_INTERVAL; lastTs now; acc delta; if (acc TARGET_INTERVAL) return; acc 0; const t0 performance.now(); update(delta); render(); const cost performance.now() - t0; // 单帧超预算就降级交给下一节讲 if (cost TARGET_INTERVAL) onBudgetExceeded(cost); }几个参数的含义要说清楚。TARGET_INTERVAL定成 33 毫秒30fps而不是 16.7 毫秒60fps是因为大部分数据看板根本不需要 60 帧30 帧的视觉流畅度已经足够把省下来的帧预算留给主线程上的其它逻辑。delta 1000的跳变保护是必须的——页面切到后台一段时间再回来now会突然变大几千毫秒如果直接拿去算动画进度或者滚动偏移你会看到图表瞬间冲到最右端。3.3 帧预算怎么分配绘制别超过一半一帧 33 毫秒我一般这样分数据更新和聚合不超过 10 毫秒绘制不超过 15 毫秒剩下 8 毫秒留给浏览器的样式计算、布局和其它脚本。这个分配不是拍脑袋是实测出来的——如果绘制占到 25 毫秒以上页面上的滚动就会开始发涩因为滚动虽然跑在合成线程但主线程被占满时输入事件的处理会被推迟用户能感觉到“拖不动”。监控单帧耗时的方法很简单就是用performance.now()前后夹一下。要注意的是这个测量本身有开销大约几微秒不要在一次绘制里调用几十次。生产环境里我会采样比如每 30 帧测一次把结果存在一个环形缓冲区里页面上放一个隐藏的性能面板按快捷键才显示。3.4 增量绘制和脏矩形什么时候值得做全量清屏重绘clearRect覆盖整个画布在数据量不大时是最简单的方案也是我默认推荐的方案。它的好处是状态永远干净不会有残留。脏矩形是只重绘发生变化的那块区域。在动态图表里如果只是右侧新增了一列数据、左侧淘汰了一列理论上只需要重绘这两条竖带。但实际收益要看场景曲线有横向连线、有坐标轴标签、有十字准线跟随鼠标时脏矩形的计算会变得非常复杂收益可能还不如全量重绘。如果是柱状图的逐条更新或者热力图的局部色块变化脏矩形效果很明显。我的经验是先做全量重绘测出来确实卡了再考虑脏矩形。过早引入脏矩形维护成本会翻倍而且一旦某处漏算就会出现“鬼影”——上一次绘制的内容残留在画布上这种 bug 极难定位。真正更值得先做的是离屏画布分层把静态不动的部分坐标轴、网格线、标题画在一个离屏 canvas 上每帧只把这一层drawImage贴上去动态数据画在另一层。这个改动能把绘制开销砍掉三到五成实现难度却很低。4. 交互与动画的时序争抢缩放、悬停、过渡怎么不打架4.1 过渡动画用插值不要用关键帧库动态图表里的过渡九成场景就是“数值从 A 平滑变到 B”。自己写一个带缓动的插值函数比引入动画库更可控也不会有额外的生命周期管理负担。const easeOutCubic t 1 - Math.pow(1 - t, 3); function makeTransition(from, to, duration) { const start performance.now(); return { step(now) { const t Math.min(1, (now - start) / duration); return from (to - from) * easeOutCubic(t); }, done(now) { return now - start duration; } }; }关键是要给每个可动画的属性单独维护一个 transition 对象新数据到来时不是“推倒重来”而是把当前的实际值作为新的起点重新计算到新目标的过渡。这样即使数据每 200 毫秒来一次、过渡时长 800 毫秒视觉上也是连续跟随的不会跳。这个技巧叫“打断式过渡”是让实时图表看起来“顺”的核心。4.2 缩放平移把变换矩阵想清楚不要到处打补丁很多人做缩放是直接改比例尺的 domain然后在各个地方修补偏移最后代码里一堆offsetX互相打架。正确的做法是引入一个独立的视口变换层把数据和屏幕之间的映射拆成两步数据 → 世界坐标比例尺世界坐标 → 屏幕坐标视口变换。const view { x: 0, y: 0, k: 1 }; // 平移量和缩放系数 function worldToScreen(wx, wy, dpr) { return [ (wx - view.x) * view.k * dpr, (wy - view.y) * view.k * dpr ]; }滚轮缩放时要以鼠标位置为锚点这样才符合直觉。做法是先算出鼠标对应的世界坐标缩放之后再反推平移量保证这个点还在鼠标下面function zoomAt(screenX, screenY, factor, dpr) { const wx screenX / dpr / view.k view.x; const wy screenY / dpr / view.k view.y; view.k Math.min(50, Math.max(0.5, view.k * factor)); view.x wx - screenX / dpr / view.k; view.y wy - screenY / dpr / view.k; }view.k的上下限必须加否则用户疯狂滚轮之后缩放系数变成 1e-9 或者 1e9浮点精度不够图形会直接消失或者糊成一团。上下限的具体数值按业务定通常下限 0.5缩小到一半、上限 50放大 50 倍覆盖大部分场景。4.3 命中检测数据点多了就别线性扫悬停高亮、点击下钻都需要知道鼠标落在哪个数据点上。数据点少于两千个时直接遍历算距离完全没问题一毫秒都用不了。数据量大了之后要换思路。如果数据已经按 x 排序绝大多数时间序列都是可以直接用二分查找定位最近的 x 区间只在前后几个点里找最近的复杂度从 O(n) 降到 O(log n)。再进一步是用网格索引把画布切成比如 40×40 的格子每个格子记录落在里面的点索引鼠标移动时只查鼠标所在格子和相邻格子。这个方案对散点图特别有效实现也就几十行。有个容易被忽略的细节命中检测的半径要跟着缩放系数变。放大之后点与点的间距变大检测半径不变的话会感觉“点不中”缩小之后间距变小半径不变又会感觉“到处都能点中”。我的做法是让检测半径固定为屏幕像素比如 8 像素这样无论怎么缩放手感都是一致的。5. 长时间运行的稳定性泄漏点和降级策略5.1 动态图表最容易漏的四个地方动态可视化的一个特点是“一直开着”。数据看板挂在墙上跑一整周是常态这时候任何微小的泄漏都会被放大。我排查过的泄漏点基本集中在四类事件监听器。窗口resize、scroll、visibilitychange还有画布上的mousemove。每次重建图表时如果没解绑旧实例的回调还挂在全局对象上连同它闭包里引用的整个数据缓冲区一起泄漏。我的做法是统一用一个disposers数组收集解绑函数销毁时一次性执行。观察器。ResizeObserver和IntersectionObserver用完必须disconnect()这个比事件监听更容易忘因为它没有对应的removeEventListener那种直觉。定时器和 rAF。requestAnimationFrame返回的 id 一定要存下来销毁时cancelAnimationFrame。如果循环内部又递归调了 rAF 而没保存 id那就彻底取消不掉了。缓存。很多实现会做“坐标计算结果缓存”“格式化后的标签缓存”用对象做 key 的话很容易无限增长。加一个容量上限或者用WeakMap。5.2 怎么自测有没有泄漏不用等跑一周五分钟就能测个大概。打开开发者工具的内存面板做一次快照然后让图表持续接收数据十分钟再做一次快照对比两次快照之间的对象数量。如果缓冲区大小是固定的、数据量是恒定的两次快照的差异应该很小如果持续增长基本可以确定有泄漏。另一个更直观的指标是帧耗时的趋势。如果单帧耗时随着运行时间缓慢上升即使数据量没变那大概率是某处数组或 Map 在膨胀导致遍历成本变高。5.3 降级策略要提前写好不要等崩了再想我一般准备三级降级按触发条件自动切换触发条件降级动作视觉效果单帧耗时连续 10 帧超过预算抽帧从 30fps 降到 15fps略顿但可接受数据点数超过阈值如 5 万启用更强的聚合按 2 像素列分箱细节减少趋势保留连续超时超过 3 秒切换到静态快照暂停自动刷新显示“点击恢复”停止更新但页面可用第三级降级看着“怂”但在真实场景里非常重要。宁可让用户看到一个明确停止的图表也不要让整个页面卡死到连滚动都不响应。我见过一个页面因为图表把主线程占满用户连关闭按钮都点不动最后只能强杀标签页。6. 上线后才暴露的几个具体问题与修法6.1 高 DPI 屏上图形发虚不是渲染的锅这个问题我第一次遇到时以为是抗锯齿配置不对折腾了很久才发现是画布的物理像素和 CSS 像素没对齐。Canvas 默认的坐标系是按 CSS 像素来的但在 2 倍屏上一个 CSS 像素实际对应 2×2 个物理像素浏览器会把画布内容拉伸上去结果就是模糊。修法是在初始化和 resize 时同步调整function resizeCanvas(canvas, ctx) { const dpr window.devicePixelRatio || 1; const rect canvas.getBoundingClientRect(); // 容器宽度为 0 时直接返回否则会得到 0×0 的画布 if (rect.width 0 || rect.height 0) return; canvas.width Math.round(rect.width * dpr); canvas.height Math.round(rect.height * dpr); canvas.style.width rect.width px; canvas.style.height rect.height px; ctx.setTransform(dpr, 0, 0, dpr, 0, 0); }setTransform这一步把后续所有绘制都自动放大 dpr 倍代码里就可以继续用 CSS 像素思考不用到处乘 dpr。这个写法比手动在每个坐标上乘 dpr 要安全得多因为漏乘一处就会出现错位。另一个坑是devicePixelRatio会变——用户把窗口从笔记本屏幕拖到外接显示器时dpr 可能从 2 变成 1。所以 resize 监听里必须重新读一次 dpr不能缓存。6.2 页面切后台再回来时间轴错乱前面 rAF 模板里提过时间跳变保护这里说完整的处理。除了在帧循环里钳制delta还需要监听页面可见性变化document.addEventListener(visibilitychange, () { if (document.hidden) { cancelAnimationFrame(rafId); rafId null; } else { lastTs performance.now(); acc 0; // 主动拉一次最新数据补齐后台期间的空档 refreshData(); if (!rafId) rafId requestAnimationFrame(frame); } });refreshData()这一句很关键。如果图表的数据源是增量推送的后台期间推送可能被浏览器节流甚至丢弃回来之后缓冲区里有一段空洞。主动拉一次全量或者拉最近一段比让用户看着一条断掉的线要好。如果业务上不允许后台暂停比如必须持续记录那就不能用 rAF 做数据采集得把“采集”和“渲染”彻底分开采集用setInterval在 Worker 里跑Worker 里的定时器节流没那么激进渲染仍然用 rAF。这个拆分思路值得提前设计后面改起来代价很大。6.3 数据突发导致的渲染风暴线上环境的数据不会均匀到达。平时每秒 5 条某个时刻突然涌进来 5000 条如果你的处理逻辑是“每来一条数据触发一次重绘”这一瞬间会排队几千次重绘页面直接假死。解法是把数据写入和渲染解耦数据到达只是往缓冲区里 push同时设一个dirty标记渲染循环每帧检查这个标记有变化才画一帧最多画一次。这样无论数据来得多猛渲染频率的上限被帧率锁死了。let dirty false; function onData(items) { for (const it of items) buffer.push(it); dirty true; } function render() { if (!dirty) return; dirty false; // ... 绘制 }再配合一个“积压检测”如果缓冲区里的数据点超过容量上限的九成说明消费速度跟不上生产速度这时候就主动跳过低价值的数据比如只保留每秒的第一个点而不是无脑丢弃最新的——最新的数据通常用户最关心。6.4 容器尺寸为 0 时的初始化陷阱图表放在 Tab 页或者弹窗里初始化那一刻容器是display: nonegetBoundingClientRect()返回全 0。如果此时按 0 宽高去设置画布尺寸后面容器显示了也不会自动恢复你看到的就是一片空白。标准做法是初始化时不急着算尺寸而是用ResizeObserver监听容器第一次拿到非零尺寸时再做真正的初始化const ro new ResizeObserver(entries { const { width, height } entries[0].contentRect; if (width 0 || height 0) return; if (!initialized) { init(width, height); initialized true; } else { resizeCanvas(canvas, ctx); dirty true; } }); ro.observe(container);这里顺便解决了一个隐藏问题Tab 切换时容器尺寸从 0 变成正常值ResizeObserver会再触发一次正好可以用来重绘不需要额外监听 Tab 的切换事件。7. 一些踩过之后才会记住的经验关于性能优化的顺序我的体会是先把渲染量降下来分箱聚合再把绘制频率降下来帧率上限最后才去抠单次绘制的细节离屏、脏矩形。前两步的收益通常是数量级的第三步是百分之几十。反过来做很容易在细节里耗掉大量时间回头一看瓶颈还在数据量上。关于代码结构我强烈建议把“数据层”和“渲染层”用一条清晰的边界隔开数据层只负责缓冲、聚合、计算值域输出一个纯数据结构的“可绘制快照”渲染层只负责把快照变成像素不碰原始数据。这条边界划清楚之后加新的图表类型、换渲染后端、写单元测试都会容易很多。我吃过反面的亏——早期把所有逻辑揉在一个大函数里后来需求要加一个双 Y 轴改了两天才理清哪部分是数据、哪部分是绘制。关于验证方式别只在自己的显示器上看。至少要在 1 倍屏和 2 倍屏各看一次在窗口缩放几次之后看一次切到别的标签页待一分钟再回来看一次。这三个动作能覆盖掉七成的显示类问题而它们恰恰是本地开发最不容易自然触发的场景。最后分享一个排查卡顿的小技巧如果你不确定卡在哪一步就在渲染循环里把各阶段的耗时打到画布角落上一帧一行颜色区分。眼睛盯着实时数字比翻性能面板快得多而且能直接看到数据量突增时哪一段先红。这个调试开关上线前记得用条件关掉但别删——下一个版本大概率还用得上。