接手之初,整体样式:
但当数据量变大时,渲染速度慢,且容易卡死浏览器,导致崩溃。大概支持500个节点。
通过浏览器performance工具分析得知,是由于comboForce(分组力导布局)算法冗余。只能通过更改布局或其他方式规避。
解决方案:
1、创建自定义布局
在原本conboForce的基础上,重新对combo内部的节点布局进行计算。如gird等布局方式。但由于comboForce布局算法对于节点位置的计算同样影响combo的位置。且代码中有很多地方不理解。pass。
2、Gird布局 + 组包裹(Hull)
通过阿里对于容器 云安全可视化的解决方案,文档中是通过包裹的方式,如下图:
优点: 渲染速度快,支持数据量大,5000+。
缺点: 数据量小,且整齐的情况下,效果很好;但是当数据量变大, 组的包裹无法分清,且存在同组内换行的情况。组包裹无法展label。
由于问题点多,继续尝试其他方式。
3、力导布局 + 类聚
在改动过程中发现该布局方式,由于力导布局的算法都会涉及到位置计算,并未报太大希望。
实现结果:
缺点:在渲染之初,力导图会有计算的动画。
优点:支持数量量变大 3000+(相比于最初), 渲染速度快 3000个node,大概35s-45s。且在 3000数据量的情况下,布局正常。
G6配置
const graph = new G6.Graph({
container: "gContain",
width: this.$refs.baro.offsetWidth, // Number,必须,图的宽度
height: this.$refs.baro.offsetHeight, // Number,必须,图的高度
plugins: [tooltip],
autoPaint: true,
fitCenter: false,
modes: {
default: ["drag-combo", { type: "drag-node", onlyChangeComboSize: true }, { type: "drag-canvas", scalableRange: -1 }, "zoom-canvas"]
},
fitView: false,
layout: {
type: "force",
clustering: true,
clusterNodeStrength: -5,
clusterEdgDistance: 200,
clusterNodeSize: 100,
clusterFociStrength: 15,
nodeSpacing: 20,
preventOverlap: true
},
defaultEdge: {
type: "cubic",
style: {
endArrow: true,
stroke: "#c0c0c4"
}
},
defaultNode: {
size: 58,
type: "tenNode",
style: {
opacity: 1,
lineWidth: 1.3,
fill: "#23b899"
}
},
defaultCombo: {
// ... 其他属性
style: {
fill: "#e6e7ea",
lineWidth: 2,
stroke: "#e6e7ea"
// ... 其他属性
},
labelCfg: {
position: "top",
refX: 0,
refY: -20,
style: {
fontSize: 24
}
}
}
})