Vue.js3.2響應(yīng)式部分的優(yōu)化升級詳解

更新時間：2022年07月04日 09:18:04 作者：黃軼

這篇文章主要為大家介紹了Vue.js3.2響應(yīng)式部分的優(yōu)化升級詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

背景

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

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

~40% faster dependency tracking

~17% less memory usage

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

這簡直就是一個吊炸天的優(yōu)化啊，因為要知道響應(yīng)式系統(tǒng)是 Vue.js 的核心實現(xiàn)之一，對它的優(yōu)化就意味著對所有使用 Vue.js 開發(fā)的 App 的性能優(yōu)化。

而且這個優(yōu)化并不是 Vue 官方人員實現(xiàn)的，而是社區(qū)一位大佬 @basvanmeurs 提出的，相關(guān)的優(yōu)化代碼在 2020 年 10 月 9 號就已經(jīng)提交了，但由于對內(nèi)部的實現(xiàn)改動較大，官方一直等到了 Vue.js 3.2 發(fā)布，才把代碼合入。

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

我們知道，相比于 Vue 2，Vue 3 做了多方面的優(yōu)化，其中一部分是數(shù)據(jù)響應(yīng)式的實現(xiàn)由 Object.defineProperty API 改成了 Proxy API。

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

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

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

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

響應(yīng)式實現(xiàn)原理

所謂響應(yīng)式，就是當(dāng)我們修改數(shù)據(jù)后，可以自動做某些事情；對應(yīng)到組件的渲染，就是修改數(shù)據(jù)后，能自動觸發(fā)組件的重新渲染。

Vue 3 實現(xiàn)響應(yīng)式，本質(zhì)上是通過 Proxy API 劫持了數(shù)據(jù)對象的讀寫，當(dāng)我們訪問數(shù)據(jù)時，會觸發(fā) getter 執(zhí)行依賴收集；修改數(shù)據(jù)時，會觸發(fā) setter 派發(fā)通知。

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

依賴收集

首先來看依賴收集的過程，核心就是在訪問響應(yīng)式數(shù)據(jù)的時候，觸發(fā) getter 函數(shù)，進而執(zhí)行 track 函數(shù)收集依賴：

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

分析這個函數(shù)的實現(xiàn)前，我們先想一下要收集的依賴是什么，我們的目的是實現(xiàn)響應(yīng)式，就是當(dāng)數(shù)據(jù)變化的時候可以自動做一些事情，比如執(zhí)行某些函數(shù)，所以我們收集的依賴就是數(shù)據(jù)變化后執(zhí)行的副作用函數(shù)。

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

track 函數(shù)外部創(chuàng)建了全局的 targetMap 作為原始數(shù)據(jù)對象的 Map，它的鍵是 target，值是 depsMap，作為依賴的 Map；這個 depsMap 的鍵是 target 的 key，值是 dep 集合，dep 集合中存儲的是依賴的副作用函數(shù)。為了方便理解，可以通過下圖表示它們之間的關(guān)系：

因此每次執(zhí)行 track 函數(shù)，就是把當(dāng)前激活的副作用函數(shù) activeEffect 作為依賴，然后收集到 target 相關(guān)的 depsMap 對應(yīng) key 下的依賴集合 dep 中。

派發(fā)通知

派發(fā)通知發(fā)生在數(shù)據(jù)更新的階段，核心就是在修改響應(yīng)式數(shù)據(jù)時，觸發(fā) setter 函數(shù)，進而執(zhí)行 trigger 函數(shù)派發(fā)通知:

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

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

trigger 函數(shù) 主要做了四件事情：

從 targetMap 中拿到 target 對應(yīng)的依賴集合 depsMap；
創(chuàng)建運行的 effects 集合；
根據(jù) key 從 depsMap 中找到對應(yīng)的 effect 添加到 effects 集合；
遍歷 effects 執(zhí)行相關(guān)的副作用函數(shù)。

因此每次執(zhí)行 trigger 函數(shù)，就是根據(jù) target 和 key，從 targetMap 中找到相關(guān)的所有副作用函數(shù)遍歷執(zhí)行一遍。

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

副作用函數(shù)

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

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

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

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

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

activeEffect = logCount 
logCount()

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

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

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

這樣當(dāng)我們執(zhí)行 wrappedLog 后，再去修改 counter.num，就會自動執(zhí)行 logCount 函數(shù)了。

實際上 Vue 3 就是采用類似的做法，在它內(nèi)部就有一個 effect 副作用函數(shù)，我們來看一下它的實現(xiàn)：

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

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

reactiveEffect 函數(shù)就是響應(yīng)式的副作用函數(shù)，當(dāng)執(zhí)行 trigger 過程派發(fā)通知的時候，執(zhí)行的 effect 就是它。

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

但實際上它的實現(xiàn)要更復(fù)雜一些，首先它會判斷 effect 的狀態(tài)是否是 active，這其實是一種控制手段，允許在非 active 狀態(tài)且非調(diào)度執(zhí)行情況，則直接執(zhí)行原始函數(shù) fn 并返回。

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

其實是考慮到以下這樣一個嵌套 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()

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

num2: 0
num: 0
num2: 0

而我們期望的結(jié)果應(yīng)該如下：

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

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

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

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>

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

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

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

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

響應(yīng)式實現(xiàn)的優(yōu)化

前面分析了響應(yīng)式實現(xiàn)原理，看上去一切都很 OK，那么這里面還有哪些可以值得優(yōu)化的點呢?

依賴收集的優(yōu)化

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

為了減少集合的添加刪除操作，我們需要標(biāo)識每個依賴集合的狀態(tài)，比如它是不是新收集的，還是已經(jīng)被收集過的。

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

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

其中 w 表示是否已經(jīng)被收集，n 表示是否新收集。

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

其中 effectTrackDepth 表示遞歸嵌套執(zhí)行 effect 函數(shù)的深度；trackOpBit 用于標(biāo)識依賴收集的狀態(tài)；maxMarkerBits 表示最大標(biāo)記的位數(shù)。

接下來看它們的應(yīng)用：

function effect(fn, options) {
  if (fn.effect) {
    fn = fn.effect.fn
  }
  // 創(chuàng)建 _effect 實例 
  const _effect = new ReactiveEffect(fn)
  if (options) {
    // 拷貝 options 中的屬性到 _effect 中
    extend(_effect, options)
    if (options.scope)
      // effectScope 相關(guān)處理邏輯
      recordEffectScope(_effect, options.scope)
  }
  if (!options || !options.lazy) {
    // 立即執(zhí)行
    _effect.run()
  }
  // 綁定 run 函數(shù)，作為 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 存儲相關(guān)的 deps 依賴
    this.deps = []
    // effectScope 相關(guān)處理邏輯
    recordEffectScope(this, scope)
  }
  run() {
    if (!this.active) {
      return this.fn()
    }
    if (!effectStack.includes(this)) {
      try {
        // 壓棧
        effectStack.push((activeEffect = this))
        enableTracking()
        // 根據(jù)遞歸的深度記錄位數(shù)
        trackOpBit = 1 << ++effectTrackDepth
        // 超過 maxMarkerBits 則 trackOpBit 的計算會超過最大整形的位數(shù)，降級為 cleanupEffect
        if (effectTrackDepth <= maxMarkerBits) {
          // 給依賴打標(biāo)記
          initDepMarkers(this)
        }
        else {
          cleanupEffect(this)
        }
        return this.fn()
      }
      finally {
        if (effectTrackDepth <= maxMarkerBits) {
          // 完成依賴標(biāo)記
          finalizeDepMarkers(this)
        }
        // 恢復(fù)到上一級
        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 函數(shù)的實現(xiàn)做了一定的修改和調(diào)整，內(nèi)部使用 ReactiveEffect 類創(chuàng)建了一個 _effect 實例，并且函數(shù)返回的 runner 指向的是 ReactiveEffect 類的 run 方法。

也就是執(zhí)行副作用函數(shù) effect 函數(shù)時，實際上執(zhí)行的就是這個 run 函數(shù)。

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

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

initDepMarkers 函數(shù)實現(xiàn)很簡單，遍歷 _effect 實例中的 deps 屬性，給每個 dep 的 w 屬性標(biāo)記為 trackOpBit 的值。

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

當(dāng) fn 函數(shù)執(zhí)行時候，會訪問到響應(yīng)式數(shù)據(jù)，就會觸發(fā)它們的 getter，進而執(zhí)行 track 函數(shù)執(zhí)行依賴收集。相應(yīng)的，依賴收集的過程也做了一些調(diào)整：

function track(target, type, key) {
  if (!isTracking()) {
    return
  }
  let depsMap = targetMap.get(target)
  if (!depsMap) {
    // 每個 target 對應(yīng)一個 depsMap
    targetMap.set(target, (depsMap = new Map()))
  }
  let dep = depsMap.get(key)
  if (!dep) {
    // 每個 key 對應(yīng)一個 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)) {
      // 標(biāo)記為新依賴
      dep.n |= trackOpBit 
      // 如果依賴已經(jīng)被收集，則不需要再次收集
      shouldTrack = !wasTracked(dep)
    }
  }
  else {
    // cleanup 模式
    shouldTrack = !dep.has(activeEffect)
  }
  if (shouldTrack) {
    // 收集當(dāng)前激活的 effect 作為依賴
    dep.add(activeEffect)
    // 當(dāng)前激活的 effect 收集 dep 集合作為依賴
    activeEffect.deps.push(dep)
    if ((process.env.NODE_ENV !== 'production') && activeEffect.onTrack) {
      activeEffect.onTrack(Object.assign({
        effect: activeEffect
      }, debuggerEventExtraInfo))
    }
  }
}

我們發(fā)現(xiàn)，當(dāng)創(chuàng)建 dep 的時候，是通過執(zhí)行 createDep 方法完成的，此外，在 dep 把前激活的 effect 作為依賴收集前，會判斷這個 dep 是否已經(jīng)被收集，如果已經(jīng)被收集，則不需要再次收集了。此外，這里還會判斷這 dep 是不是新的依賴，如果不是，則標(biāo)記為新的。

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

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

在滿足依賴標(biāo)記的條件下，需要執(zhí)行 finalizeDepMarkers 完成依賴標(biāo)記，來看它的實現(xiàn)：

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

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

以上就實現(xiàn)了依賴收集部分的優(yōu)化，可以看到相比于之前每次執(zhí)行 effect 函數(shù)都需要先清空依賴，再添加依賴的過程，現(xiàn)在的實現(xiàn)會在每次執(zhí)行 effect 包裹的函數(shù)前標(biāo)記依賴的狀態(tài)，過程中對于已經(jīng)收集的依賴不會重復(fù)收集，執(zhí)行完 effect 函數(shù)還會移除掉已被收集但是新的一輪依賴收集中沒有被收集的依賴。

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

響應(yīng)式 API 的優(yōu)化

響應(yīng)式 API 的優(yōu)化主要體現(xiàn)在對 ref、computed 等 API 的優(yōu)化。

以 ref API 為例，來看看它優(yōu)化前的實現(xiàn)：

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 的情況，如果它的值是對象或者數(shù)組，則遞歸響應(yīng)式
    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)
      // 派發(fā)通知
      trigger(toRaw(this), 'set' /* SET */, 'value', newVal)
    }
  }
}

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

而 RefImpl 內(nèi)部的實現(xiàn)，主要是劫持它的實例 value 屬性的 getter 和 setter。

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

接下來，我們再來看 Vue.js 3.2 對于這部分的實現(xiàn)相關(guān)的改動：

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 屬性執(zhí)行依賴收集和派發(fā)通知的邏輯。

在 Vue.js 3.2 版本的 ref 的實現(xiàn)中，關(guān)于依賴收集部分，由原先的 track 函數(shù)改成了 trackRefValue，來看它的實現(xiàn)：

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 的相關(guān)依賴保存到 dep 屬性中，而在 track 函數(shù)的實現(xiàn)中，會把依賴保留到全局的 targetMap 中：

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

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

相應(yīng)的，ref 的實現(xiàn)關(guān)于派發(fā)通知部分，由原先的 trigger 函數(shù)改成了 triggerRefValue，來看它的實現(xiàn)：

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') &amp;&amp; effect.onTrigger) {
        effect.onTrigger(extend({ effect }, debuggerEventExtraInfo))
      }
      if (effect.scheduler) {
        effect.scheduler()
      }
      else {
        effect.run()
      }
    }
  }
}

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

trackOpBit 的設(shè)計

細(xì)心的你可能會發(fā)現(xiàn)，標(biāo)記依賴的 trackOpBit，在每次計算時采用了左移的運算符 trackOpBit = 1 << ++effectTrackDepth；并且在賦值的時候，使用了或運算：

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

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

在判斷某個 dep 是否已經(jīng)被依賴收集的時候，使用了 wasTracked 函數(shù)：

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

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

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

總結(jié)

一般在 Vue.js 的應(yīng)用中，對響應(yīng)式數(shù)據(jù)的訪問和修改都是非常頻繁的操作，因此對這個過程的性能優(yōu)化，將極大提升整個應(yīng)用的性能。

大部分人去看 Vue.js 響應(yīng)式的實現(xiàn)，可能目的最多就是搞明白其中的實現(xiàn)原理，而很少去關(guān)注其中實現(xiàn)是否是最優(yōu)的。而 basvanmeurs 大佬能對提出這一系列的優(yōu)化的實現(xiàn)，并且手寫了一個 benchmark 工具來驗證自己的優(yōu)化，非常值得我們學(xué)習(xí)。

原貼，看看他們的討論，相信你會收獲更多。

前端的性能優(yōu)化永遠(yuǎn)是一個值得深挖的方向，希望在日后的開發(fā)中，不論是寫框架還是業(yè)務(wù)，你都能夠經(jīng)常去思考其中可能存在的優(yōu)化的點。

以上就是Vue.js3.2響應(yīng)式部分的優(yōu)化升級詳解的詳細(xì)內(nèi)容，更多關(guān)于Vue.js3.2響應(yīng)式優(yōu)化升級的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: