Vue.js3.2響應式優化升級的方法

這篇文章主要介紹“Vue.js3.2響應式優化升級的方法”，在日常操作中，相信很多人在Vue.js3.2響應式優化升級的方法問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Vue.js3.2響應式優化升級的方法”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

背景

Vue 3 正式發布距今已經快一年了，相信很多小伙伴已經在生產環境用上了 Vue 3 了。如今，Vue.js 3.2 已經正式發布，而這次 minor 版本的升級主要體現在源碼層級的優化，對于用戶的使用層面來說其實變化并不大。其中一個吸引我的點是提升了響應式的性能:

More efficient ref implementation (~260% faster read / ~50% faster write)

~40% faster dependency tracking

~17% less memory usage

翻譯過來就是 ref API 的讀效率提升約為 260%，寫效率提升約為 50% ，依賴收集的效率提升約為 40%，同時還減少了約 17% 的內存使用。

這簡直就是一個吊炸天的優化啊，因為要知道響應式系統是 Vue.js 的核心實現之一，對它的優化就意味著對所有使用 Vue.js 開發的 App 的性能優化。

而且這個優化并不是 Vue 官方人員實現的，而是社區一位大佬 @basvanmeurs 提出的，相關的優化代碼在 2020 年 10 月 9 號就已經提交了，但由于對內部的實現改動較大，官方一直等到了 Vue.js 3.2 發布，才把代碼合入。

這次 basvanmeurs 提出的響應式性能優化真的讓尤大喜出望外，不僅僅是大大提升了 Vue 3 的運行時性能，還因為這么核心的代碼能來自社區的貢獻，這就意味著 Vue 3 受到越來越多的人關注；一些能力強的開發人員參與到核心代碼的貢獻，可以讓 Vue 3 走的更遠更好。

我們知道，相比于 Vue 2，Vue 3 做了多方面的優化，其中一部分是數據響應式的實現由 Object.defineProperty API 改成了 Proxy API。

當初 Vue 3 在宣傳的時候，官方宣稱在響應式的實現性能上做了優化，那么優化體現在哪些方面呢？有部分小伙伴認為是 Proxy API 的性能要優于 Object.defineProperty 的，其實不然，實際上 Proxy 在性能上是要比 Object.defineProperty 差的，詳情可以參考 Thoughts on ES6 Proxies Performance 這篇文章，而我也對此做了測試，結論同上，可以參考這個 repo。

既然 Proxy 慢，為啥 Vue 3 還是選擇了它來實現數據響應式呢？因為 Proxy 本質上是對某個對象的劫持，這樣它不僅僅可以監聽對象某個屬性值的變化，還可以監聽對象屬性的新增和刪除；而 Object.defineProperty 是給對象的某個已存在的屬性添加對應的 getter 和 setter，所以它只能監聽這個屬性值的變化，而不能去監聽對象屬性的新增和刪除。

而響應式在性能方面的優化其實是體現在把嵌套層級較深的對象變成響應式的場景。在 Vue 2 的實現中，在組件初始化階段把數據變成響應式時，遇到子屬性仍然是對象的情況，會遞歸執行 Object.defineProperty 定義子對象的響應式；而在 Vue 3 的實現中，只有在對象屬性被訪問的時候才會判斷子屬性的類型來決定要不要遞歸執行 reactive，這其實是一種延時定義子對象響應式的實現，在性能上會有一定的提升。

因此，相比于 Vue 2，Vue 3 確實在響應式實現部分做了一定的優化，但實際上效果是有限的。而 Vue.js 3.2 這次在響應式性能方面的優化，是真的做到了質的飛躍，接下來我們就來上點硬菜，從源碼層面分析具體做了哪些優化，以及這些優化背后帶來的技術層面的思考。

響應式實現原理

所謂響應式，就是當我們修改數據后，可以自動做某些事情；對應到組件的渲染，就是修改數據后，能自動觸發組件的重新渲染。

Vue 3 實現響應式，本質上是通過 Proxy API 劫持了數據對象的讀寫，當我們訪問數據時，會觸發 getter 執行依賴收集；修改數據時，會觸發 setter 派發通知。

接下來，我們簡單分析一下依賴收集和派發通知的實現（Vue.js 3.2 之前的版本）。

依賴收集

首先來看依賴收集的過程，核心就是在訪問響應式數據的時候，觸發 getter 函數，進而執行 track 函數收集依賴：

let shouldTrack = true
// 當前激活的 effect
let activeEffect
// 原始數據對象 map
const targetMap = new WeakMap()
function track(target, type, key) {
  if (!shouldTrack || activeEffect === undefined) {
    return
  }
  let depsMap = targetMap.get(target)
  if (!depsMap) {
    // 每個 target 對應一個 depsMap
    targetMap.set(target, (depsMap = new Map()))
  }
  let dep = depsMap.get(key)
  if (!dep) {
    // 每個 key 對應一個 dep 集合
    depsMap.set(key, (dep = new Set()))
  }
  if (!dep.has(activeEffect)) {
    // 收集當前激活的 effect 作為依賴
    dep.add(activeEffect)
   // 當前激活的 effect 收集 dep 集合作為依賴
    activeEffect.deps.push(dep)
  }
}

分析這個函數的實現前，我們先想一下要收集的依賴是什么，我們的目的是實現響應式，就是當數據變化的時候可以自動做一些事情，比如執行某些函數，所以我們收集的依賴就是數據變化后執行的副作用函數。

track 函數擁有三個參數，其中 target 表示原始數據；type 表示這次依賴收集的類型；key 表示訪問的屬性。

track 函數外部創建了全局的 targetMap 作為原始數據對象的 Map，它的鍵是 target，值是 depsMap，作為依賴的 Map；這個 depsMap 的鍵是 target 的 key，值是 dep 集合，dep 集合中存儲的是依賴的副作用函數。

因此每次執行 track 函數，就是把當前激活的副作用函數 activeEffect 作為依賴，然后收集到 target 相關的 depsMap 對應 key 下的依賴集合 dep 中。

派發通知

派發通知發生在數據更新的階段，核心就是在修改響應式數據時，觸發 setter 函數，進而執行 trigger 函數派發通知:

const targetMap = new WeakMap()
function trigger(target, type, key) {
  // 通過 targetMap 拿到 target 對應的依賴集合
  const depsMap = targetMap.get(target)
  if (!depsMap) {
    // 沒有依賴，直接返回
    return
  }
  // 創建運行的 effects 集合
  const effects = new Set()
  // 添加 effects 的函數
  const add = (effectsToAdd) => {
    if (effectsToAdd) {
      effectsToAdd.forEach(effect => {
        effects.add(effect)
      })
    }
  }
  // SET | ADD | DELETE 操作之一，添加對應的 effects
  if (key !== void 0) {
    add(depsMap.get(key))
  }
  const run = (effect) => {
    // 調度執行
    if (effect.options.scheduler) {
      effect.options.scheduler(effect)
    }
    else {
      // 直接運行
      effect()
    }
  }
  // 遍歷執行 effects
  effects.forEach(run)
}

trigger 函數擁有三個參數，其中 target 表示目標原始對象；type 表示更新的類型；key 表示要修改的屬性。

trigger 函數 主要做了四件事情：

• 從 targetMap 中拿到 target 對應的依賴集合 depsMap；

• 創建運行的 effects 集合；

• 根據 key 從 depsMap 中找到對應的 effect 添加到 effects 集合；

• 遍歷 effects 執行相關的副作用函數。

因此每次執行 trigger 函數，就是根據 target 和 key，從 targetMap 中找到相關的所有副作用函數遍歷執行一遍。

在描述依賴收集和派發通知的過程中，我們都提到了一個詞：副作用函數，依賴收集過程中我們把 activeEffect（當前激活副作用函數）作為依賴收集，它又是什么？接下來我們來看一下副作用函數的廬山真面目。

副作用函數

那么，什么是副作用函數，在介紹它之前，我們先回顧一下響應式的原始需求，即我們修改了數據就能自動做某些事情，舉個簡單的例子：

import { reactive } from 'vue'
const counter = reactive({
  num: 0
})
function logCount() {
  console.log(counter.num)
}
function count() {
  counter.num++
}
logCount()
count()

我們定義了響應式對象 counter，然后在 logCount 中訪問了 counter.num，我們希望在執行 count 函數修改 counter.num 值的時候，能自動執行 logCount 函數。

按我們之前對依賴收集過程的分析，如果logCount 是 activeEffect 的話，那么就可以實現需求，但顯然是做不到的，因為代碼在執行到 console.log(counter.num) 這一行的時候，它對自己在 logCount 函數中的運行是一無所知的。

那么該怎么辦呢？其實只要我們運行 logCount 函數前，把 logCount 賦值給 activeEffect 就好了：

activeEffect = logCount 
logCount()

順著這個思路，我們可以利用高階函數的思想，對 logCount 做一層封裝：

function wrapper(fn) {
  const wrapped = function(...args) {
    activeEffect = fn
    fn(...args)
  }
  return wrapped
}
const wrappedLog = wrapper(logCount)
wrappedLog()

wrapper 本身也是一個函數，它接受 fn 作為參數，返回一個新的函數 wrapped，然后維護一個全局變量 activeEffect，當 wrapped 執行的時候，把 activeEffect 設置為 fn，然后執行 fn 即可。

這樣當我們執行 wrappedLog 后，再去修改 counter.num，就會自動執行 logCount 函數了。

實際上 Vue 3 就是采用類似的做法，在它內部就有一個 effect 副作用函數，我們來看一下它的實現：

// 全局 effect 棧
const effectStack = []
// 當前激活的 effect
let activeEffect
function effect(fn, options = EMPTY_OBJ) {
  if (isEffect(fn)) {
    // 如果 fn 已經是一個 effect 函數了，則指向原始函數
    fn = fn.raw
  }
  // 創建一個 wrapper，它是一個響應式的副作用的函數
  const effect = createReactiveEffect(fn, options)
  if (!options.lazy) {
    // lazy 配置，計算屬性會用到，非 lazy 則直接執行一次
    effect()
  }
  return effect
}
function createReactiveEffect(fn, options) {
  const effect = function reactiveEffect() {
    if (!effect.active) {
      // 非激活狀態，則判斷如果非調度執行，則直接執行原始函數。
      return options.scheduler ? undefined : fn()
    }
    if (!effectStack.includes(effect)) {
      // 清空 effect 引用的依賴
      cleanup(effect)
      try {
        // 開啟全局 shouldTrack，允許依賴收集
        enableTracking()
        // 壓棧
        effectStack.push(effect)
        activeEffect = effect
        // 執行原始函數
        return fn()
      }
      finally {
        // 出棧
        effectStack.pop()
        // 恢復 shouldTrack 開啟之前的狀態
        resetTracking()
        // 指向棧最后一個 effect
        activeEffect = effectStack[effectStack.length - 1]
      }
    }
  }
  effect.id = uid++
  // 標識是一個 effect 函數
  effect._isEffect = true
  // effect 自身的狀態
  effect.active = true
  // 包裝的原始函數
  effect.raw = fn
  // effect 對應的依賴，雙向指針，依賴包含對 effect 的引用，effect 也包含對依賴的引用
  effect.deps = []
  // effect 的相關配置
  effect.options = options
  return effect
}

結合上述代碼來看，effect 內部通過執行 createReactiveEffect 函數去創建一個新的 effect 函數，為了和外部的 effect 函數區分，我們把它稱作 reactiveEffect 函數，并且還給它添加了一些額外屬性（我在注釋中都有標明）。另外，effect 函數還支持傳入一個配置參數以支持更多的 feature，這里就不展開了。

reactiveEffect 函數就是響應式的副作用函數，當執行 trigger 過程派發通知的時候，執行的 effect 就是它。

按我們之前的分析，reactiveEffect 函數只需要做兩件事情：讓全局的 activeEffect 指向它， 然后執行被包裝的原始函數 fn。

但實際上它的實現要更復雜一些，首先它會判斷 effect 的狀態是否是 active，這其實是一種控制手段，允許在非 active 狀態且非調度執行情況，則直接執行原始函數 fn 并返回。

接著判斷 effectStack 中是否包含 effect，如果沒有就把 effect 壓入棧內。之前我們提到，只要設置 activeEffect = effect 即可，那么這里為什么要設計一個棧的結構呢？

其實是考慮到以下這樣一個嵌套 effect 的場景：

import { reactive} from 'vue' 
import { effect } from '@vue/reactivity' 
const counter = reactive({ 
  num: 0, 
  num2: 0 
}) 
function logCount() { 
  effect(logCount2) 
  console.log('num:', counter.num) 
} 
function count() { 
  counter.num++ 
} 
function logCount2() { 
  console.log('num2:', counter.num2) 
} 
effect(logCount) 
count()

我們每次執行 effect 函數時，如果僅僅把 reactiveEffect 函數賦值給 activeEffect，那么針對這種嵌套場景，執行完 effect(logCount2) 后，activeEffect 還是 effect(logCount2) 返回的 reactiveEffect 函數，這樣后續訪問 counter.num 的時候，依賴收集對應的 activeEffect 就不對了，此時我們外部執行 count 函數修改 counter.num 后執行的便不是 logCount 函數，而是 logCount2 函數，最終輸出的結果如下：

num2: 0 
num: 0 
num2: 0

而我們期望的結果應該如下：

num2: 0 
num: 0 
num2: 0 
num: 1

因此針對嵌套 effect 的場景，我們不能簡單地賦值 activeEffect，應該考慮到函數的執行本身就是一種入棧出棧操作，因此我們也可以設計一個 effectStack，這樣每次進入 reactiveEffect 函數就先把它入棧，然后 activeEffect 指向這個 reactiveEffect 函數，接著在 fn 執行完畢后出棧，再把 activeEffect 指向 effectStack 最后一個元素，也就是外層 effect 函數對應的 reactiveEffect。

這里我們還注意到一個細節，在入棧前會執行 cleanup 函數清空 reactiveEffect 函數對應的依賴 。在執行 track 函數的時候，除了收集當前激活的 effect 作為依賴，還通過 activeEffect.deps.push(dep) 把 dep 作為 activeEffect 的依賴，這樣在 cleanup 的時候我們就可以找到 effect 對應的 dep 了，然后把 effect 從這些 dep 中刪除。cleanup 函數的代碼如下所示：

function cleanup(effect) {
  const { deps } = effect
  if (deps.length) {
    for (let i = 0; i < deps.length; i++) {
      deps[i].delete(effect)
    }
    deps.length = 0
  }
}

為什么需要 cleanup 呢？如果遇到這種場景：

<template>
  <div v-if="state.showMsg">
    {{ state.msg }}
  </div>
  <div v-else>
    {{ Math.random()}}
  </div>
  <button @click="toggle">Toggle Msg</button>
  <button @click="switchView">Switch View</button>
</template>
<script>
  import { reactive } from 'vue'
  export default {
    setup() {
      const state = reactive({
        msg: 'Hello World',
        showMsg: true
      })
      function toggle() {
        state.msg = state.msg === 'Hello World' ? 'Hello Vue' : 'Hello World'
      }
      function switchView() {
        state.showMsg = !state.showMsg
      }
      return {
        toggle,
        switchView,
        state
      }
    }
  }
</script>

結合代碼可以知道，這個組件的視圖會根據 showMsg 變量的控制顯示 msg 或者一個隨機數，當我們點擊 Switch View 的按鈕時，就會修改這個變量值。

假設沒有 cleanup，在第一次渲染模板的時候，activeEffect 是組件的副作用渲染函數，因為模板 render 的時候訪問了 state.msg，所以會執行依賴收集，把副作用渲染函數作為 state.msg 的依賴，我們把它稱作 render effect。然后我們點擊 Switch View 按鈕，視圖切換為顯示隨機數，此時我們再點擊 Toggle Msg 按鈕，由于修改了 state.msg 就會派發通知，找到了 render effect 并執行，就又觸發了組件的重新渲染。

但這個行為實際上并不符合預期，因為當我們點擊 Switch View 按鈕，視圖切換為顯示隨機數的時候，也會觸發組件的重新渲染，但這個時候視圖并沒有渲染 state.msg，所以對它的改動并不應該影響組件的重新渲染。

因此在組件的 render effect 執行之前，如果通過 cleanup 清理依賴，我們就可以刪除之前 state.msg 收集的 render effect 依賴。這樣當我們修改 state.msg 時，由于已經沒有依賴了就不會觸發組件的重新渲染，符合預期。

響應式實現的優化

前面分析了響應式實現原理，看上去一切都很 OK，那么這里面還有哪些可以值得優化的點呢?

依賴收集的優化

目前每次副作用函數執行，都需要先執行 cleanup 清除依賴，然后在副作用函數執行的過程中重新收集依賴，這個過程牽涉到大量對 Set 集合的添加和刪除操作。在許多場景下，依賴關系是很少改變的，因此這里存在一定的優化空間。

為了減少集合的添加刪除操作，我們需要標識每個依賴集合的狀態，比如它是不是新收集的，還是已經被收集過的。

所以這里需要給集合 dep 添加兩個屬性：

export const createDep = (effects) => {
  const dep = new Set(effects)
  dep.w = 0
  dep.n = 0
  return dep
}

其中 w 表示是否已經被收集，n 表示是否新收集。

然后設計幾個全局變量，effectTrackDepth、trackOpBit、maxMarkerBits。

其中 effectTrackDepth 表示遞歸嵌套執行 effect 函數的深度；trackOpBit 用于標識依賴收集的狀態；maxMarkerBits 表示最大標記的位數。

接下來看它們的應用：

function effect(fn, options) {
  if (fn.effect) {
    fn = fn.effect.fn
  }
  // 創建 _effect 實例 
  const _effect = new ReactiveEffect(fn)
  if (options) {
    // 拷貝 options 中的屬性到 _effect 中
    extend(_effect, options)
    if (options.scope)
      // effectScope 相關處理邏輯
      recordEffectScope(_effect, options.scope)
  }
  if (!options || !options.lazy) {
    // 立即執行
    _effect.run()
  }
  // 綁定 run 函數，作為 effect runner
  const runner = _effect.run.bind(_effect)
  // runner 中保留對 _effect 的引用
  runner.effect = _effect
  return runner
}
class ReactiveEffect {
  constructor(fn, scheduler = null, scope) {
    this.fn = fn
    this.scheduler = scheduler
    this.active = true
    // effect 存儲相關的 deps 依賴
    this.deps = []
    // effectScope 相關處理邏輯
    recordEffectScope(this, scope)
  }
  run() {
    if (!this.active) {
      return this.fn()
    }
    if (!effectStack.includes(this)) {
      try {
        // 壓棧
        effectStack.push((activeEffect = this))
        enableTracking()
        // 根據遞歸的深度記錄位數
        trackOpBit = 1 << ++effectTrackDepth
        // 超過 maxMarkerBits 則 trackOpBit 的計算會超過最大整形的位數，降級為 cleanupEffect
        if (effectTrackDepth <= maxMarkerBits) {
          // 給依賴打標記
          initDepMarkers(this)
        }
        else {
          cleanupEffect(this)
        }
        return this.fn()
      }
      finally {
        if (effectTrackDepth <= maxMarkerBits) {
          // 完成依賴標記
          finalizeDepMarkers(this)
        }
        // 恢復到上一級
        trackOpBit = 1 << --effectTrackDepth
        resetTracking()
        // 出棧
        effectStack.pop()
        const n = effectStack.length
        // 指向棧最后一個 effect
        activeEffect = n > 0 ? effectStack[n - 1] : undefined
      }
    }
  }
  stop() {
    if (this.active) {
      cleanupEffect(this)
      if (this.onStop) {
        this.onStop()
      }
      this.active = false
    }
  }
}

可以看到，effect 函數的實現做了一定的修改和調整，內部使用 ReactiveEffect 類創建了一個 _effect 實例，并且函數返回的 runner 指向的是 ReactiveEffect 類的 run 方法。

也就是執行副作用函數 effect 函數時，實際上執行的就是這個 run 函數。

當 run 函數執行的時候，我們注意到 cleanup 函數不再默認執行，在封裝的函數 fn 執行前，首先執行 trackOpBit = 1 << ++effectTrackDepth 記錄 trackOpBit，然后對比遞歸深度是否超過了 maxMarkerBits，如果超過（通常情況下不會）則仍然執行老的 cleanup 邏輯，如果沒超過則執行 initDepMarkers 給依賴打標記，來看它的實現：

const initDepMarkers = ({ deps }) => {
  if (deps.length) {
    for (let i = 0; i < deps.length; i++) {
      deps[i].w |= trackOpBit // 標記依賴已經被收集
    }
  }
}

initDepMarkers 函數實現很簡單，遍歷 _effect 實例中的 deps 屬性，給每個 dep 的 w 屬性標記為 trackOpBit 的值。

接下來會執行 fn 函數，在就是副作用函數封裝的函數，比如針對組件渲染，fn 就是組件渲染函數。

當 fn 函數執行時候，會訪問到響應式數據，就會觸發它們的 getter，進而執行 track 函數執行依賴收集。相應的，依賴收集的過程也做了一些調整：

function track(target, type, key) {
  if (!isTracking()) {
    return
  }
  let depsMap = targetMap.get(target)
  if (!depsMap) {
    // 每個 target 對應一個 depsMap
    targetMap.set(target, (depsMap = new Map()))
  }
  let dep = depsMap.get(key)
  if (!dep) {
    // 每個 key 對應一個 dep 集合
    depsMap.set(key, (dep = createDep()))
  }
  const eventInfo = (process.env.NODE_ENV !== 'production')
    ? { effect: activeEffect, target, type, key }
    : undefined
  trackEffects(dep, eventInfo)
}
function trackEffects(dep, debuggerEventExtraInfo) {
  let shouldTrack = false
  if (effectTrackDepth <= maxMarkerBits) {
    if (!newTracked(dep)) {
      // 標記為新依賴
      dep.n |= trackOpBit 
      // 如果依賴已經被收集，則不需要再次收集
      shouldTrack = !wasTracked(dep)
    }
  }
  else {
    // cleanup 模式
    shouldTrack = !dep.has(activeEffect)
  }
  if (shouldTrack) {
    // 收集當前激活的 effect 作為依賴
    dep.add(activeEffect)
    // 當前激活的 effect 收集 dep 集合作為依賴
    activeEffect.deps.push(dep)
    if ((process.env.NODE_ENV !== 'production') && activeEffect.onTrack) {
      activeEffect.onTrack(Object.assign({
        effect: activeEffect
      }, debuggerEventExtraInfo))
    }
  }
}

我們發現，當創建 dep 的時候，是通過執行 createDep 方法完成的，此外，在 dep 把前激活的 effect 作為依賴收集前，會判斷這個 dep 是否已經被收集，如果已經被收集，則不需要再次收集了。此外，這里還會判斷這 dep 是不是新的依賴，如果不是，則標記為新的。

接下來，我們再來看 fn 執行完后的邏輯：

finally {
  if (effectTrackDepth <= maxMarkerBits) {
    // 完成依賴標記
    finalizeDepMarkers(this)
  }
  // 恢復到上一級
  trackOpBit = 1 << --effectTrackDepth
  resetTracking()
  // 出棧
  effectStack.pop()
  const n = effectStack.length
  // 指向棧最后一個 effect
  activeEffect = n > 0 ? effectStack[n - 1] : undefined
}

在滿足依賴標記的條件下，需要執行 finalizeDepMarkers 完成依賴標記，來看它的實現：

const finalizeDepMarkers = (effect) => {
  const { deps } = effect
  if (deps.length) {
    let ptr = 0
    for (let i = 0; i < deps.length; i++) {
      const dep = deps[i]
      // 曾經被收集過但不是新的依賴，需要刪除
      if (wasTracked(dep) && !newTracked(dep)) {
        dep.delete(effect)
      }
      else {
        deps[ptr++] = dep
      }
      // 清空狀態
      dep.w &= ~trackOpBit
      dep.n &= ~trackOpBit
    }
    deps.length = ptr
  }
}

finalizeDepMarkers 主要做的事情就是找到那些曾經被收集過但是新的一輪依賴收集沒有被收集的依賴，從 deps 中移除。這其實就是解決前面舉的需要 cleanup 的場景：在新的組件渲染過程中沒有訪問到的響應式對象，那么它的變化不應該觸發組件的重新渲染。

以上就實現了依賴收集部分的優化，可以看到相比于之前每次執行 effect 函數都需要先清空依賴，再添加依賴的過程，現在的實現會在每次執行 effect 包裹的函數前標記依賴的狀態，過程中對于已經收集的依賴不會重復收集，執行完 effect 函數還會移除掉已被收集但是新的一輪依賴收集中沒有被收集的依賴。

優化后對于 dep 依賴集合的操作就減少了，自然也就優化了性能。

響應式 API 的優化

響應式 API 的優化主要體現在對 ref、computed 等 API 的優化。

以 ref API 為例，來看看它優化前的實現：

function ref(value) {
  return createRef(value)
}
const convert = (val) => isObject(val) ? reactive(val) : val
function createRef(rawValue, shallow = false) {
  if (isRef(rawValue)) {
    // 如果傳入的就是一個 ref，那么返回自身即可，處理嵌套 ref 的情況。
    return rawValue
  }
  return new RefImpl(rawValue, shallow)
}
class RefImpl {
  constructor(_rawValue, _shallow = false) {
    this._rawValue = _rawValue
    this._shallow = _shallow
    this.__v_isRef = true
    // 非 shallow 的情況，如果它的值是對象或者數組，則遞歸響應式
    this._value = _shallow ? _rawValue : convert(_rawValue)
  }
  get value() {
    // 給 value 屬性添加 getter，并做依賴收集
    track(toRaw(this), 'get' /* GET */, 'value')
    return this._value
  }
  set value(newVal) {
    // 給 value 屬性添加 setter
    if (hasChanged(toRaw(newVal), this._rawValue)) {
      this._rawValue = newVal
      this._value = this._shallow ? newVal : convert(newVal)
      // 派發通知
      trigger(toRaw(this), 'set' /* SET */, 'value', newVal)
    }
  }
}

ref 函數返回了 createRef 函數執行的返回值，而在 createRef 內部，首先處理了嵌套 ref 的情況，如果傳入的 rawValue 也是個 ref，那么直接返回 rawValue；接著返回 RefImpl 對象的實例。

而 RefImpl 內部的實現，主要是劫持它的實例 value 屬性的 getter 和 setter。

當訪問一個 ref 對象的 value 屬性，會觸發 getter 執行 track 函數做依賴收集然后返回它的值；當修改一個 ref 對象的 value 值，則會觸發 setter 設置新值并且執行 trigger 函數派發通知，如果新值 newVal 是對象或者數組類型，那么把它轉換成一個 reactive 對象。

接下來，我們再來看 Vue.js 3.2 對于這部分的實現相關的改動：

class RefImpl {
  constructor(value, _shallow = false) {
    this._shallow = _shallow
    this.dep = undefined
    this.__v_isRef = true
    this._rawValue = _shallow ? value : toRaw(value)
    this._value = _shallow ? value : convert(value)
  }
  get value() {
    trackRefValue(this)
    return this._value
  }
  set value(newVal) {
    newVal = this._shallow ? newVal : toRaw(newVal)
    if (hasChanged(newVal, this._rawValue)) {
      this._rawValue = newVal
      this._value = this._shallow ? newVal : convert(newVal)
      triggerRefValue(this, newVal)
    }
  }
}

主要改動部分就是對 ref 對象的 value 屬性執行依賴收集和派發通知的邏輯。

在 Vue.js 3.2 版本的 ref 的實現中，關于依賴收集部分，由原先的 track 函數改成了 trackRefValue，來看它的實現：

function trackRefValue(ref) {
  if (isTracking()) {
    ref = toRaw(ref)
    if (!ref.dep) {
      ref.dep = createDep()
    }
    if ((process.env.NODE_ENV !== 'production')) {
      trackEffects(ref.dep, {
        target: ref,
        type: "get" /* GET */,
        key: 'value'
      })
    }
    else {
      trackEffects(ref.dep)
    }
  }
}

可以看到這里直接把 ref 的相關依賴保存到 dep 屬性中，而在 track 函數的實現中，會把依賴保留到全局的 targetMap 中：

let depsMap = targetMap.get(target)
if (!depsMap) {
  // 每個 target 對應一個 depsMap
  targetMap.set(target, (depsMap = new Map()))
}
let dep = depsMap.get(key)
if (!dep) {
  // 每個 key 對應一個 dep 集合
  depsMap.set(key, (dep = createDep()))
}

顯然，track 函數內部可能需要做多次判斷和設置邏輯，而把依賴保存到 ref 對象的 dep 屬性中則省去了這一系列的判斷和設置，從而優化性能。

相應的，ref 的實現關于派發通知部分，由原先的 trigger 函數改成了 triggerRefValue，來看它的實現：

function triggerRefValue(ref, newVal) {
  ref = toRaw(ref)
  if (ref.dep) {
    if ((process.env.NODE_ENV !== 'production')) {
      triggerEffects(ref.dep, {
        target: ref,
        type: "set" /* SET */,
        key: 'value',
        newValue: newVal
      })
    }
    else {
      triggerEffects(ref.dep)
    }
  }
}
function triggerEffects(dep, debuggerEventExtraInfo) {
  for (const effect of isArray(dep) ? dep : [...dep]) {
    if (effect !== activeEffect || effect.allowRecurse) {
      if ((process.env.NODE_ENV !== 'production') && effect.onTrigger) {
        effect.onTrigger(extend({ effect }, debuggerEventExtraInfo))
      }
      if (effect.scheduler) {
        effect.scheduler()
      }
      else {
        effect.run()
      }
    }
  }
}

由于直接從 ref 屬性中就拿到了它所有的依賴且遍歷執行，不需要執行 trigger 函數一些額外的邏輯，因此在性能上也得到了提升。

trackOpBit 的設計

細心的你可能會發現，標記依賴的 trackOpBit，在每次計算時采用了左移的運算符 trackOpBit = 1 << ++effectTrackDepth；并且在賦值的時候，使用了或運算：

deps[i].w |= trackOpBit
dep.n |= trackOpBit

那么為什么這么設計呢？因為 effect 的執行可能會有遞歸的情況，通過這種方式就可以記錄每個層級的依賴標記情況。

在判斷某個 dep 是否已經被依賴收集的時候，使用了 wasTracked 函數：

const wasTracked = (dep) => (dep.w & trackOpBit) > 0

通過與運算的結果是否大于 0 來判斷，這就要求依賴被收集時嵌套的層級要匹配。舉個例子，假設此時 dep.w 的值是 2，說明它是在第一層執行 effect 函數時創建的，但是這時候已經執行了嵌套在第二層的 effect 函數，trackOpBit 左移兩位變成了 4，2 & 4 的值是 0，那么 wasTracked 函數返回值為 false，說明需要收集這個依賴。顯然，這個需求是合理的。

可以看到，如果沒有 trackOpBit 位運算的設計，你就很難去處理不同嵌套層級的依賴標記，這個設計也體現了 basvanmeurs 大佬非常扎實的計算機基礎功力。

到此，關于“Vue.js3.2響應式優化升級的方法”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！