01Joy

Appearance

风起
风起

从SVG到Canvas的演进与矢量网格的探讨 ​

1. 概述 ​

  • 对于图的编排，只要能做到设计协议与运行协议的映射，就可以用一个设计工具支持多种类型的运行时。
  • 一般的设计工具底层渲染不选择SVG+DOM，主要是出于性能考虑。
  • 越接近渲染底层，技术可控性越强，自由灵活度越高，支持的业务类型越广，所以有实力尽量自研渲染引擎。

2. 背景与问题 ​

2.1. 业务背景 ​

在工业控制与智能编排领域，我们需要支持多种类型的编排场景，包括：算法工具、专家规则、操作导航、工作流及逻辑图等。

算法工具

专家规则

操作导航

工作流

逻辑图

2.2. 核心痛点 ​

随着业务复杂度增加，图编排场景下的节点数量急剧增长，原有的技术架构面临严峻挑战：

  • 性能瓶颈：早期的编排工具多基于SVG+DOM技术栈。实测在节点数量达到2000个时，页面出现严重卡顿甚至假死，无法满足大规模编排需求。
  • 维护困难：针对不同场景使用不同的工具（如bpmn-js, Node-RED），导致技术栈割裂，交互体验不一致，维护成本高昂。

3. 分析与排查 ​

3.1. 技术选型分析 ​

为了解决性能与统一性问题，我们对主流的图编辑框架及底层引擎进行了深度对比分析。

维度AntV GAntV X6bpmn-jsNode-RED
定位底层图表引擎通用图编辑框架BPMN流程编排逻辑图
技术栈Canvas/SVG/WebGLG(SVG)+自研SVGSVG
标准支持自定义JSON自定义JSONBPMN2.0自定义JSON
开箱即用需要封装完整框架完整工具完整工具

3.2. 决策思考 ​

  • 性能优先：AntV-G 支持 Canvas/WebGL 渲染，相比 SVG 方案，在处理大量图元时具有更高的性能上限。
  • 灵活度：越接近渲染底层，技术可控性越强。AntV-G 提供了基础的图形能力，不绑定具体的业务交互，适合我们自研统一的编排引擎。
  • 统一架构：通过自研渲染层，可以实现“一套设计工具支持多种运行时”的目标。

4. 解决方案 ​

4.1. 总体架构设计 ​

我们采用“设计协议与运行协议分离”的架构思想。只要能做到设计协议与运行协议的映射，就可以用一个设计工具支持多种类型的运行时。

项目应用：目前已实现了算法工具（自研运行时）和专家规则（LitFlow运行时）的渲染层统一。

4.2. 功能模块实现 ​

基于AntV-G的底层渲染能力，我们基本实现了一下核心功能模块：

4.2.1. 页面结构 ​

画布、算子库、工具栏、属性配置、信息栏

4.2.2. 画布操作 ​

保存、缩放、对齐、前进/后退、导入/导出/打印

4.2.3. 节点操作 ​

嵌套、成组、拖放、删除、框选、单位移动、复制/剪切/粘贴、参数配置

4.2.4. 连线操作 ​

连线、编辑线条

4.2.5. 文本信息 ​

版权信息、文本注释、算子（引脚别名/引脚实时值/标题/参数/单位/描述/运行信息）

4.2.6. 辅助信息 ​

网格、辅助线、连线分叉标识、小地图

4.2.7. 自定义 ​

自定义节点、自定义连线路由、自定义右键菜单、自定义快捷键、自定义（算子库/工具栏/属性配置/信息栏）、自定义业务数据等

4.2.8. 动态特性 ​

动态改变算子（颜色/引脚个数/引脚别名/引脚实时值/标题/参数/单位/描述/运行信息）

动态改变连线（颜色/断连）

4.3. 协议设计 ​

为了适配不同业务类型的运行时，我们定义了统一的画布、节点和边协议。

javascript
/**
画布协议
*/
{
  nodes: [],
  edges: [],
}

/**
节点协议
*/
{
  id: '',
  shape: {}, // 形状
  ports: [], // 引脚
  data: '', // 业务数据 json-string
}

/**
边协议
*/
{
  id: '',
  shape: {}, // 形状
  source: { // 起点
    cell: '',
    port: '',
  },
  target: { // 终点
    cell: '',
    port: '',
  },
}

/**
业务数据协议
*/
{
  variables: [], // 变量集合
  component: { // 配置组件
    name: '',
    props: {},
  }, 
}

5. 效果与验证 ​

5.1. 性能提升验证 ​

我们对算法工具优化前（SVG）后（Canvas）性能测试，测试场景包括批量创建、批量删除、批量框选、批量移动、连线等操作。

测试结果：在节点数量达到2000个时，SVG方案页面卡死，而基于AntV-G的Canvas方案依然可以正常操作。

5.2. 统一渲染层的价值 ​

  • 设计语言统一：交互风格一致，提升用户体验。
  • 研发效率提升：新的编排类产品可快速集成已封装好的功能。
  • 性能红利共享：优化底层渲染性能，可同时提高所有编排类产品渲染性能上限。
  • 功能复用：扩展新的交互功能，可应用到所有编排类产品上。

5.3. AntV-G简介 ​

G 作为 AntV 底层的渲染引擎，致力于为上层产品提供一致、高性能的 2D / 3D 图形渲染能力，适配 Web 端全部底层渲染 API（Canvas2D / SVG / WebGL / WebGPU / CanvasKit）。特别的，针对图场景下适合并行计算的算法提供GPGPU支持。

AntV-G定位参考

6. 经验总结与延伸思考 ​

6.1. 成功经验 ​

  • 技术选型：对于通用图编排场景，AntV-G是优选方案。它在性能和灵活度上取得了平衡，Canvas渲染在2000节点规模下仍可流畅操作。
  • 架构设计：通过设计协议与运行协议的映射机制，实现了“一套设计工具支持多种运行时”的目标。

6.2. 技术边界与反思：为何不是AntV-G? ​

如果要实现类似Figma这样强大的矢量工具，AntV-G可能不在适用。我们需要从功能和性能两方面重新考虑底层的渲染机制。

矢量网格（Vector Networks）

Figma的矢量图形描述使用的是 矢量网格。

  • 差异：AntV-G 这类图表引擎的图形描述类似SVG（一个个独立的图形对象），而矢量网格协议对上支撑各种复杂的路径编辑功能，对下描述如何渲染。
  • 结论：若业务需求涉及复杂的矢量路径编辑（如专业绘图工具），应考虑基于矢量网格的自研引擎。

参考：Figma Vector Networks: 重新定义矢量图形编辑

地址：https://01joy.com/rww/figma-vector-networks.html

渲染性能上限

浏览器提供的渲染方式：DOM+SVG、Canvas、WebGL、WebGPU。

虽然Canvas解决了SVG的DOM性能瓶颈，但对于极致性能或3D场景，WebGPU是未来的方向。选择哪种渲染方式决定了性能优化的上限。

参考：自研矢量引擎为什么不选择SVG

地址：https://01joy.com/rww/svg-webgpu.html

7. 总结 ​

基于AntV-G的编排工具技术方案为大多数企业级编排工具提供了一个务实且高效的技术底座。技术选型需要在性能上限、开发效率、业务适配度之间找到平衡点。

Copyright 2025 zxhsure@163.com