Vue3生命周期Hooks原理與調(diào)度器Scheduler關系
寫在最前:本文章的目標
Vue3的生命周期的實現(xiàn)原理是比較簡單的,但要理解整個Vue3的生命周期則還要結合整個Vue的運行原理,又因為Vue3的一些生命周期的執(zhí)行機制是通過Vue3的調(diào)度器來完成的,所以想要徹底了解Vue3的生命周期原理還必須要結合Vue3的調(diào)度器的實現(xiàn)原理來理解。同時通過對Vue3的調(diào)度器的理解,從而加深對Vue底層的一些設計原理和規(guī)則的理解,所以本文章的目標是理解Vue3生命周期Hooks的原理以及通過Vue3生命周期Hooks的運行了解Vue3調(diào)度器(Scheduler)的原理。
Vue3生命周期的實現(xiàn)原理
Vue3的生命周期Hooks函數(shù)的實現(xiàn)原理還是比較簡單的,就是把各個生命周期的函數(shù)掛載或者叫注冊到組件的實例上,然后等到組件運行到某個時刻,再去組件實例上把相應的生命周期的函數(shù)取出來執(zhí)行。
下面來看看具體代碼的實現(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', // 卸載之后
// ...
}
各個生命周期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)
可以看到各個生命周期的Hooks函數(shù)是通過createHook這個函數(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是一個閉包函數(shù),通過閉包緩存當前是屬于哪個生命周期的Hooks,target表示該生命周期Hooks函數(shù)被綁定到哪個組件實例上,默認是當前工作的組件實例。createHook底層又調(diào)用了一個injectHook的函數(shù),那么下面我們繼續(xù)來看看這個injectHook函數(shù)。
injectHook函數(shù)
injectHook是一個閉包函數(shù),通過閉包緩存綁定對應生命周期Hooks到對應的組件實例上。
// packages/runtime-core/src/apiLifecycle.ts
export function injectHook(type, hook, target) {
if(target) {
// 把各個生命周期的Hooks函數(shù)掛載到組件實例上,并且是一個數(shù)組,因為可能你會多次調(diào)用同一個組件的同一個生命周期函數(shù)
const hooks = target[type] || (target[type] = [])
// 把生命周期函數(shù)進行包裝并且把包裝函數(shù)緩存在__weh上
const wrappedHook =
hook.__weh ||
(hook.__weh = (...args: unknown[]) => {
if (target.isUnmounted) {
return
}
// 當生命周期調(diào)用時 保證currentInstance是正確的
setCurrentInstance(target)
// 執(zhí)行生命周期Hooks函數(shù)
const res = args ? hook(...args) : hook()
unsetCurrentInstance()
return res
})
// 把生命周期的包裝函數(shù)綁定到組件實例對應的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)
}
// 組件初始化的時候會執(zhí)行這里
// 為什么要在這里調(diào)用 render 函數(shù)呢
// 是因為在 effect 內(nèi)調(diào)用 render 才能觸發(fā)依賴收集
// 等到后面響應式的值變更后會再次觸發(fā)這個函數(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 {
// 響應式的值變更后會從這里執(zhí)行邏輯
// 主要就是拿到新的 vnode ,然后和之前的 vnode 進行對比
// 拿到最新的 subTree
const { bu, u, next, vnode } = instance
// 如果有 next 的話, 說明需要更新組件的數(shù)據(jù)(props,slots 等)
// 先更新組件的數(shù)據(jù),然后更新完成后,在繼續(xù)對比當前組件的子元素
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)
}
})
上面這個是Vue3組件實例化之后,通過effect包裝一個更新的副作用函數(shù)來和響應式數(shù)據(jù)進行依賴收集。在這個副作用函數(shù)里面有兩個分支,第一個是組件掛載之前執(zhí)行的,也就是生命周期函數(shù)beforeMount和mount調(diào)用的地方,第二個分支是組件掛載之后更新的時候執(zhí)行的,在這里就是生命周期函數(shù)beforeUpdate和updated調(diào)用的地方。 具體就是在掛載之前,還沒生成虛擬DOM之前就執(zhí)行beforeMount函數(shù),之后則去生成虛擬DOM經(jīng)過patch之后,組件已經(jīng)被掛載到頁面上了,也就是頁面上顯示視圖了,這個時候就去執(zhí)行mount函數(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í)行的,而是放到異步任務隊列里面,然后按一定的規(guī)則進行執(zhí)行的,比如說任務隊列里面同時存在,watch的任務,組件更新的任務,生命周期的任務,它的執(zhí)行順序是怎么樣的呢?這個就是由調(diào)度器的調(diào)度算法決定,同時調(diào)度算法只調(diào)度執(zhí)行的順序,不負責具體的執(zhí)行。這樣設計的好處就是即便將來Vue3增加新的異步回調(diào)API,也不需要修改調(diào)度算法,可以極大的減少 Vue API 和 隊列間耦合。 Vue3的Scheduler提供了三個入列方式的API:
queuePreFlushCb API: 加入 Pre 隊列 組件更新前執(zhí)行
export function queuePreFlushCb(cb: SchedulerJob) {
queueCb(cb, activePreFlushCbs, pendingPreFlushCbs, preFlushIndex)
}
queueJob API: 加入 queue 隊列 組件更新執(zhí)行
export function queueJob(job: SchedulerJob) {
}
queuePostFlushCb API: 加入 Post 隊列 組件更新后執(zhí)行
export function queuePostFlushCb(cb: SchedulerJobs) {
queueCb(cb, activePostFlushCbs, pendingPostFlushCbs, postFlushIndex)
}
由于Vue3只提供了入列方式的API并沒有提供出列方式的API,所以我們只能控制何時入列,而何時出列則由Vue3調(diào)度器本身控制。
那么Vue3調(diào)度器如何控制出列方式呢?其實也很簡單。
function flushJobs(seen?) {
isFlushPending = false
// 組件更新前隊列執(zhí)行
flushPreFlushCbs(seen)
try{
// 組件更新隊列執(zhí)行
let job
while (job = queue.shift()) {
job && job()
}
} finally {
// 組件更新后隊列執(zhí)行
flushPostFlushCbs(seen)
// 如果在執(zhí)行異步任務的過程中又產(chǎn)生了新的隊列,那么則繼續(xù)回調(diào)執(zhí)行
if (
queue.length ||
pendingPreFlushCbs.length ||
pendingPostFlushCbs.length
) {
flushJobs(seen)
}
}
}
Vue父子組件的生命周期的執(zhí)行順序
這里有兩個概念需要厘清的概念,一:父子組件的執(zhí)行順序,二:父子組件生命周期的執(zhí)行順序。這兩個是不一樣的
父子組件的執(zhí)行順序
這個是先執(zhí)行父組件再執(zhí)行子組件,先父組件實例化,然后去獲取父組件的虛擬DOM之后在patch的過程中,如果父組件的虛擬DOM中存在組件類型的虛擬DOM也就是子組件,那么在patch的分支中就會去走組件初始化的流程,如此循環(huán)。
父子組件生命周期的執(zhí)行順序
父子組件生命周期的執(zhí)行順序是在父子組件的執(zhí)行順序下通過調(diào)度算法按Vue的規(guī)則進行執(zhí)行的。首先父組件先實例化進行執(zhí)行,通過上面的生命周期的調(diào)用說明,我們可以知道,父組件在更新函數(shù)update第一次執(zhí)行,也就是組件初始化的時候,先執(zhí)行父組件的beforeMount,然后去獲取父組件的虛擬DOM,然后在patch的過程中遇到虛擬節(jié)點是組件類型的時候,就又會去走組件初始化的流程,這個時候其實就是子組件初始化,那么之后子組件也需要走一遍組件的所有流程,子組件在更新update第一次執(zhí)行的時候,先執(zhí)行子組件的beforeMount,再去獲取子組件的虛擬DOM,然后patch子組件的虛擬DOM,如果過程中又遇到節(jié)點是組件類型的話,又去走一遍組件初始化的流程,直到子組件patch完成,然后執(zhí)行子組件的mounted生命周期函數(shù),接著回到父組件的執(zhí)行棧,執(zhí)行父組件的mounted生命周期。
所以在初始化創(chuàng)建的時候,是深度遞歸創(chuàng)建子組件的過程,父子組件的生命周期的執(zhí)行順序是:
- 父組件 -> beforeMount
- 子組件 -> beforeMount
- 子組件 -> mounted
- 父組件 -> mounted
父子組件更新順序同樣是深度遞歸執(zhí)行的過程:
- 如果父子組件沒通過props傳遞數(shù)據(jù),那么更新的時候,就各自執(zhí)行各自的更新生命周期函數(shù)。
- 如果父子組件存在通過props傳遞數(shù)據(jù)的話,就必須先更新父組件,才能更新子組件。因為父組件 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)
// ...
}
所以在父子組件更新的時候,父子組件的生命周期執(zhí)行順序是:
- 父組件 -> beforeUpdate
- 子組件 -> beforeUpdate
- 子組件 -> updated
- 父組件 -> updated
同樣卸載的時候父子組件也是深度遞歸遍歷執(zhí)行的過程:
- 父組件 -> beforeUnmount
- 子組件 -> beforeUnmount
- 子組件 -> unmounted
- 父組件 -> unmounted
組件卸載的時候,是在卸載些什么呢?
組件卸載的時候主要是卸載模版引用,清除effect里面保存的相關組件的更新函數(shù)的副作用函數(shù),如果是緩存組件,則清除相關緩存,最后去移除真實DOM上相關節(jié)點。
另外組件 DOM 更新(instance.update)是有保存在調(diào)度器的任務隊列中的,組件卸載的時候,也需要把相關的組件更新(instance.update)設置失效。
在源碼的unmountComponent函數(shù)中,有這么一段:
if (update) {
// 把組件更新函數(shù)的active設置false
update.active = false
unmount(subTree, instance, parentSuspense, doRemove)
}
然后在Scheduler執(zhí)行queue隊列任務的時候,那些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)什么時候會被刪除呢?
在源碼的updateComponent函數(shù)可以找到刪除instance.update的設置
invalidateJob(instance.update) // 立即執(zhí)行更新任務 instance.update()
調(diào)度器刪除任務
export function invalidateJob(job: SchedulerJob) {
// 找到 job 的索引
const i = queue.indexOf(job)
if (i > flushIndex) {
// 刪除 Job
queue.splice(i, 1)
}
}
由此我們可以得知在一個組件更新的時候,會先把該組件在調(diào)度器里的更新任務先刪除。因為組件更新也是一個遞歸執(zhí)行更新的過程,在遞歸的過程中執(zhí)行了子組件的更新,那么調(diào)度器的任務隊列里面的子組件更新任務就不需要再執(zhí)行了,所以就要刪除掉,將來子組件依賴的響應式數(shù)據(jù)發(fā)生了更新,那么則重新把子組件的更新任務放到調(diào)度器的任務隊列里去。
組件更新的調(diào)度器里的隊列任務的失效與刪除的區(qū)別
通過上述組件卸載的介紹我們可以總結一下組件更新的調(diào)度器里的隊列任務的失效與刪除的區(qū)別
失效
- 組件卸載時,將 Job 設置為失效,Job 從隊列中取出時,不再執(zhí)行
- 不能再次加入隊列,因為會被去重
- 被卸載的組件,無論它依賴的響應式變量如何更新,該組件都不會更新了
刪除
- 組件更新時,刪除該組件在調(diào)度器任務隊列中的 Job
- 可以再次加入隊列
- 刪除任務,因為已經(jīng)更新過了,不需要重復更新。 如果依賴的響應式變量再次被修改,仍然需要加入調(diào)度器的任務隊列,等待更新
父子組件執(zhí)行順序與調(diào)度器的關系
假設有有這樣一個場景,有一對父子組件,子組件使用watch API監(jiān)聽某個子組件的響應式數(shù)據(jù)發(fā)生改變之后,然后去修改了N個父組件的響應式數(shù)據(jù)。那么N個父組件的更新函數(shù)都將被放到調(diào)度器的任務隊列中等待執(zhí)行。這種情況調(diào)度器怎么確保最頂層的父組件的更新函數(shù)最先執(zhí)行呢?
我們先看看調(diào)度器的任務隊列里的Job的數(shù)據(jù)結構
export interface SchedulerJob extends Function {
id?: number // 用于對隊列中的 job 進行排序,id 小的先執(zhí)行
active?: boolean
computed?: boolean
allowRecurse?: boolean
ownerInstance?: ComponentInternalInstance
}
Job是一個函數(shù),并且?guī)в幸恍傩浴F渲衖d,表示優(yōu)先級,用于實現(xiàn)隊列插隊,id 小的先執(zhí)行,active通過上文我們可以知道active表示 Job 是否有效,失效的 Job 不執(zhí)行,如組件卸載會導致 Job 失效。
調(diào)度器任務隊列的數(shù)據(jù)結構
const queue: SchedulerJob[] = []
是一個數(shù)組
調(diào)度器任務隊列的執(zhí)行
// 按任務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)部的錯誤處理函數(shù)執(zhí)行job
callWithErrorHandling(job, null, ErrorCodes.SCHEDULER)
}
}
} finally {
// 清空 queue 隊列
flushIndex = 0
queue.length = 0
}
那么又怎么確保父組件的更新函數(shù)的任務id是最小的呢?
通過查看源碼我們可以看在創(chuàng)建組件實例的createComponentInstance函數(shù)中有一個uid的屬性,并且它的初始值為0,后續(xù)則++
let uid = 0 // 初始化為0
export function createComponentInstance(
vnode
parent
suspense
) {
const instance: ComponentInternalInstance = {
uid: uid++,
// ...
}
然后在創(chuàng)建組件更新函數(shù)的時候可以看到,組件更新函數(shù)的id就是該組件實例的uid
const update = (instance.update = effect.run.bind(effect) as SchedulerJob) update.id = instance.uid
組件創(chuàng)建的過程是深度遞歸創(chuàng)建子組件的過程,所以最先的父組件是0,后面的子組件則一路++上去,這樣就確保了子組件的更新函數(shù)的任務id是一定大于父組件更新函數(shù)的id的。所以當調(diào)度器的任務隊列里面同時存在很多組件的更新函數(shù)的時候,通過優(yōu)先級排序,就可以確保一定父組件的更新函數(shù)最先執(zhí)行了。
當前中途也可以進行插隊
export function queueJob(job: SchedulerJob) {
// 沒有id的則push到最后
if (job.id == null) {
queue.push(job)
} else {
// 進行插隊處理
queue.splice(findInsertionIndex(job.id), 0, job)
}
queueFlush()
}
Hooks的本質
最后探討一下Hooks的本質
Vue的Hooks設計是從React的Hooks那里借鑒過來的,React的Hooks的本質就是把狀態(tài)變量、副作用函數(shù)存到函數(shù)組件的fiber對象上,等到將來狀態(tài)變量發(fā)生改變的時候,相關的函數(shù)組件fiber就重新進行更新。Vue3這邊的實現(xiàn)原理也類似,通過上面的生命周期的Hooks實現(xiàn)原理,我們可以知道Vue3的生命周期的Hooks是綁定到具體的組件實例上,而狀態(tài)變量,則因為Vue的變量是響應式的,狀態(tài)變量會通過effect和具體的組件更新函數(shù)進行依賴收集,然后進行綁定,將來狀態(tài)變量發(fā)生改變的時候,相應的組件更新函數(shù)會重新進入調(diào)度器的任務隊列進行調(diào)度執(zhí)行。
所以Hooks的本質就是讓那些狀態(tài)變量或生命周期函數(shù)和組件綁定起來,組件運行到相應時刻執(zhí)行相應綁定的生命周期函數(shù),那些綁定的變量發(fā)生改變的時候,相應的組件也重新進行更新。
最后
下一篇準備寫一下watch API的實現(xiàn)原理,同時watch API也需要和調(diào)度器結合進行理解,只有相互串聯(lián)理解才可以把Vue3底層設計和實現(xiàn)原理理解得更加透切一些。
最后推薦一個學習vue3源碼的庫,它是基于崔效瑞老師的開源庫mini-vue而來,在mini-vue的基礎上實現(xiàn)更多的vue3核心功能,用于深入學習 vue3, 讓你更輕松地理解 vue3 的核心邏輯。
源碼地址 https://github.com/amebyte/mini-vue3-plus
以上就是Vue3生命周期Hooks原理與調(diào)度器Scheduler關系的詳細內(nèi)容,更多關于Vue3 Hooks與Scheduler關系的資料請關注腳本之家其它相關文章!
相關文章
vue報錯Not?allowed?to?load?local?resource的解決辦法
這篇文章主要給大家介紹了關于vue報錯Not?allowed?to?load?local?resource的解決辦法,這個錯誤是因為Vue不能加載本地資源的原因,需要的朋友可以參考下2023-07-07
解決Element中el-date-picker組件不回填的情況
這篇文章主要介紹了解決Element中el-date-picker組件不回填的情況,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2020-11-11

