寫在最前：本文章的目標(biāo)

Vue3的生命周期的實(shí)現(xiàn)原理是比較簡(jiǎn)單的，但要理解整個(gè)Vue3的生命周期則還要結(jié)合整個(gè)Vue的運(yùn)行原理，又因?yàn)閂ue3的一些生命周期的執(zhí)行機(jī)制是通過Vue3的調(diào)度器來完成的，所以想要徹底了解Vue3的生命周期原理還必須要結(jié)合Vue3的調(diào)度器的實(shí)現(xiàn)原理來理解。同時(shí)通過對(duì)Vue3的調(diào)度器的理解，從而加深對(duì)Vue底層的一些設(shè)計(jì)原理和規(guī)則的理解，所以本文章的目標(biāo)是理解Vue3生命周期Hooks的原理以及通過Vue3生命周期Hooks的運(yùn)行了解Vue3調(diào)度器(Scheduler)的原理。

Vue3生命周期的實(shí)現(xiàn)原理

Vue3的生命周期Hooks函數(shù)的實(shí)現(xiàn)原理還是比較簡(jiǎn)單的，就是把各個(gè)生命周期的函數(shù)掛載或者叫注冊(cè)到組件的實(shí)例上，然后等到組件運(yùn)行到某個(gè)時(shí)刻，再去組件實(shí)例上把相應(yīng)的生命周期的函數(shù)取出來執(zhí)行。

下面來看看具體代碼的實(shí)現(xiàn)

生命周期類型

// packages/runtime-core/src/component.ts
export const enum LifecycleHooks {
    BEFORE_CREATE = 'bc', // 創(chuàng)建之前
    CREATED = 'c', // 創(chuàng)建
    BEFORE_MOUNT = 'bm', // 掛載之前
    MOUNTED = 'm', // 掛載之后
    BEFORE_UPDATE = 'bu', // 更新之前
    UPDATED = 'u', // 更新之后
    BEFORE_UNMOUNT = 'bum', // 卸載之前
    UNMOUNTED = 'um', // 卸載之后
	// ...
}

各個(gè)生命周期Hooks函數(shù)的創(chuàng)建

// packages/runtime-core/src/apiLifecycle.ts
export const onBeforeMount = createHook(LifecycleHooks.BEFORE_MOUNT)
export const onMounted = createHook(LifecycleHooks.MOUNTED)
export const onBeforeUpdate = createHook(LifecycleHooks.BEFORE_UPDATE)
export const onUpdated = createHook(LifecycleHooks.UPDATED)
export const onBeforeUnmount = createHook(LifecycleHooks.BEFORE_UNMOUNT)
export const onUnmounted = createHook(LifecycleHooks.UNMOUNTED)

可以看到各個(gè)生命周期的Hooks函數(shù)是通過createHook這個(gè)函數(shù)創(chuàng)建的

創(chuàng)建生命周期函數(shù)createHook

// packages/runtime-core/src/apiLifecycle.ts
export const createHook = (lifecycle) => (hook, target = currentInstance) => injectHook(lifecycle, hook, target)

createHook是一個(gè)閉包函數(shù)，通過閉包緩存當(dāng)前是屬于哪個(gè)生命周期的Hooks,target表示該生命周期Hooks函數(shù)被綁定到哪個(gè)組件實(shí)例上，默認(rèn)是當(dāng)前工作的組件實(shí)例。createHook底層又調(diào)用了一個(gè)injectHook的函數(shù)，那么下面我們繼續(xù)來看看這個(gè)injectHook函數(shù)。

injectHook函數(shù)

injectHook是一個(gè)閉包函數(shù)，通過閉包緩存綁定對(duì)應(yīng)生命周期Hooks到對(duì)應(yīng)的組件實(shí)例上。

// packages/runtime-core/src/apiLifecycle.ts
export function injectHook(type, hook, target) {
    if(target) {
        // 把各個(gè)生命周期的Hooks函數(shù)掛載到組件實(shí)例上，并且是一個(gè)數(shù)組，因?yàn)榭赡苣銜?huì)多次調(diào)用同一個(gè)組件的同一個(gè)生命周期函數(shù)
        const hooks = target[type] || (target[type] = [])
        // 把生命周期函數(shù)進(jìn)行包裝并且把包裝函數(shù)緩存在__weh上
        const wrappedHook =
        hook.__weh ||
        (hook.__weh = (...args: unknown[]) => {
          if (target.isUnmounted) {
            return
          }
            // 當(dāng)生命周期調(diào)用時(shí) 保證currentInstance是正確的
            setCurrentInstance(target)
            // 執(zhí)行生命周期Hooks函數(shù)
            const  res = args ? hook(...args) : hook()
            unsetCurrentInstance()
          return res
        })
        // 把生命周期的包裝函數(shù)綁定到組件實(shí)例對(duì)應(yīng)的hooks上
        hooks.push(wrappedHook)
        // 返回包裝函數(shù)
        return wrappedHook
    }
}

生命周期Hooks的調(diào)用

instance.update = effect(() => {
    if (!instance.isMounted) {
        const { bm, m } = instance
        // 生命周期：beforeMount hook
        if (bm) {
            invokeArrayFns(bm)
        }
        // 組件初始化的時(shí)候會(huì)執(zhí)行這里
        // 為什么要在這里調(diào)用 render 函數(shù)呢
        // 是因?yàn)樵?effect 內(nèi)調(diào)用 render 才能觸發(fā)依賴收集
        // 等到后面響應(yīng)式的值變更后會(huì)再次觸發(fā)這個(gè)函數(shù)  
        const subTree = (instance.subTree = renderComponentRoot(instance))
        patch(null, subTree, container, instance, anchor)
        instance.vnode.el = subTree.el 
        instance.isMounted = true
        // 生命周期：mounted
        if(m) {
            // mounted需要通過Scheduler的函數(shù)來調(diào)用
            queuePostFlushCb(m)
        }
    } else {
        // 響應(yīng)式的值變更后會(huì)從這里執(zhí)行邏輯
        // 主要就是拿到新的 vnode ，然后和之前的 vnode 進(jìn)行對(duì)比
        // 拿到最新的 subTree
        const { bu, u, next, vnode } = instance
        // 如果有 next 的話， 說明需要更新組件的數(shù)據(jù)（props，slots 等）
        // 先更新組件的數(shù)據(jù)，然后更新完成后，在繼續(xù)對(duì)比當(dāng)前組件的子元素
        if(next) {
            next.el = vnode.el
            updateComponentPreRender(instance, next)
        }
        // 生命周期：beforeUpdate hook
        if (bu) {
            invokeArrayFns(bu)
        }
        const subTree = renderComponentRoot(instance)
        // 替換之前的 subTree
        const prevSubTree = instance.subTree
        instance.subTree = subTree
        // 用舊的 vnode 和新的 vnode 交給 patch 來處理
        patch(prevSubTree, subTree, container, instance, anchor)
        // 生命周期：updated hook
        if (u) {
            // updated 需要通過Scheduler的函數(shù)來調(diào)用
            queuePostFlushCb(u)
        }
    }
}, {
    scheduler() {
        queueJobs(instance.update)
    }
})

上面這個(gè)是Vue3組件實(shí)例化之后，通過effect包裝一個(gè)更新的副作用函數(shù)來和響應(yīng)式數(shù)據(jù)進(jìn)行依賴收集。在這個(gè)副作用函數(shù)里面有兩個(gè)分支，第一個(gè)是組件掛載之前執(zhí)行的，也就是生命周期函數(shù)beforeMount和mount調(diào)用的地方，第二個(gè)分支是組件掛載之后更新的時(shí)候執(zhí)行的，在這里就是生命周期函數(shù)beforeUpdate和updated調(diào)用的地方。 具體就是在掛載之前，還沒生成虛擬DOM之前就執(zhí)行beforeMount函數(shù)，之后則去生成虛擬DOM經(jīng)過patch之后，組件已經(jīng)被掛載到頁(yè)面上了，也就是頁(yè)面上顯示視圖了，這個(gè)時(shí)候就去執(zhí)行mount函數(shù);在更新的時(shí)候，還沒獲取更新之后的虛擬DOM之前執(zhí)行beforeUpdate，然后去獲取更新之后的虛擬DOM，然后再去patch，更新視圖，之后就執(zhí)行updated。 需要注意的是beforeMount和beforeUpdate是同步執(zhí)行的，都是通過invokeArrayFns來調(diào)用的。 invokeArrayFns函數(shù)

export const invokeArrayFns = (fns: Function[], arg?: any) => {
  for (let i = 0; i < fns.length; i++) {
    fns[i](arg)
  }
}

組件掛載和更新則是異步的，需要通過Scheduler來處理。

Vue3調(diào)度器(Scheduler)原理

在Vue3的一些API，例如：組件的生命周期API、watch API、組件更新的回調(diào)函數(shù)都不是立即執(zhí)行的，而是放到異步任務(wù)隊(duì)列里面，然后按一定的規(guī)則進(jìn)行執(zhí)行的，比如說任務(wù)隊(duì)列里面同時(shí)存在，watch的任務(wù)，組件更新的任務(wù)，生命周期的任務(wù)，它的執(zhí)行順序是怎么樣的呢？這個(gè)就是由調(diào)度器的調(diào)度算法決定，同時(shí)調(diào)度算法只調(diào)度執(zhí)行的順序，不負(fù)責(zé)具體的執(zhí)行。這樣設(shè)計(jì)的好處就是即便將來Vue3增加新的異步回調(diào)API，也不需要修改調(diào)度算法，可以極大的減少 Vue API 和 隊(duì)列間耦合。 Vue3的Scheduler提供了三個(gè)入列方式的API：

queuePreFlushCb API: 加入 Pre 隊(duì)列 組件更新前執(zhí)行

export function queuePreFlushCb(cb: SchedulerJob) {
  queueCb(cb, activePreFlushCbs, pendingPreFlushCbs, preFlushIndex)
}

queueJob API: 加入 queue 隊(duì)列 組件更新執(zhí)行

export function queueJob(job: SchedulerJob) {
}

queuePostFlushCb API: 加入 Post 隊(duì)列 組件更新后執(zhí)行

export function queuePostFlushCb(cb: SchedulerJobs) {
  queueCb(cb, activePostFlushCbs, pendingPostFlushCbs, postFlushIndex)
}

由于Vue3只提供了入列方式的API并沒有提供出列方式的API，所以我們只能控制何時(shí)入列，而何時(shí)出列則由Vue3調(diào)度器本身控制。

那么Vue3調(diào)度器如何控制出列方式呢？其實(shí)也很簡(jiǎn)單。

function flushJobs(seen?) {
    isFlushPending = false
    // 組件更新前隊(duì)列執(zhí)行
    flushPreFlushCbs(seen)
    try{
        // 組件更新隊(duì)列執(zhí)行
        let job
        while (job = queue.shift()) {
            job && job()
        }
    } finally {
        // 組件更新后隊(duì)列執(zhí)行
        flushPostFlushCbs(seen)
        // 如果在執(zhí)行異步任務(wù)的過程中又產(chǎn)生了新的隊(duì)列，那么則繼續(xù)回調(diào)執(zhí)行
        if (
            queue.length ||
            pendingPreFlushCbs.length ||
            pendingPostFlushCbs.length
        ) {
            flushJobs(seen)
        }
    }
}

Vue父子組件的生命周期的執(zhí)行順序

這里有兩個(gè)概念需要厘清的概念，一：父子組件的執(zhí)行順序，二：父子組件生命周期的執(zhí)行順序。這兩個(gè)是不一樣的

父子組件的執(zhí)行順序

這個(gè)是先執(zhí)行父組件再執(zhí)行子組件，先父組件實(shí)例化，然后去獲取父組件的虛擬DOM之后在patch的過程中，如果父組件的虛擬DOM中存在組件類型的虛擬DOM也就是子組件，那么在patch的分支中就會(huì)去走組件初始化的流程，如此循環(huán)。

父子組件生命周期的執(zhí)行順序

父子組件生命周期的執(zhí)行順序是在父子組件的執(zhí)行順序下通過調(diào)度算法按Vue的規(guī)則進(jìn)行執(zhí)行的。首先父組件先實(shí)例化進(jìn)行執(zhí)行，通過上面的生命周期的調(diào)用說明，我們可以知道，父組件在更新函數(shù)update第一次執(zhí)行，也就是組件初始化的時(shí)候，先執(zhí)行父組件的beforeMount，然后去獲取父組件的虛擬DOM，然后在patch的過程中遇到虛擬節(jié)點(diǎn)是組件類型的時(shí)候，就又會(huì)去走組件初始化的流程，這個(gè)時(shí)候其實(shí)就是子組件初始化，那么之后子組件也需要走一遍組件的所有流程，子組件在更新update第一次執(zhí)行的時(shí)候，先執(zhí)行子組件的beforeMount，再去獲取子組件的虛擬DOM，然后patch子組件的虛擬DOM，如果過程中又遇到節(jié)點(diǎn)是組件類型的話，又去走一遍組件初始化的流程，直到子組件patch完成，然后執(zhí)行子組件的mounted生命周期函數(shù)，接著回到父組件的執(zhí)行棧，執(zhí)行父組件的mounted生命周期。

所以在初始化創(chuàng)建的時(shí)候，是深度遞歸創(chuàng)建子組件的過程，父子組件的生命周期的執(zhí)行順序是：

• 父組件 -> beforeMount
• 子組件 -> beforeMount
• 子組件 -> mounted
• 父組件 -> mounted

父子組件更新順序同樣是深度遞歸執(zhí)行的過程：

• 如果父子組件沒通過props傳遞數(shù)據(jù)，那么更新的時(shí)候，就各自執(zhí)行各自的更新生命周期函數(shù)。
• 如果父子組件存在通過props傳遞數(shù)據(jù)的話，就必須先更新父組件，才能更新子組件。因?yàn)楦附M件 DOM 更新前，需要修改子組件的 props，子組件的 props 才是正確的值。

下面我們來看源碼

if (next) {
    next.el = vnode.el
    // 在組件更新前，先更新一些數(shù)據(jù)
    updateComponentPreRender(instance, next, optimized)
} else {
    next = vnode
}

例如更新props,更新slots

  const updateComponentPreRender = (
    instance: ComponentInternalInstance,
    nextVNode: VNode,
    optimized: boolean
  ) => {
    nextVNode.component = instance
    const prevProps = instance.vnode.props
    instance.vnode = nextVNode
    instance.next = null
    // 更新props
    updateProps(instance, nextVNode.props, prevProps, optimized)
    // 更新slots
    updateSlots(instance, nextVNode.children, optimized)
	// ...
  }

所以在父子組件更新的時(shí)候，父子組件的生命周期執(zhí)行順序是：

• 父組件 -> beforeUpdate
• 子組件 -> beforeUpdate
• 子組件 -> updated
• 父組件 -> updated

同樣卸載的時(shí)候父子組件也是深度遞歸遍歷執(zhí)行的過程：

• 父組件 -> beforeUnmount
• 子組件 -> beforeUnmount
• 子組件 -> unmounted
• 父組件 -> unmounted

組件卸載的時(shí)候，是在卸載些什么呢？

組件卸載的時(shí)候主要是卸載模版引用，清除effect里面保存的相關(guān)組件的更新函數(shù)的副作用函數(shù)，如果是緩存組件，則清除相關(guān)緩存，最后去移除真實(shí)DOM上相關(guān)節(jié)點(diǎn)。

另外組件 DOM 更新（instance.update）是有保存在調(diào)度器的任務(wù)隊(duì)列中的，組件卸載的時(shí)候，也需要把相關(guān)的組件更新（instance.update）設(shè)置失效。

在源碼的unmountComponent函數(shù)中，有這么一段：

if (update) {
    // 把組件更新函數(shù)的active設(shè)置false
    update.active = false
    unmount(subTree, instance, parentSuspense, doRemove)
}

然后在Scheduler執(zhí)行queue隊(duì)列任務(wù)的時(shí)候，那些job的active為false的則不執(zhí)行

const job = queue[flushIndex]
// 那些job的active為false的則不執(zhí)行
if (job && job.active !== false) {
    callWithErrorHandling(job, null, ErrorCodes.SCHEDULER)
}

那么組件 DOM 更新（instance.update）什么時(shí)候會(huì)被刪除呢？

在源碼的updateComponent函數(shù)可以找到刪除instance.update的設(shè)置

invalidateJob(instance.update)
// 立即執(zhí)行更新任務(wù)
instance.update()

調(diào)度器刪除任務(wù)

export function invalidateJob(job: SchedulerJob) {
  // 找到 job 的索引
  const i = queue.indexOf(job)
  if (i > flushIndex) {
    // 刪除 Job
    queue.splice(i, 1)
  }
}

由此我們可以得知在一個(gè)組件更新的時(shí)候，會(huì)先把該組件在調(diào)度器里的更新任務(wù)先刪除。因?yàn)榻M件更新也是一個(gè)遞歸執(zhí)行更新的過程，在遞歸的過程中執(zhí)行了子組件的更新，那么調(diào)度器的任務(wù)隊(duì)列里面的子組件更新任務(wù)就不需要再執(zhí)行了，所以就要?jiǎng)h除掉，將來子組件依賴的響應(yīng)式數(shù)據(jù)發(fā)生了更新，那么則重新把子組件的更新任務(wù)放到調(diào)度器的任務(wù)隊(duì)列里去。

組件更新的調(diào)度器里的隊(duì)列任務(wù)的失效與刪除的區(qū)別

通過上述組件卸載的介紹我們可以總結(jié)一下組件更新的調(diào)度器里的隊(duì)列任務(wù)的失效與刪除的區(qū)別

失效

• 組件卸載時(shí)，將 Job 設(shè)置為失效，Job 從隊(duì)列中取出時(shí)，不再執(zhí)行
• 不能再次加入隊(duì)列，因?yàn)闀?huì)被去重
• 被卸載的組件，無論它依賴的響應(yīng)式變量如何更新，該組件都不會(huì)更新了

刪除

• 組件更新時(shí)，刪除該組件在調(diào)度器任務(wù)隊(duì)列中的 Job
• 可以再次加入隊(duì)列
• 刪除任務(wù)，因?yàn)橐呀?jīng)更新過了，不需要重復(fù)更新。 如果依賴的響應(yīng)式變量再次被修改，仍然需要加入調(diào)度器的任務(wù)隊(duì)列，等待更新

父子組件執(zhí)行順序與調(diào)度器的關(guān)系

假設(shè)有有這樣一個(gè)場(chǎng)景，有一對(duì)父子組件，子組件使用watch API監(jiān)聽某個(gè)子組件的響應(yīng)式數(shù)據(jù)發(fā)生改變之后，然后去修改了N個(gè)父組件的響應(yīng)式數(shù)據(jù)。那么N個(gè)父組件的更新函數(shù)都將被放到調(diào)度器的任務(wù)隊(duì)列中等待執(zhí)行。這種情況調(diào)度器怎么確保最頂層的父組件的更新函數(shù)最先執(zhí)行呢？

我們先看看調(diào)度器的任務(wù)隊(duì)列里的Job的數(shù)據(jù)結(jié)構(gòu)

export interface SchedulerJob extends Function {
  id?: number  // 用于對(duì)隊(duì)列中的 job 進(jìn)行排序，id 小的先執(zhí)行
  active?: boolean
  computed?: boolean
  allowRecurse?: boolean 
  ownerInstance?: ComponentInternalInstance	
}

Job是一個(gè)函數(shù)，并且?guī)в幸恍傩?。其中id，表示優(yōu)先級(jí)，用于實(shí)現(xiàn)隊(duì)列插隊(duì)，id 小的先執(zhí)行,active通過上文我們可以知道active表示 Job 是否有效，失效的 Job 不執(zhí)行，如組件卸載會(huì)導(dǎo)致 Job 失效。

調(diào)度器任務(wù)隊(duì)列的數(shù)據(jù)結(jié)構(gòu)

const queue: SchedulerJob[] = []

是一個(gè)數(shù)組

調(diào)度器任務(wù)隊(duì)列的執(zhí)行

// 按任務(wù)id大小排序
queue.sort((a, b) => getId(a) - getId(b))
try {
    for (flushIndex = 0; flushIndex < queue.length; flushIndex++) {
        const job = queue[flushIndex]
        if (job && job.active !== false) {
            // 使用帶有 Vue 內(nèi)部的錯(cuò)誤處理函數(shù)執(zhí)行job
            callWithErrorHandling(job, null, ErrorCodes.SCHEDULER)
        }
    }
} finally {
    // 清空 queue 隊(duì)列
    flushIndex = 0
    queue.length = 0
}

那么又怎么確保父組件的更新函數(shù)的任務(wù)id是最小的呢？

通過查看源碼我們可以看在創(chuàng)建組件實(shí)例的createComponentInstance函數(shù)中有一個(gè)uid的屬性，并且它的初始值為0，后續(xù)則++

let uid = 0 // 初始化為0
export function createComponentInstance(
  vnode
  parent
  suspense
) {
  const instance: ComponentInternalInstance = {
    uid: uid++,
   // ...   
  }

然后在創(chuàng)建組件更新函數(shù)的時(shí)候可以看到，組件更新函數(shù)的id就是該組件實(shí)例的uid

const update = (instance.update = effect.run.bind(effect) as SchedulerJob)
update.id = instance.uid

組件創(chuàng)建的過程是深度遞歸創(chuàng)建子組件的過程，所以最先的父組件是0，后面的子組件則一路++上去，這樣就確保了子組件的更新函數(shù)的任務(wù)id是一定大于父組件更新函數(shù)的id的。所以當(dāng)調(diào)度器的任務(wù)隊(duì)列里面同時(shí)存在很多組件的更新函數(shù)的時(shí)候，通過優(yōu)先級(jí)排序，就可以確保一定父組件的更新函數(shù)最先執(zhí)行了。

當(dāng)前中途也可以進(jìn)行插隊(duì)

export function queueJob(job: SchedulerJob) {
	// 沒有id的則push到最后
    if (job.id == null) {
      queue.push(job)
    } else {
      // 進(jìn)行插隊(duì)處理
      queue.splice(findInsertionIndex(job.id), 0, job)
    }
    queueFlush()
}

Hooks的本質(zhì)

最后探討一下Hooks的本質(zhì)

Vue的Hooks設(shè)計(jì)是從React的Hooks那里借鑒過來的，React的Hooks的本質(zhì)就是把狀態(tài)變量、副作用函數(shù)存到函數(shù)組件的fiber對(duì)象上，等到將來狀態(tài)變量發(fā)生改變的時(shí)候，相關(guān)的函數(shù)組件fiber就重新進(jìn)行更新。Vue3這邊的實(shí)現(xiàn)原理也類似，通過上面的生命周期的Hooks實(shí)現(xiàn)原理，我們可以知道Vue3的生命周期的Hooks是綁定到具體的組件實(shí)例上，而狀態(tài)變量，則因?yàn)閂ue的變量是響應(yīng)式的，狀態(tài)變量會(huì)通過effect和具體的組件更新函數(shù)進(jìn)行依賴收集，然后進(jìn)行綁定，將來狀態(tài)變量發(fā)生改變的時(shí)候，相應(yīng)的組件更新函數(shù)會(huì)重新進(jìn)入調(diào)度器的任務(wù)隊(duì)列進(jìn)行調(diào)度執(zhí)行。

所以Hooks的本質(zhì)就是讓那些狀態(tài)變量或生命周期函數(shù)和組件綁定起來，組件運(yùn)行到相應(yīng)時(shí)刻執(zhí)行相應(yīng)綁定的生命周期函數(shù)，那些綁定的變量發(fā)生改變的時(shí)候，相應(yīng)的組件也重新進(jìn)行更新。

最后

下一篇準(zhǔn)備寫一下watch API的實(shí)現(xiàn)原理，同時(shí)watch API也需要和調(diào)度器結(jié)合進(jìn)行理解，只有相互串聯(lián)理解才可以把Vue3底層設(shè)計(jì)和實(shí)現(xiàn)原理理解得更加透切一些。

最后推薦一個(gè)學(xué)習(xí)vue3源碼的庫(kù)，它是基于崔效瑞老師的開源庫(kù)mini-vue而來，在mini-vue的基礎(chǔ)上實(shí)現(xiàn)更多的vue3核心功能，用于深入學(xué)習(xí) vue3， 讓你更輕松地理解 vue3 的核心邏輯。

源碼地址 https://github.com/amebyte/mini-vue3-plus

以上就是Vue3生命周期Hooks原理與調(diào)度器Scheduler關(guān)系的詳細(xì)內(nèi)容，更多關(guān)于Vue3 Hooks與Scheduler關(guān)系的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！