前端tree组件，10000个树节点，从12.19s到0.49s

时间 2019-11-09

标签前端 tree 组件树节点 12.19s 0.49s 繁體版

原文原文链接

全篇思想：

递归的本质是栈的读取

如下都是基于10000条子节点数据做对比
css

先看效果对比：

递归版tree，渲染速度: 12.19s，点击节点处理速度: 9.52s
优化版tree，渲染速度: 0.49s，点击节点处理速度: 0.18s
vue

递归组件实现tree：渲染速度 13.75s -1.56s = 12.19s

递归组件版tree性能图-1node

递归组件版tree点击节点性能分析图：点击节点处理速度: 9.64s - 0.117s = 9.523s ≈ 9.52s算法

递归版tree点击节点性能图-2

优化版tree: 渲染速度2.54s - 2.05s = 0.49s数组

优化版tree性能图-3

优化版tree点击节点性能分析图：点击节点处理速度2.53s - 2.35s = 0.18sbash

优化版tree点击节点性能图-4

最终对比是：数据结构

递归版tree，渲染速度: 12.19s，点击节点处理速度: 9.52s
优化版tree，渲染速度: 0.49s，点击节点处理速度: 0.18s

分析问题

咱们能够借助performance分析一下递归组件的耗时点所在，上递归组件渲染的性能分析：dom

一、script耗时分析：post

递归tree script性能分析图-5

经过图-1性能瀑布能够清晰的看到script执行占了8.9s的时间，经过上图即图-5能够看到script的的调用栈主要集中在建立vue实例时的createChildren上面。
性能

二、render耗时分析：

递归tree render性能分析图-6

经过上图即图-6能够清晰的看到render耗时主要集中在Recalculate Style、Layout上面。咱们知道Recalculate Style、Layout主要是样式计算，所以查看代码：

递归组件部分代码图-7

发如今递归的tree-node组件里面有不少样式的计算，10000条子节点就须要计算10000次。

三、DOM结构分析：

递归组件DOM结构图-8

由上图即图-8咱们能够看出递归组件生成的DOM结构也相应是嵌套的结构，所以DOM不只有纵向的结构也同时有嵌套层次的结构，所以这时控制DOM的数量很难。

由上面的script、render、DOM结构的分析，能够看出问题症结所在：建立vue实例过多！

所以咱们若是要优化，那么只要减小vue实例的建立，那么问题就获得了解决，所以接下来来看是如何实现的。

实现思想

来看咱们的开篇思想：

递归的本质是栈的读取

在算法中咱们会遇到不少递归实现的案例，全部的递归均可以转换成非递归实现，其中转换的本质是：递归是解析器(引擎)来帮咱们作了栈的存取，非递归是手动建立栈来模拟栈的存取过程。

万物都是相通的，递归组件也能够转换成扁平数组来实现：

一、更改DOM结构成平级结构，点击节点以及节点的视觉样式经过操做总的list数据去实现

二、而后使用虚拟长列表来控制vue子组件实例建立的数量。

优化版实现

主要分为两部分功能:

一、tree数据和DOM结构的扁平化
二、虚拟长列表控制DOM渲染数量

一、tree数据和DOM结构的扁平化

优化版tree的DOM结构图-9

由上图咱们能够看到通过改造以后的tree的DOM结构，父节点和子节点是平级的，在操做子节点时去操做内存中的listData数据来改变相关联节点的状态。

咱们再看下listData数据的结构，：

优化版tree listData数据结构图-10

上图即图-10结合图-9的DOM结构能够对整个功能的实现逻辑一目了然：

listData中的每一项的style、checked、path等信息来描述节点的样式位置和状态，操做一个节点时经过listData更改相关节点的状态样式等信息。

所以最终来写咱们的代码：

实现.vue代码图-11

咱们再看下handleCheckChange的作了什么：

handleCheckChange处理逻辑图-12

handleCheckChange 处理了父节点和子节点的check和半选状态，一切都是操做的listData中的数据。

如今咱们是把全部listData都经过循环渲染出来，其实咱们能够只渲染可视区的节点数据。

listData数据的扁平化及DOM的扁平化为接下来咱们接入虚拟长列表的功能提供了可能。

二、虚拟长列表控制DOM渲染数量

实现思路：

根节点DOM分红两个子节点：fui-tree__phantom 和 fui-tree__content

两个子节点都是绝对定位，为了在滚动时避免数据的更改回头触发滚动事件

虚拟列表DOM组织结构图-13

根节点解两个子节点css：

.fui-tree {
    height: 400px;
    overflow: auto;
    position: relative;
  }

  .fui-tree__phantom {
    position: absolute;
    left: 0;
    top: 0;
    right: 0;
    z-index: -1;
  }

  .fui-tree__content {
    left: 0;
    right: 0;
    top: 0;
    position: absolute;
  }
复制代码

而后咱们经过滚动条的位置来计算咱们应该要取哪些数据。

主要代码：

计算可视区数据的起止索引index图-14

经过startIndex、endIndex能够取出咱们须要循环的数据列表renderNodes:

computed: {
      renderNodes() {
        if (!this.treeNode) return []
        return this.treeNode.listData.slice(this.positionConfig.startIndex, this.positionConfig.endIndex)
      },
      phantomStyle() {
        return {
          height: this.allListLen * 20 + 'px'
        }
      }
    }
复制代码

结合图-11的v-for，这样咱们在渲染时的dom数量是固定的条数，以下图：

优化版tree DOM数量是固定的图-15

虚拟列表的接入可让即便再多数据量也能渲染固定的DOM数量，这样就能够支撑更大数据的渲染和功能。

以上咱们实现了业务需求的大数据渲染，目前测试可支撑到20w条节点，点击子节点时会有肉眼可见的延迟，主要是图-12中handleCheckChange的数据查找和处理，这块还有必定的优化空间：使用字典树存储节点相关信息，字典树和扁平数组listData的每个元素指向同一个内存地址，在handleCheckChange中经过操做字典树来达到操做listData的元素的效果，经典的空间换时间的案例。

欢迎关注叶雨森的知乎专栏：zhuanlan.zhihu.com/p/55528376

参考：

zhuanlan.zhihu.com/p/34585166

juejin.im/post/5c4154…