云顾问编辑器性能优化总结（一期）

优化场景

基于用户反馈及体验测试，当前架构图存在三大核心性能瓶颈：

1. 初始化渲染耗时高：大型架构图（500+节点）渲染时间长达几秒
2. 交互流畅度不足：节点拖拽时帧率低于30FPS，600节点场景下卡顿明显
3. 自动生图性能差：复杂架构图生成时易导致浏览器假死

优化目标：

• 初始化渲染时间降低至200ms以内（500节点）
• 拖拽操作帧率稳定在50+FPS，大图稳定在30+FPS
• 自动生图耗时减少50%以上优化方案架构图初始化渲染这里我们要优化的是，从接口获取到架构图详情，到用户看到架构图渲染完成的耗时，优化之前，需要梳理架构图的渲染流程。

架构图保存的结构大致是这样的：:

const detail = {
	'key1': {
		name: 'node1',
		position: {x:0, y:0},
		type: 'product,
	},
	'key2': {
		name: 'node2',
		position: {x:0, y:0},
		type: 'group,
	},
}
...

渲染的时候就是一个个节点依次渲染到画布上，所以优化方案就很明确，这里只要把渲染耗时异常的节点类型优化掉就可以了。

此外，对于用户不可见的逻辑，执行不执行对于用户是视野里看不到的，而这段逻辑执行的过程中，大概率用户也操作不到这块逻辑对应的功能，因此没这部分逻辑完全可以放在渲染架构图之后去执行。

具体优化措施

1. 耗时打点 console.time对每种类型节点的渲染进行耗时打点，筛选出耗时最高的类型，排查耗时异常点。
2. 异常排查 1）排查出Line折线类型节点，每次初始化的时候都会重新利用A* 算法自动寻路，寻路是很耗时的操作，这块逻辑可以干掉，直接用已有数据渲染即可； 2）产品类型节点如cvm等，在初始化的时候都是需要根据是否绑定资源修改颜色的，也就是初始化渲染之后，根据是否绑定资源再触发一次渲染，发现了这个问题处理起来也很简单，修改sigma编辑器的底层逻辑，把两次渲染合并为一次，这也有效的提升了整体的渲染耗时； 3）再就是组类型节点，初始化渲染的时候，也渲染了缩放点等，在插件模式不可见的元素，那么把这块逻辑移到渲染架构图之后执行即可。
3. 其他优化 节点的渲染通过步骤2排查优化一遍后，梳理节点渲染之外的逻辑，对于节点排序算法进行优化，提升排序效率、部分事件注册在渲染逻辑之后，数据预处理逻辑优化等。

优化效果

根据代码逻辑以及耗时监控得出结论:

1. 节点数越多，耗时越久
2. 电脑性能越差，耗时越久

架构图操作卡顿

首先要了解，用户为什么会感觉卡，浏览器一般是60帧，一秒完成60次渲染则丝滑，否则帧率越低，用户感觉越卡顿，如下图所示，可以看到浏览器每一帧都做了哪些内容。

浏览器渲染流程

我们要处理的就是Main Thread,这个线程最有可能导致卡顿，主要是因为这里运行了太多任务，比如某个函数需要100ms执行完，那么这100ms浏览器就是卡死的状态。

优化思路

知道了卡顿原因，优化就好办了，尽可能减少每一帧执行js的耗时就可以了，这里需要重点针对拖拽节点的逻辑进行处理，同样的首先整理拖拽的逻辑链路，核心在mousemove这个函数的处理，卡顿就是每一次mousemove的js运算逻辑过多，超过16.6ms。

mousemove逻辑链路

1. 计算diff
2. 计算是否会移出画布边界，会则不继续向下走
3. 对需要更新的节点触发position-change
4. 更新这些节点
5. 计算当前是否有需要加入的组

数理逻辑后发现每次移动鼠标频繁触发这个逻辑链路，其中，步骤四和五是耗时异常高的，那么针对这两个环节进行优化。

耗时异常排查

这里我们通过浏览器的perfaomance工具录制移动节点操作，查看函数调用栈找内鬼。

preformance分析工具

排查下来发现update/mousemove函数耗时最高，接下来对这部分逻辑进行优化。

优化措施

1）update

检查发现，中间cloneDeep耗时最高，功能需要对节点每个属性深克隆，每个节点几十个属性，几十上百个节点就要深克隆几千次，而该函数耗时又是比较高的，进一步排查发现，很多属性是无需深克隆的，因此代码逻辑修改为如下的伪代码:

try {
    // 很多字段无需深克隆
	if (NOT_NEED_CLONE_PROPERTY.includes(k)) {
	  shape[k] = vnode[k];
	} else {
	  shape[k] = structuredClone(vnode[k]);
	}
	} catch (e) {
	// 出现克隆异常全用cloneDeep处理
	shape[k] = cloneDeep(vnode[k]);
}

这极大减少了深克隆调用次数，需要克隆使用性能更佳的structuredClone，克隆频率降低了70%。

2）mousemove

第一个优化项：__handleRelationsWhenMove耗时是最高的，该函数功能是移动节点的时候检测是否有需要加入的组，很明显该功能不必在每次移动的时候都触发检测，只需要在快要停止移动的时候触发检测就可以了。

// 耗时高的操作待用户快停下的时候再触发
if (Math.abs(diff.x) < 1 && Math.abs(diff.y) < 1) {
  this.__handleRelationsWhenMove(checkedNodes);
}

第二个优化项:

mousemove触发频率过高，每秒触发一百五十次以上，对于浏览器环境，其实每秒60帧就是丝滑的，因此，做一个限频处理，每秒最多处理60次，伪代码如下所示:

const optMove = throttle((ev) => {
	if (isMoving || isMouseUp) return;

	isMoving = true;

	rafId = requestAnimationFrame(() => {
	  mouseMove(ev);
	  isMoving = false;
	});
}, 16);

第三个优化项:

mousemove的时候频繁触发了折线的findPath自动寻路，这里其实也是不必要的，对折线的拐点(x,y)修改为(x+diff.x,y+diff.y)就可以了，把这个逻辑进行梳理优化，对于同时移动较多折线的场景也得到了较大的提升。

优化效果

根据代码逻辑以及耗时监控得出结论:

1. 同时拖拽节点数越多，每次移动耗时越久
2. 电脑性能越差，每次移动耗时越久

（MAC M4 芯片电脑数据，电脑不同数据可能有差异）

帧率能够达到 50 ～ 60 FPS 的动画将会相当流畅，让人倍感舒适；

帧率在 30 ～ 50 FPS 之间的动画，因各人敏感程度不同，舒适度因人而异；

帧率在 30 FPS 以下的动画，让人感觉到明显的卡顿和不适感；

帧率波动很大的动画，亦会使人感觉到卡顿。

可以看到同时移动300节点以内，可以达到40帧，相对来说是比较丝滑的，同时移动600节点有17帧左右，是能用但是感到卡顿的，99%的场景用户同时移动的节点在100个以内，所以基本不会出现卡顿的问题，而少部分场景同时移动操作300节点以上，也能保证基本的移动需求，后续会对这里持续优化。

自动生图效率优化

这里同样使用浏览器的performance排查耗时异常高的函数，排查发现setBaseGroup函数耗时最高，检查生图逻辑，逻辑如下图所示:

1. 绘制最外层组
2. 绘制组内节点（很多则重复2-3的步骤）
3. 组内节点加入组
4. 绘制组内节点的组内节点（如果有则重复1-3的逻辑）

这里的逻辑步骤执行次数过多，如果组内节点有一百个，那么要执行一百次加入组的函数，我们可以把这一百次函数用一次批量执行的函数完成操作，即改变执行策略:

1. 绘制最外层组
2. 绘制组内节点，添加到待加入组队列
3. 批量将组内节点加入组
4. 绘制组内节点的组内节点（如果有则重复1-3的逻辑）

这样就极大的降低了函数执行次数，有效提升了是自动生图效率。

优化效果

自动生图平均耗时降低了50%

二期优化项

1. 自动生图效率仍需提升，在性能普通的电脑上自动生成大批量节点（500+）可能导致浏览器卡死。
2. sigma编辑器操作不断地有小bug被反馈，需要把目前发现的问题及时处理掉。
3. 大批量操作节点如同时移动300+节点，性能不好的电脑会感到卡顿，仍需持续优化。
4. 视野外的节点降级渲染。

最后

如果使用云顾问编辑架构图遇到什么bug，请及时反馈，万分感谢。