Vue3生命周期Hooks原理與調(diào)度器Scheduler關(guān)系
寫在最前:本文章的目標
Vue3的生命周期的實現(xiàn)原理是比較簡單的,但要理解整個Vue3的生命周期則還要結(jié)合整個Vue的運行原理,又因為Vue3的一些生命周期的執(zhí)行機制是通過Vue3的調(diào)度器來完成的,所以想要徹底了解Vue3的生命周期原理還必須要結(jié)合Vue3的調(diào)度器的實現(xiàn)原理來理解。同時通過對Vue3的調(diào)度器的理解,從而加深對Vue底層的一些設(shè)計原理和規(guī)則的理解,所以本文章的目標是理解Vue3生命周期Hooks的原理以及通過Vue3生命周期Hooks的運行了解Vue3調(diào)度器(Scheduler)的原理。
Vue3生命周期的實現(xiàn)原理
Vue3的生命周期Hooks函數(shù)的實現(xiàn)原理還是比較簡單的,就是把各個生命周期的函數(shù)掛載或者叫注冊到組件的實例上,然后等到組件運行到某個時刻,再去組件實例上把相應(yīng)的生命周期的函數(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ù),通過閉包緩存綁定對應(yīng)生命周期Hooks到對應(yīng)的組件實例上。
// 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ù)綁定到組件實例對應(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) } // 組件初始化的時候會執(zhí)行這里 // 為什么要在這里調(diào)用 render 函數(shù)呢 // 是因為在 effect 內(nèi)調(diào)用 render 才能觸發(fā)依賴收集 // 等到后面響應(yīng)式的值變更后會再次觸發(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 { // 響應(yīng)式的值變更后會從這里執(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ù)來和響應(yīng)式數(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í)行的,而是放到異步任務(wù)隊列里面,然后按一定的規(guī)則進行執(zhí)行的,比如說任務(wù)隊列里面同時存在,watch的任務(wù),組件更新的任務(wù),生命周期的任務(wù),它的執(zhí)行順序是怎么樣的呢?這個就是由調(diào)度器的調(diào)度算法決定,同時調(diào)度算法只調(diào)度執(zhí)行的順序,不負責具體的執(zhí)行。這樣設(shè)計的好處就是即便將來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í)行異步任務(wù)的過程中又產(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里面保存的相關(guān)組件的更新函數(shù)的副作用函數(shù),如果是緩存組件,則清除相關(guān)緩存,最后去移除真實DOM上相關(guān)節(jié)點。
另外組件 DOM 更新(instance.update)是有保存在調(diào)度器的任務(wù)隊列中的,組件卸載的時候,也需要把相關(guān)的組件更新(instance.update)設(shè)置失效。
在源碼的unmountComponent函數(shù)中,有這么一段:
if (update) { // 把組件更新函數(shù)的active設(shè)置false update.active = false unmount(subTree, instance, parentSuspense, doRemove) }
然后在Scheduler執(zhí)行queue隊列任務(wù)的時候,那些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的設(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) } }
由此我們可以得知在一個組件更新的時候,會先把該組件在調(diào)度器里的更新任務(wù)先刪除。因為組件更新也是一個遞歸執(zhí)行更新的過程,在遞歸的過程中執(zhí)行了子組件的更新,那么調(diào)度器的任務(wù)隊列里面的子組件更新任務(wù)就不需要再執(zhí)行了,所以就要刪除掉,將來子組件依賴的響應(yīng)式數(shù)據(jù)發(fā)生了更新,那么則重新把子組件的更新任務(wù)放到調(diào)度器的任務(wù)隊列里去。
組件更新的調(diào)度器里的隊列任務(wù)的失效與刪除的區(qū)別
通過上述組件卸載的介紹我們可以總結(jié)一下組件更新的調(diào)度器里的隊列任務(wù)的失效與刪除的區(qū)別
失效
- 組件卸載時,將 Job 設(shè)置為失效,Job 從隊列中取出時,不再執(zhí)行
- 不能再次加入隊列,因為會被去重
- 被卸載的組件,無論它依賴的響應(yīng)式變量如何更新,該組件都不會更新了
刪除
- 組件更新時,刪除該組件在調(diào)度器任務(wù)隊列中的 Job
- 可以再次加入隊列
- 刪除任務(wù),因為已經(jīng)更新過了,不需要重復更新。 如果依賴的響應(yīng)式變量再次被修改,仍然需要加入調(diào)度器的任務(wù)隊列,等待更新
父子組件執(zhí)行順序與調(diào)度器的關(guān)系
假設(shè)有有這樣一個場景,有一對父子組件,子組件使用watch API監(jiān)聽某個子組件的響應(yīng)式數(shù)據(jù)發(fā)生改變之后,然后去修改了N個父組件的響應(yīng)式數(shù)據(jù)。那么N個父組件的更新函數(shù)都將被放到調(diào)度器的任務(wù)隊列中等待執(zhí)行。這種情況調(diào)度器怎么確保最頂層的父組件的更新函數(shù)最先執(zhí)行呢?
我們先看看調(diào)度器的任務(wù)隊列里的Job的數(shù)據(jù)結(jié)構(gòu)
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)度器任務(wù)隊列的數(shù)據(jù)結(jié)構(gòu)
const queue: SchedulerJob[] = []
是一個數(shù)組
調(diào)度器任務(wù)隊列的執(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)部的錯誤處理函數(shù)執(zhí)行job callWithErrorHandling(job, null, ErrorCodes.SCHEDULER) } } } finally { // 清空 queue 隊列 flushIndex = 0 queue.length = 0 }
那么又怎么確保父組件的更新函數(shù)的任務(wù)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ù)的任務(wù)id是一定大于父組件更新函數(shù)的id的。所以當調(diào)度器的任務(wù)隊列里面同時存在很多組件的更新函數(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的本質(zhì)
最后探討一下Hooks的本質(zhì)
Vue的Hooks設(shè)計是從React的Hooks那里借鑒過來的,React的Hooks的本質(zhì)就是把狀態(tài)變量、副作用函數(shù)存到函數(shù)組件的fiber對象上,等到將來狀態(tài)變量發(fā)生改變的時候,相關(guān)的函數(shù)組件fiber就重新進行更新。Vue3這邊的實現(xiàn)原理也類似,通過上面的生命周期的Hooks實現(xiàn)原理,我們可以知道Vue3的生命周期的Hooks是綁定到具體的組件實例上,而狀態(tài)變量,則因為Vue的變量是響應(yīng)式的,狀態(tài)變量會通過effect和具體的組件更新函數(shù)進行依賴收集,然后進行綁定,將來狀態(tài)變量發(fā)生改變的時候,相應(yīng)的組件更新函數(shù)會重新進入調(diào)度器的任務(wù)隊列進行調(diào)度執(zhí)行。
所以Hooks的本質(zhì)就是讓那些狀態(tài)變量或生命周期函數(shù)和組件綁定起來,組件運行到相應(yīng)時刻執(zhí)行相應(yīng)綁定的生命周期函數(shù),那些綁定的變量發(fā)生改變的時候,相應(yīng)的組件也重新進行更新。
最后
下一篇準備寫一下watch API的實現(xiàn)原理,同時watch API也需要和調(diào)度器結(jié)合進行理解,只有相互串聯(lián)理解才可以把Vue3底層設(shè)計和實現(xiàn)原理理解得更加透切一些。
最后推薦一個學習vue3源碼的庫,它是基于崔效瑞老師的開源庫mini-vue而來,在mini-vue的基礎(chǔ)上實現(xiàn)更多的vue3核心功能,用于深入學習 vue3, 讓你更輕松地理解 vue3 的核心邏輯。
源碼地址 https://github.com/amebyte/mini-vue3-plus
以上就是Vue3生命周期Hooks原理與調(diào)度器Scheduler關(guān)系的詳細內(nèi)容,更多關(guān)于Vue3 Hooks與Scheduler關(guān)系的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
vuejs通過filterBy、orderBy實現(xiàn)搜索篩選、降序排序數(shù)據(jù)
這篇文章主要為大家詳細介紹了vuejs通過filterBy、orderBy實現(xiàn)搜索篩選、降序排序數(shù)據(jù)實例,具有一定的參考價值,感興趣的小伙伴們可以參考一下2017-02-02vue-router3.x和vue-router4.x相互影響的問題分析
這篇文章主要介紹了vue-router3.x和vue-router4.x相互影響的問題分析,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-04-04vue?el-table實現(xiàn)動態(tài)添加行和列具體代碼
最近遇到一個動態(tài)增加行和列的需求,所以這里給大家總結(jié)下,這篇文章主要給大家介紹了關(guān)于vue?el-table實現(xiàn)動態(tài)添加行和列的相關(guān)資料,需要的朋友可以參考下2023-09-09vue如何統(tǒng)一樣式(reset.css與border.css)
這篇文章主要介紹了vue如何統(tǒng)一樣式(reset.css與border.css),具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-05-05Vue Element前端應(yīng)用開發(fā)之整合ABP框架的前端登錄
VUE+Element 前端是一個純粹的前端處理,前面介紹了很多都是Vue+Element開發(fā)的基礎(chǔ),從本章隨筆開始,就需要進入深水區(qū)了,需要結(jié)合ABP框架使用2021-05-05