本篇的性能優(yōu)化不是八股文類的優(yōu)化方案，而是針對具體場景，具體分析，從排查卡頓根因到一步步尋找解決方案，甚至是規(guī)避等方案來最終解決性能問題的經(jīng)歷實操

所以，解決方案可能不通用，不適用于你的場景，但這個解決過程是如何一步步去處理的，解決思路是怎么樣的，應(yīng)該還是可以提供一些參考、借鑒意義的

當(dāng)然，也許你還有更好的解決方案，也歡迎評論教一下，萬分感謝

問題現(xiàn)象

我基于 twaver.js 庫實現(xiàn)了一個園區(qū)內(nèi)網(wǎng)絡(luò)設(shè)備的拓?fù)涑尸F(xiàn)，連線表示設(shè)備間的拓?fù)潢P(guān)系，線路上支持流動動畫、告警動畫、鏈路信息等呈現(xiàn)，如：

但當(dāng)呈現(xiàn)的節(jié)點數(shù)量超過 1000 后，動畫開始有點丟幀，操作有點點滯后感

超過 5000 個節(jié)點后，頁面就非常的卡頓，難以操作

所以，就開始了性能優(yōu)化之路

猜測&驗證

猜測 1：Vue 框架的響應(yīng)式處理導(dǎo)致的性能瓶頸

之所以有這個猜測是因為，我在官方給的 demo 上體驗時，上萬個節(jié)點時都不卡頓，更何況是一千個節(jié)點而已

而我的項目跟官方 demo 的差異有兩塊：

• 我用 vue 框架開發(fā)，官方 demo 用的純 html + js
• 我功能已經(jīng)開發(fā)完，所以實際上還參雜了其他各種實現(xiàn)的代碼，官方 demo 很簡單的純節(jié)點和鏈路

為了驗證這個猜想，我另外搞了個空項目，純粹就只是把官方 demo 的代碼遷移到 vue 上運行起來而已，如：

【10000 個節(jié)點，20000 條連線，twaver 官方 demo 耗時 250ms，不卡頓】

【10000 個節(jié)點，20000 條連線，vue 實現(xiàn)的 demo 耗時 11500ms，操作上有 0.5s 的滯后感】

同樣的代碼，同樣的數(shù)據(jù)量，區(qū)別僅僅是一個用純 js 實現(xiàn)，一個用 vue 實現(xiàn)，但兩邊的耗時差異將近 45 倍

所以就開始思考了，Vue 框架能影響到性能問題的是什么？

無非不就是響應(yīng)式處理，內(nèi)部會自動對復(fù)雜對象深度遍歷去配置 setter, getter 來攔截對象屬性的讀寫

而 twaver 的對象結(jié)構(gòu)又非常復(fù)雜，就導(dǎo)致了一堆無效的響應(yīng)式處理耗時資源：

看到?jīng)]有，twaver 的兩個變量 box 和 network，內(nèi)部結(jié)構(gòu)非常復(fù)雜，N 多的內(nèi)嵌對象，全部都被響應(yīng)式處理，這占用的資源是非常恐怖的

（注：Vue2.x 版本可以直接在開發(fā)者工具面板上查看對象內(nèi)部是否有 setter 和 getter 就知道這個對象是否有被響應(yīng)式處理）

但我們其實又不需要它能夠響應(yīng)式，我們只是想使用 twaver 對象的一些 api 而已

那么該怎么來避免 Vue 對這些數(shù)據(jù)進行的響應(yīng)式處理呢？

下一章節(jié)里再具體介紹解法，至少到這里已經(jīng)明確了卡頓的根因之一是 Vue 對 twaver 的數(shù)據(jù)對象進行了響應(yīng)式處理而引發(fā)的性能瓶頸

猜測 2：動畫太多導(dǎo)致的性能瓶頸

這個應(yīng)該是顯而易見的根因之一了，每條鏈路上都會有各種動畫，而實現(xiàn)上又是每條鏈路內(nèi)部自己維護自己的動畫管理器（twaver.Animate）

簡單去撈了下 twaver 內(nèi)部源碼實現(xiàn)，動畫管理器用了 requestAnimationFrame 來實現(xiàn)動畫幀，用了 setTimeout 來實現(xiàn)動畫的延遲執(zhí)行

那么當(dāng)節(jié)點成千上萬時，肯定會卡頓，畢竟這么多異步任務(wù)

而之所以會這么實現(xiàn)，原因之一是官方給的鏈路動畫 demo 就是這么做的，當(dāng)初做的時候直接用 demo 方案來實現(xiàn)了

而 demo 顯然只是介紹鏈路動畫怎么實現(xiàn)而已，不會給你考慮到極端場景的性能瓶頸問題

那么怎么解決呢？不難，無非就是抽離復(fù)用 + 按需刷新思路而已，具體也是下面講解

猜測 3：一次性呈現(xiàn)的節(jié)點鏈路太多導(dǎo)致的性能瓶頸

這也是顯而易見的根因之一，就像長列表問題一樣，一次性呈現(xiàn)的節(jié)點鏈路太多了，必然會導(dǎo)致性能瓶頸問題

也不需要去驗證了，思考解決方案就行

但這跟長列表實現(xiàn)上有點不太一樣，因為 twaver 內(nèi)部是用 canvas 來繪制節(jié)點和鏈路的，并不是用 dom 繪制，所以虛擬列表那種思路在這里行不通

但本質(zhì)上的解決都一個樣，無非就是一次性沒必要呈現(xiàn)這么多節(jié)點，因為一屏內(nèi)又顯示不了，沒有意義

所以，按照這種思路去尋找解決方案，具體也下面講講

猜測 4：dom 節(jié)點太多導(dǎo)致的性能瓶頸

雖然 twaver 內(nèi)部是用 canvas 繪制的節(jié)點和鏈路，但當(dāng)節(jié)點畢竟復(fù)雜時，比如：

這種時候用 canvas 畫不出來，只能用 div 繪制，twaver 也支持 HTMLNode 類型節(jié)點，這就意味著也會存在 dom 過多的場景

而 dom 導(dǎo)致的性能問題包括 dom 元素過多，頻繁操作 dom

因此解決方案上就是盡量避免創(chuàng)建過多的 dom 元素以及避免頻繁操作 dom 即可，具體也下面講

解決方案

繞過 Vue 的自動對數(shù)據(jù)模型進行的響應(yīng)式處理

Vue2.x 框架內(nèi)部會自動將聲明在 data 里的變量進行響應(yīng)式處理，第一個想到的是嘗試用 Object.freeze 來凍結(jié)對象，例如：

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

但有兩個問題：

• Object.freeze 是淺凍結(jié)，不是深度凍結(jié)，內(nèi)嵌的對象好像還是會被響應(yīng)式處理
• 可能會引發(fā)功能異常，因為沒法確認(rèn)三方庫內(nèi)部是否有用到對象的枚舉、遍歷、擴展等能力

那么還有其他什么方案嗎？

如果是 Vue3.x 的話，因為響應(yīng)式處理是顯示調(diào)用，就沒有這些煩惱了。

至于 Vue2.x，內(nèi)部自動進行了響應(yīng)式處理，因此我們需要去源碼里看看有沒有什么辦法可以繞過響應(yīng)式處理。

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

源碼里給 data 數(shù)據(jù)進行響應(yīng)式處理是在 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); // 這里是關(guān)鍵之一，把 data 里的對象掛載到外部 vue 組件上
    }
  }
  const ob = observe(data); // 響應(yīng)式處理 data 數(shù)據(jù)
  ob && ob.vmCount++;
}

上面的源碼里我省略了一些無關(guān)的代碼，然后有兩個關(guān)鍵點，一個是通過 isReserved(key) 判斷變量命名是否是以 _ 或 $ 開頭的代理處理，另一個是 observe(data) 處理響應(yīng)式的 data 數(shù)據(jù)

第一點等會再講，先來看看是怎么對 data 數(shù)據(jù)進行響應(yīng)式處理的：

// core/observer/index.ts
export function observe(
  value: any,
  shallow?: boolean,
  ssrMockReactivity?: boolean
): Observer | void {
  // 如果該對象已經(jīng)響應(yīng)式處理過了，就跳過，沒必要再次處理
  if (value && hasOwn(value, "__ob__") && value.__ob__ instanceof Observer) {
    return value.__ob__;
  }
  // 當(dāng)滿足下面條件時，對對象進行響應(yīng)式處理
  if (
    shouldObserve && // 總開關(guān)
    (ssrMockReactivity || !isServerRendering()) && // 非服務(wù)端渲染場景
    (isArray(value) || isPlainObject(value)) && // 數(shù)組或?qū)ο?    Object.isExtensible(value) && // 支持?jǐn)U展（即動態(tài)增刪字段）
    !value.__v_skip /* ReactiveFlags.SKIP */ && // 是否跳過響應(yīng)式處理
    !isRef(value) && // // 是否是響應(yīng)式對象
    !(value instanceof VNode) // 是否是 VNode 對象
  ) {
    // 內(nèi)部遍歷對象的屬性，調(diào)用 defineReactive() 來對屬性進行 setter, getter 攔截
    // 而 setter 里又重新調(diào)用 observe() 處理屬性值，從而達到深度遞歸處理內(nèi)嵌對象屬性的響應(yīng)式效果
    return new Observer(value, shallow, ssrMockReactivity);
  }
}

所以，我們其實是有辦法來繞過響應(yīng)式處理的，比如給對象增加一個要跳過響應(yīng)式處理的標(biāo)志 __v_skip，如：

const box = new twaver.ElementBox();
box.__v_skip = true; // 這個是關(guān)鍵
this.box = box;

const network = new twaver.vector.Network(this.box);
network.__v_skip = true; // 這個是關(guān)鍵
this.network = network;

注意：__v_skip是 Vue2.7.x 版本后加入的邏輯，在 Vue2.6 及之前版本里，并沒有該邏輯，相反只有一個 _isVue 標(biāo)志位判斷

有人說，不用這么麻煩，把變量命名改成 _ 為前綴，也能繞過響應(yīng)式處理，這是真的嗎？畢竟源碼里好像沒有看到相關(guān)的代碼

別急，還記得我上面介紹 initData() 源碼里的兩個關(guān)鍵點之一的 ``

// core/instance/state.ts
function initData(vm: Component) {
  // 省略其他無關(guān)代碼
  //  ...
  while (i--) {
    // 省略其他無關(guān)代碼
    //  ...

    // 判斷變量命名是否是 _ 或 $ 為前綴
    if (!isReserved(key)) {
      // 把 data 里的對象掛載到外部 vue 組件上
      proxy(vm, `_data`, key);
    }
  }
  // 省略其他無關(guān)代碼
  //  ...
}

這里會遍歷 data 里的各個屬性字段，然后把里面非 _ 或 $ 為前綴的變量都掛到外部 Vue 組件實例上，這樣我們代碼里才可以直接用 this.xxx 來操作這些變量

由于我們命名了 _box，_network 變量，這些以 _ 開頭的變量就沒有被掛到 Vue 組件實例上，而后續(xù)我們代碼里使用 this._box = xxx 這樣來賦值變量，其實本質(zhì)上是動態(tài)的往 Vue 組件實例上增加了一個 _box 變量，由于 Vue2.x 不支持對動態(tài)添加的屬性進行響應(yīng)式處理，因此這才能達到繞過響應(yīng)式處理的效果

所以把變量命名改成 _ 為前綴，其實是誤打誤撞的剛好繞過了響應(yīng)式處理

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 內(nèi)部變量命名就是以 _ 和 $ 為前綴命名，因此不會把 data 里以 _ 和 $ 開頭的變量掛到外部上來，防止變量命名沖突覆蓋掉內(nèi)部變量而引起異常。因此當(dāng) data 里有這些變量時，使用時應(yīng)該要 this.$data._xxx 的方式來操作這些變量

雖然是誤打誤撞的繞過了響應(yīng)式處理，但這種方案不會讓代碼更繁瑣，使用上還算方便，就是需要放開 eslint 的 vue/no-reserved-keys 校驗規(guī)則

【舉一反三】

當(dāng)用到其他一些三方庫，三方庫變量又不是全局而是當(dāng)前組件內(nèi)的局部變量 data 內(nèi)部時，都會存在被 Vue 響應(yīng)式處理的問題。

如果你也有遇到這種場景，不防往這方面去考慮看看如果繞過響應(yīng)式處理

共同復(fù)用全局的動畫管理器 + 按需刷新

【原實現(xiàn)方案】

每條鏈路的動畫由各自內(nèi)部實現(xiàn)：

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) {
    // 內(nèi)部自己的動畫管理器
    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 實例對象，當(dāng)達到成千上萬條鏈路時，資源就被撐爆了，很卡

【復(fù)用全局動畫管理器思想】

其實，每條鏈路內(nèi)部的動畫管理器是一模一樣的，那我們其實可以實現(xiàn)一個全局的統(tǒng)一動畫管理器，這樣不管鏈路有多少條，我們的動畫管理器都只有 1 個

但動畫管理器就要有種途徑來找到各個鏈路，這樣才能觸發(fā)鏈路的刷新，以便它們內(nèi)部根據(jù)最新動畫進度來進行渲染

【按需刷新思想】

既然動畫管理器內(nèi)部需要撈取到鏈路來刷新，那干脆，只撈取屏幕可視范圍內(nèi)的鏈路進行刷新，屏幕外部的鏈路就不通知刷新

這樣不就更節(jié)省性能損耗了

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

twaver.Util.ext(FlowLink, twaver.Link, {
  play: function () {
    // 鏈路內(nèi)部不維護動畫管理器了，只需要加個動畫開關(guān)即可
    this.setClient("anim.enable", true);
  },
});

export default class GLobalAnimation {
  constructor(network) {
    this._network = network; // 與動畫關(guān)聯(lián)的拓?fù)洚嫴?    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) => {
        // 只重繪可視范圍內(nèi)的鏈路
        try {
          const state = this._network.state || {};
          // 滑動、縮放、布局過程中，都沒必要更新UI
          const isReady = !state.zooming && !state.panning && !state.layouting;
          if (isReady) {
            // 獲取經(jīng)過縮放后的可視范圍
            const viewRect = this._getZoomRect(this._network.getViewRect());
            // 根據(jù)可視范圍，獲取范圍內(nèi)的鏈路對象
            const nodes = this._network.getElementsAtRect(viewRect, true);
            nodes.forEach((node) => {
              // 刷新指定鏈路節(jié)點
              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,
    };
  }
}

這種思路有點像一開始只站在局部角度來思考代碼實現(xiàn)，優(yōu)化后則是站在全局角度上來進行的思考

而解決思路則是萬能的復(fù)用，萬能的懶加載，按需使用思想

交互上進行規(guī)避，如增加默認(rèn)折疊、展開處理

由于節(jié)點是直接借助 twaver 內(nèi)部的 canvas 實現(xiàn)，因此節(jié)點數(shù)量太多導(dǎo)致的性能瓶頸問題是 twaver 庫本身就存在的問題，雖然 twaver 已經(jīng)做到 1W 級別的節(jié)點的絲滑呈現(xiàn)，但當(dāng)數(shù)量繼續(xù)加上去，達到 5W，10W 級別時，也會開始出現(xiàn)操作滯后感，卡頓等性能瓶頸

也許你會說，簡單，跟上個問題一樣，按需加載不就行了，只繪制屏幕可視范圍內(nèi)的節(jié)點，其余節(jié)點不繪制

理論上可行，但實現(xiàn)上難度很大

因為上一個問題是節(jié)點鏈路已經(jīng)繪制完畢的基礎(chǔ)上，來進行刷新范圍的過濾，所以只需要根據(jù)坐標(biāo)點信息的計算就能達到訴求

但現(xiàn)在場景是還沒繪制，你沒法獲知任何信息

你不知道經(jīng)過縮放、拖拽后的當(dāng)前視圖里，到底應(yīng)該呈現(xiàn)哪些節(jié)點

而且，twaver 是付費框架，源碼是混淆的，你不知道內(nèi)部它是怎么實現(xiàn)的，無法參與節(jié)點的排版過程，也導(dǎo)致你很難下手去實現(xiàn)所謂的按需繪制問題

再者，我們還有搜索定位的交互需求，就算你上面問題都解決了，那當(dāng)搜索的節(jié)點是沒繪制的節(jié)點，你如何去定位到該節(jié)點真實的位置

基于以上種種原因，考慮到投入成本的性價比，我們最終決定采用從非技術(shù)角度去優(yōu)化：從交互上進行規(guī)避

• 增加節(jié)點的默認(rèn)折疊處理方案，當(dāng)超過一定數(shù)量時，默認(rèn)把子孫節(jié)點折疊起來，這樣能夠避免一次性渲染太多節(jié)點
• 同時增加展開/折疊全部節(jié)點的快捷操作
• 由于孤點沒有樹形結(jié)構(gòu)，因此當(dāng)超過一定數(shù)量孤點時，需要另外處理折疊邏輯
• 搜索節(jié)點時，發(fā)現(xiàn)節(jié)點處于折疊狀態(tài)的話，要自動進行展開處理

簡單來說就是會設(shè)定一個閾值，當(dāng)節(jié)點超過這個數(shù)量時，都折疊起來，等用戶手動去展開再呈現(xiàn)，相當(dāng)于分頁呈現(xiàn)的思想

dom 節(jié)點的懶創(chuàng)建 + 緩存和復(fù)用

有些復(fù)雜節(jié)點的場景無法用 twaver 的默認(rèn)節(jié)點樣式呈現(xiàn)，也就用不了 canvas 實現(xiàn)，只能自己用 html 方式來實現(xiàn)

但也不可能用純 html + js 實現(xiàn)，還是依賴于 vue 框架，這就涉及到 vue 組件的手動創(chuàng)建、掛載、銷毀

這種復(fù)雜節(jié)點過多時，就會涉及到 dom 元素的反復(fù)創(chuàng)建、銷毀以及渲染過多的性能瓶頸問題

那么解決方案上，一樣也是懶加載，但為了組件可以復(fù)用，增加了緩存和復(fù)用處理，避免相同組件要重復(fù)創(chuàng)建

具體做法則是：

• 重寫了 twaver 繪制 dom 元素的方法邏輯，改造成懶加載方式
  • 即當(dāng)節(jié)點不在頁面可視范圍內(nèi)的話，不掛載 dom 到界面上，避免一次性渲染太多 dom
• 收集緩存所有的 dom 組件
  • 當(dāng)反復(fù)使用時，直接復(fù)用緩存
  • 當(dāng)銷毀時，手動觸發(fā) vue 的 destroy，及時銷毀資源

小結(jié)

其實，大多數(shù)的性能問題本質(zhì)上都是大同小異的原因：

• 無意義的內(nèi)存占用過高，如 Vue 對 twaver 數(shù)據(jù)對象的響應(yīng)式處理
• 一次性處理的東西過多，如渲染上萬個節(jié)點
• 短時間內(nèi)頻繁執(zhí)行某些其實沒意義的操作，如實時刷新即使在屏幕外的動畫
• 反復(fù)創(chuàng)建、銷毀行為，如 dom 節(jié)點的反復(fù)創(chuàng)建

所以性能優(yōu)化的難點之一在于排查根因，找到問題所在后，才能去著手思考對應(yīng)的解決方案

而解決思路無外乎也是大同小異：文章來源地址http://www.zghlxwxcb.cn/news/detail-783757.html

• 按需使用、懶加載、分頁
• 緩存和復(fù)用
• 規(guī)避方法

到了這里，關(guān)于記一次卡頓的性能優(yōu)化經(jīng)歷實操的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！