G6展示网络拓扑图，适配大数据量的方案_g6拓扑图

接手之初，整体样式：

但当数据量变大时，渲染速度慢，且容易卡死浏览器，导致崩溃。大概支持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
          }
        }
      }
    })