请教一个前端设计及实现问题, 绘制并实时更新 96 个折线图的最佳实践?

程序是这样的:

• 后端维护 96 个通道, 每个通道中有三种需要绘图的数据, 每隔 1s 更新一次.
• 前端则需要将 96 个通道数据绘制在折线图上, 但是不一定全部都挤在一个屏幕显示上.
• 二者交互的数据包含三种浮点数数据和他们对应的时间戳, 二者之间可以通过 ws 通信, 也可通过 ipc 通信.

问题有这些:

• 交互时, 是将 96 个通道数据一起发送好还是单独发送好.
• 前端绘制时选择什么绘图库性能好, 可选交互功能.
• 选择这种前后端分离的架构, 却追求性能, 是不是从一开始就走错了方向? 如果有其他架构, 选择什么样的架构比较合适?

目前我选择的是 tauri+vite+react+highchart(highstock).

我调研的每一个绘图库都吹榜他的性能, 包括上面选择的 highstock.

后端性能没有问题, 交互时后端单独发送数据, 前端使用 debounce.

但是性能却非常糟糕.

好家伙,每秒 96*3 的数据还要时时绘图?这不现实吧,前端折线图这种每次改数据是要重新计算的,你这算得过来吗

echarts 的大数据量绘图还可以啊 。 通道数据在绘图时 是追加到原有数据还是覆盖了所有数据额，覆盖可能会有性能问题，追加的话会好很多。

https://echarts.apache.org/zh/api.html#echartsInstance.setOption 不过我没做过这么大数据量的测试，你可以试试看哈

你说的性能糟糕具体指什么现象

你不如直接丢一份测试数据出来，还有设计图

首先肯定是一起发好，减少连接数 你这数据量到底有多大，能碰到绘图库的性能上限，你先确认一下是数据存的太大内存顶不住了，还是点太多绘制上去有问题，如果是绘制的问题正常的库都会有给数据抽稀的方法，过大的数据直接绘制上去意义不大，我盲猜是数据量过大存不住了，你可以研究一下接一层 bff 做数据整合和抽稀，或者交给后端做 然后前后端分离和追求性能不冲突，如果你觉得是交给客户端的计算量过大可以试试尽量把计算放在 worker 里或者考虑 next 或者 remix 这样的服务端渲染框架

我才看到技术栈里还有个 tauri ，next 或者 remix 当我没说，生产敢用这东西的都是个猛人，打扰了

1.都差不多，但只要前端的主线程没出现堵塞，一起发送更好。websocket 会自己分片，ipc （我不知道你前端的什么 ipc ，只说 electron 的 ipc ）大数据会有一定延迟（ 4k 的 bmp 会有 200ms 左右延迟），但预估你数据量还没那么大。 2.别用 svg ，用 canvas ，绘图的渲染性能都没什么压力的，毕竟都只是 2d 的。我猜测问题可能出在数据处理上，可以用帧循环来将 96 个数据排序提交，减小并发。用 woker 或者 wasm 来优化处理，无论怎样，千万别让主线程卡住了。 3.感觉前后端分不分离和性能没啥联系。 最好还是把问题现象描述的清楚一点，主要不好分析出现在堵在哪儿了

不用 UI 框架的内置 state ，直接调用绘图框架的更新方法更新，绘图框架最好是 canvas 的，这样就只有数据计算过程，没有 vdom 的更新