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

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

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

問題現(xiàn)象

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

但當呈現(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í)行

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

而之所以會這么實現(xiàn)，原因之一是官方給的鏈路動畫 demo 就是這么做的，當初做的時候直接用 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é)點和鏈路，但當節(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ā)功能異常，因為沒法確認三方庫內(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__;
  }
  // 當滿足下面條件時，對對象進行響應(yīng)式處理
  if (
    shouldObserve && // 總開關(guān)
    (ssrMockReactivity || !isServerRendering()) && // 非服務(wù)端渲染場景
    (isArray(value) || isPlainObject(value)) && // 數(shù)組或?qū)ο?    Object.isExtensible(value) && // 支持擴展（即動態(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)式處理的標志 __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 標志位判斷

有人說，不用這么麻煩，把變量命名改成 _ 為前綴，也能繞過響應(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)部變量而引起異常。因此當 data 里有這些變量時，使用時應(yīng)該要 this.$data._xxx 的方式來操作這些變量

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

【舉一反三】

當用到其他一些三方庫，三方庫變量又不是全局而是當前組件內(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 實例對象，當達到成千上萬條鏈路時，資源就被撐爆了，很卡

【復(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)的拓撲畫布
    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ī)避，如增加默認折疊、展開處理

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

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

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

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

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

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

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

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

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

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

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

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

有些復(fù)雜節(jié)點的場景無法用 twaver 的默認節(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 元素的方法邏輯，改造成懶加載方式
  • 即當節(jié)點不在頁面可視范圍內(nèi)的話，不掛載 dom 到界面上，避免一次性渲染太多 dom
• 收集緩存所有的 dom 組件
  • 當反復(fù)使用時，直接復(fù)用緩存
  • 當銷毀時，手動觸發(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)的解決方案

而解決思路無外乎也是大同小異：

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

總結(jié)

以上是生活随笔為你收集整理的记一次卡顿的性能优化经历实操的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。