记一次卡顿的性能优化经历实操-Toy模板网

这篇具有很好参考价值的文章主要介绍了记一次卡顿的性能优化经历实操。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

本篇的性能优化不是八股文类的优化方案，而是针对具体场景，具体分析，从排查卡顿根因到一步步寻找解决方案，甚至是规避等方案来最终解决性能问题的经历实操

所以，解决方案可能不通用，不适用于你的场景，但这个解决过程是如何一步步去处理的，解决思路是怎么样的，应该还是可以提供一些参考、借鉴意义的

当然，也许你还有更好的解决方案，也欢迎评论教一下，万分感谢

问题现象

我基于 twaver.js 库实现了一个园区内网络设备的拓扑呈现，连线表示设备间的拓扑关系，线路上支持流动动画、告警动画、链路信息等呈现，如：

记一次卡顿的性能优化经历实操

但当呈现的节点数量超过 1000 后，动画开始有点丢帧，操作有点点滞后感

超过 5000 个节点后，页面就非常的卡顿，难以操作

所以，就开始了性能优化之路

猜测&验证

猜测 1：Vue 框架的响应式处理导致的性能瓶颈

之所以有这个猜测是因为，我在官方给的 demo 上体验时，上万个节点时都不卡顿，更何况是一千个节点而已

而我的项目跟官方 demo 的差异有两块：

我用 vue 框架开发，官方 demo 用的纯 html + js
我功能已经开发完，所以实际上还参杂了其他各种实现的代码，官方 demo 很简单的纯节点和链路

为了验证这个猜想，我另外搞了个空项目，纯粹就只是把官方 demo 的代码迁移到 vue 上运行起来而已，如：

【10000 个节点，20000 条连线，twaver 官方 demo 耗时 250ms，不卡顿】

记一次卡顿的性能优化经历实操

【10000 个节点，20000 条连线，vue 实现的 demo 耗时 11500ms，操作上有 0.5s 的滞后感】

记一次卡顿的性能优化经历实操

同样的代码，同样的数据量，区别仅仅是一个用纯 js 实现，一个用 vue 实现，但两边的耗时差异将近 45 倍

所以就开始思考了，Vue 框架能影响到性能问题的是什么？

无非不就是响应式处理，内部会自动对复杂对象深度遍历去配置 setter, getter 来拦截对象属性的读写

而 twaver 的对象结构又非常复杂，就导致了一堆无效的响应式处理耗时资源：

记一次卡顿的性能优化经历实操

看到没有，twaver 的两个变量 box 和 network，内部结构非常复杂，N 多的内嵌对象，全部都被响应式处理，这占用的资源是非常恐怖的

（注：Vue2.x 版本可以直接在开发者工具面板上查看对象内部是否有 setter 和 getter 就知道这个对象是否有被响应式处理）

但我们其实又不需要它能够响应式，我们只是想使用 twaver 对象的一些 api 而已

那么该怎么来避免 Vue 对这些数据进行的响应式处理呢？

下一章节里再具体介绍解法，至少到这里已经明确了卡顿的根因之一是 Vue 对 twaver 的数据对象进行了响应式处理而引发的性能瓶颈

猜测 2：动画太多导致的性能瓶颈

这个应该是显而易见的根因之一了，每条链路上都会有各种动画，而实现上又是每条链路内部自己维护自己的动画管理器（twaver.Animate）

简单去捞了下 twaver 内部源码实现，动画管理器用了 requestAnimationFrame 来实现动画帧，用了 setTimeout 来实现动画的延迟执行

那么当节点成千上万时，肯定会卡顿，毕竟这么多异步任务

而之所以会这么实现，原因之一是官方给的链路动画 demo 就是这么做的，当初做的时候直接用 demo 方案来实现了

而 demo 显然只是介绍链路动画怎么实现而已，不会给你考虑到极端场景的性能瓶颈问题

那么怎么解决呢？不难，无非就是抽离复用 + 按需刷新思路而已，具体也是下面讲解

猜测 3：一次性呈现的节点链路太多导致的性能瓶颈

这也是显而易见的根因之一，就像长列表问题一样，一次性呈现的节点链路太多了，必然会导致性能瓶颈问题

也不需要去验证了，思考解决方案就行

但这跟长列表实现上有点不太一样，因为 twaver 内部是用 canvas 来绘制节点和链路的，并不是用 dom 绘制，所以虚拟列表那种思路在这里行不通

但本质上的解决都一个样，无非就是一次性没必要呈现这么多节点，因为一屏内又显示不了，没有意义

所以，按照这种思路去寻找解决方案，具体也下面讲讲

猜测 4：dom 节点太多导致的性能瓶颈

虽然 twaver 内部是用 canvas 绘制的节点和链路，但当节点毕竟复杂时，比如：

记一次卡顿的性能优化经历实操

这种时候用 canvas 画不出来，只能用 div 绘制，twaver 也支持 HTMLNode 类型节点，这就意味着也会存在 dom 过多的场景

而 dom 导致的性能问题包括 dom 元素过多，频繁操作 dom

因此解决方案上就是尽量避免创建过多的 dom 元素以及避免频繁操作 dom 即可，具体也下面讲

解决方案

绕过 Vue 的自动对数据模型进行的响应式处理

Vue2.x 框架内部会自动将声明在 data 里的变量进行响应式处理，第一个想到的是尝试用 Object.freeze 来冻结对象，例如：

this.box = Object.freeze(new twaver.ElementBox());

但有两个问题：

Object.freeze 是浅冻结，不是深度冻结，内嵌的对象好像还是会被响应式处理
可能会引发功能异常，因为没法确认三方库内部是否有用到对象的枚举、遍历、扩展等能力

那么还有其他什么方案吗？

如果是 Vue3.x 的话，因为响应式处理是显示调用，就没有这些烦恼了。

至于 Vue2.x，内部自动进行了响应式处理，因此我们需要去源码里看看有没有什么办法可以绕过响应式处理。

注：下面是 Vue 2.7.16 版本的源码

源码里给 data 数据进行响应式处理是在 core/instance/state.ts#initData()

// core/instance/state.ts
function initData(vm: Component) {
  let data: any = vm.$options.data;
  data = vm._data = isFunction(data) ? getData(data, vm) : data || {};
  // 省略判断 data 为对象的代码
  //  ...

  const keys = Object.keys(data);
  const props = vm.$options.props;
  const methods = vm.$options.methods;
  let i = keys.length;
  while (i--) {
    const key = keys[i];
    // 省略判断 data 的字段与 props 或 methods 是否有同名的场景
    // ...

    // 判断变量命名是否是 _ 或 $ 为前缀
    if (!isReserved(key)) {
      proxy(vm, `_data`, key); // 这里是关键之一，把 data 里的对象挂载到外部 vue 组件上
    }
  }
  const ob = observe(data); // 响应式处理 data 数据
  ob && ob.vmCount++;
}

上面的源码里我省略了一些无关的代码，然后有两个关键点，一个是通过 isReserved(key) 判断变量命名是否是以 _ 或 $ 开头的代理处理，另一个是 observe(data) 处理响应式的 data 数据

第一点等会再讲，先来看看是怎么对 data 数据进行响应式处理的：

// core/observer/index.ts
export function observe(
  value: any,
  shallow?: boolean,
  ssrMockReactivity?: boolean
): Observer | void {
  // 如果该对象已经响应式处理过了，就跳过，没必要再次处理
  if (value && hasOwn(value, "__ob__") && value.__ob__ instanceof Observer) {
    return value.__ob__;
  }
  // 当满足下面条件时，对对象进行响应式处理
  if (
    shouldObserve && // 总开关
    (ssrMockReactivity || !isServerRendering()) && // 非服务端渲染场景
    (isArray(value) || isPlainObject(value)) && // 数组或对象
    Object.isExtensible(value) && // 支持扩展（即动态增删字段）
    !value.__v_skip /* ReactiveFlags.SKIP */ && // 是否跳过响应式处理
    !isRef(value) && // // 是否是响应式对象
    !(value instanceof VNode) // 是否是 VNode 对象
  ) {
    // 内部遍历对象的属性，调用 defineReactive() 来对属性进行 setter, getter 拦截
    // 而 setter 里又重新调用 observe() 处理属性值，从而达到深度递归处理内嵌对象属性的响应式效果
    return new Observer(value, shallow, ssrMockReactivity);
  }
}

所以，我们其实是有办法来绕过响应式处理的，比如给对象增加一个要跳过响应式处理的标志 __v_skip，如：

const box = new twaver.ElementBox();
box.__v_skip = true; // 这个是关键
this.box = box;

const network = new twaver.vector.Network(this.box);
network.__v_skip = true; // 这个是关键
this.network = network;

注意：__v_skip是 Vue2.7.x 版本后加入的逻辑，在 Vue2.6 及之前版本里，并没有该逻辑，相反只有一个 _isVue 标志位判断

有人说，不用这么麻烦，把变量命名改成 _ 为前缀，也能绕过响应式处理，这是真的吗？毕竟源码里好像没有看到相关的代码

别急，还记得我上面介绍 initData() 源码里的两个关键点之一的 ``

// core/instance/state.ts
function initData(vm: Component) {
  // 省略其他无关代码
  //  ...
  while (i--) {
    // 省略其他无关代码
    //  ...

    // 判断变量命名是否是 _ 或 $ 为前缀
    if (!isReserved(key)) {
      // 把 data 里的对象挂载到外部 vue 组件上
      proxy(vm, `_data`, key);
    }
  }
  // 省略其他无关代码
  //  ...
}

这里会遍历 data 里的各个属性字段，然后把里面非 _ 或 $ 为前缀的变量都挂到外部 Vue 组件实例上，这样我们代码里才可以直接用 this.xxx 来操作这些变量

由于我们命名了 _box，_network 变量，这些以 _ 开头的变量就没有被挂到 Vue 组件实例上，而后续我们代码里使用 this._box = xxx 这样来赋值变量，其实本质上是动态的往 Vue 组件实例上增加了一个 _box 变量，由于 Vue2.x 不支持对动态添加的属性进行响应式处理，因此这才能达到绕过响应式处理的效果

所以把变量命名改成 _ 为前缀，其实是误打误撞的刚好绕过了响应式处理

Vue 官方文档里其实也有解释说了：

Properties that start with _ or $ will not be proxied on the Vue instance because they may conflict with Vue’s internal properties and API methods. You will have to access them as vm.$data._property

大意就是，Vue 内部变量命名就是以 _ 和 $ 为前缀命名，因此不会把 data 里以 _ 和 $ 开头的变量挂到外部上来，防止变量命名冲突覆盖掉内部变量而引起异常。因此当 data 里有这些变量时，使用时应该要 this.$data._xxx 的方式来操作这些变量

虽然是误打误撞的绕过了响应式处理，但这种方案不会让代码更繁琐，使用上还算方便，就是需要放开 eslint 的 vue/no-reserved-keys 校验规则

【举一反三】

当用到其他一些三方库，三方库变量又不是全局而是当前组件内的局部变量 data 内部时，都会存在被 Vue 响应式处理的问题。

如果你也有遇到这种场景，不防往这方面去考虑看看如果绕过响应式处理

共同复用全局的动画管理器 + 按需刷新

【原实现方案】

每条链路的动画由各自内部实现：

export default function FlowLink() {
  FlowLink.superClass.constructor.apply(this, arguments);
  this._animate = this.getAnimate();
}

twaver.Util.ext(FlowLink, twaver.Link, {
  play: function (options) {
    this._animate.play();
    return this._animate;
  },
  getAnimate: function (options) {
    // 内部自己的动画管理器
    this._animate = new twaver.Animate(
      Object.assign(
        {
          from: 0,
          to: 1,
          repeat: Number.POSITIVE_INFINITY,
          reverse: false,
          delay: 200, // 动画延迟
          dur: 5000, // 动画时才
          easing: "linear", // 线性动画
          onUpdate: (value) => {
            // 更新动画进度
            this.setClient("anim.percent", value);
          },
        },
        options
      )
    );
    return this._animate;
  },
});

而每条链路都是独立的 FlowLink 实例对象，当达到成千上万条链路时，资源就被撑爆了，很卡

【复用全局动画管理器思想】

其实，每条链路内部的动画管理器是一模一样的，那我们其实可以实现一个全局的统一动画管理器，这样不管链路有多少条，我们的动画管理器都只有 1 个

但动画管理器就要有种途径来找到各个链路，这样才能触发链路的刷新，以便它们内部根据最新动画进度来进行渲染

【按需刷新思想】

既然动画管理器内部需要捞取到链路来刷新，那干脆，只捞取屏幕可视范围内的链路进行刷新，屏幕外部的链路就不通知刷新

这样不就更节省性能损耗了

export default function FlowLink() {
  FlowLink.superClass.constructor.apply(this, arguments);
}

twaver.Util.ext(FlowLink, twaver.Link, {
  play: function () {
    // 链路内部不维护动画管理器了，只需要加个动画开关即可
    this.setClient("anim.enable", true);
  },
});

export default class GLobalAnimation {
  constructor(network) {
    this._network = network; // 与动画关联的拓扑画布
    this._linkAnimation = null; // 链路动画实例
    this._linkAnimPercent = 0; // 链路动画进度
  }

  playLinkAnimation() {
    if (!this._linkAnimation) {
      this._linkAnimation = this._initLinkAnimation();
      this._linkAnimation.play();
    }
  }

  _initLinkAnimation() {
    return new twaver.Animate({
      from: 0,
      to: 1,
      repeat: Number.POSITIVE_INFINITY,
      reverse: false,
      delay: 200, // 动画延迟
      dur: 5000, // 动画时才
      easing: "linear", // 线性动画
      onUpdate: (value) => {
        // 只重绘可视范围内的链路
        try {
          const state = this._network.state || {};
          // 滑动、缩放、布局过程中，都没必要更新UI
          const isReady = !state.zooming && !state.panning && !state.layouting;
          if (isReady) {
            // 获取经过缩放后的可视范围
            const viewRect = this._getZoomRect(this._network.getViewRect());
            // 根据可视范围，获取范围内的链路对象
            const nodes = this._network.getElementsAtRect(viewRect, true);
            nodes.forEach((node) => {
              // 刷新指定链路节点
              this._network.invalidateElementUI(node, false);
            });
          }
        } catch (error) {
          console.error("[GlobalAnimation]", error);
        }
      },
    });
  }

  _getZoomRect(rect) {
    const zoom = this._network.getZoom() || 1;
    const offset = 200;
    return {
      x: (rect.x - offset) / zoom,
      y: (rect.y - offset) / zoom,
      width: (rect.width + offset * 2) / zoom,
      height: (rect.height + offset * 2) / zoom,
    };
  }
}

这种思路有点像一开始只站在局部角度来思考代码实现，优化后则是站在全局角度上来进行的思考

而解决思路则是万能的复用，万能的懒加载，按需使用思想