Vue3 生命周期Hooks函数与调度器Scheduler的原理
大廠技術??高級前端??Node進階
點擊上方?程序員成長指北,關注公眾號
回復1,加入高級Node交流群
寫在最前:本文章的目標
Vue3的生命周期的實現原理是比較簡單的,但要理解整個Vue3的生命周期則還要結合整個Vue的運行原理,又因為Vue3的一些生命周期的執行機制是通過Vue3的調度器來完成的,所以想要徹底了解Vue3的生命周期原理還必須要結合Vue3的調度器的實現原理來理解。同時通過對Vue3的調度器的理解,從而加深對Vue底層的一些設計原理和規則的理解,所以本文章的目標是理解Vue3生命周期Hooks的原理以及通過Vue3生命周期Hooks的運行了解Vue3調度器(Scheduler)的原理。
Vue3生命周期的實現原理
Vue3的生命周期Hooks函數的實現原理還是比較簡單的,就是把各個生命周期的函數掛載或者叫注冊到組件的實例上,然后等到組件運行到某個時刻,再去組件實例上把相應的生命周期的函數取出來執行。
下面來看看具體代碼的實現
生命周期類型
//?packages/runtime-core/src/component.ts export?const?enum?LifecycleHooks?{BEFORE_CREATE?=?'bc',?//?創建之前CREATED?=?'c',?//?創建BEFORE_MOUNT?=?'bm',?//?掛載之前MOUNTED?=?'m',?//?掛載之后BEFORE_UPDATE?=?'bu',?//?更新之前UPDATED?=?'u',?//?更新之后BEFORE_UNMOUNT?=?'bum',?//?卸載之前UNMOUNTED?=?'um',?//?卸載之后//?... } 復制代碼各個生命周期Hooks函數的創建
//?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函數是通過createHook這個函數創建的
創建生命周期函數createHook
//?packages/runtime-core/src/apiLifecycle.ts export?const?createHook?=?(lifecycle)?=>?(hook,?target?=?currentInstance)?=>?injectHook(lifecycle,?hook,?target) 復制代碼createHook是一個閉包函數,通過閉包緩存當前是屬于哪個生命周期的Hooks,target表示該生命周期Hooks函數被綁定到哪個組件實例上,默認是當前工作的組件實例。createHook底層又調用了一個injectHook的函數,那么下面我們繼續來看看這個injectHook函數。
injectHook函數
injectHook是一個閉包函數,通過閉包緩存綁定對應生命周期Hooks到對應的組件實例上。
//?packages/runtime-core/src/apiLifecycle.ts export?function?injectHook(type,?hook,?target)?{if(target)?{//?把各個生命周期的Hooks函數掛載到組件實例上,并且是一個數組,因為可能你會多次調用同一個組件的同一個生命周期函數const?hooks?=?target[type]?||?(target[type]?=?[])//?把生命周期函數進行包裝并且把包裝函數緩存在__weh上const?wrappedHook?=hook.__weh?||(hook.__weh?=?(...args:?unknown[])?=>?{if?(target.isUnmounted)?{return}//?當生命周期調用時?保證currentInstance是正確的setCurrentInstance(target)//?執行生命周期Hooks函數const??res?=?args???hook(...args)?:?hook()unsetCurrentInstance()return?res})//?把生命周期的包裝函數綁定到組件實例對應的hooks上hooks.push(wrappedHook)//?返回包裝函數return?wrappedHook} } 復制代碼生命周期Hooks的調用
instance.update?=?effect(()?=>?{if?(!instance.isMounted)?{const?{?bm,?m?}?=?instance//?生命周期:beforeMount hookif?(bm)?{invokeArrayFns(bm)}//?組件初始化的時候會執行這里//?為什么要在這里調用?render?函數呢//?是因為在?effect?內調用?render?才能觸發依賴收集//?等到后面響應式的值變更后會再次觸發這個函數??const?subTree?=?(instance.subTree?=?renderComponentRoot(instance))patch(null,?subTree,?container,?instance,?anchor)instance.vnode.el?=?subTree.el?instance.isMounted?=?true//?生命周期:mountedif(m)?{//?mounted需要通過Scheduler的函數來調用queuePostFlushCb(m)}}?else?{//?響應式的值變更后會從這里執行邏輯//?主要就是拿到新的?vnode?,然后和之前的?vnode?進行對比//?拿到最新的?subTreeconst?{?bu,?u,?next,?vnode?}?=?instance//?如果有?next?的話,?說明需要更新組件的數據(props,slots?等)//?先更新組件的數據,然后更新完成后,在繼續對比當前組件的子元素if(next)?{next.el?=?vnode.elupdateComponentPreRender(instance,?next)}//?生命周期:beforeUpdate hookif?(bu)?{invokeArrayFns(bu)}const?subTree?=?renderComponentRoot(instance)//?替換之前的?subTreeconst?prevSubTree?=?instance.subTreeinstance.subTree?=?subTree//?用舊的?vnode?和新的?vnode?交給?patch?來處理patch(prevSubTree,?subTree,?container,?instance,?anchor)//?生命周期:updated hookif?(u)?{//?updated?需要通過Scheduler的函數來調用queuePostFlushCb(u)}} },?{scheduler()?{queueJobs(instance.update)} }) 復制代碼上面這個是Vue3組件實例化之后,通過effect包裝一個更新的副作用函數來和響應式數據進行依賴收集。在這個副作用函數里面有兩個分支,第一個是組件掛載之前執行的,也就是生命周期函數beforeMount和mount調用的地方,第二個分支是組件掛載之后更新的時候執行的,在這里就是生命周期函數beforeUpdate和updated調用的地方。具體就是在掛載之前,還沒生成虛擬DOM之前就執行beforeMount函數,之后則去生成虛擬DOM經過patch之后,組件已經被掛載到頁面上了,也就是頁面上顯示視圖了,這個時候就去執行mount函數;在更新的時候,還沒獲取更新之后的虛擬DOM之前執行beforeUpdate,然后去獲取更新之后的虛擬DOM,然后再去patch,更新視圖,之后就執行updated。需要注意的是beforeMount和beforeUpdate是同步執行的,都是通過invokeArrayFns來調用的。invokeArrayFns函數
export?const?invokeArrayFns?=?(fns:?Function[],?arg?:?any)?=>?{for?(let?i?=?0;?i?<?fns.length;?i++)?{fns[i](arg)} } 復制代碼組件掛載和更新則是異步的,需要通過Scheduler來處理。
Vue3調度器(Scheduler)原理
在Vue3的一些API,例如:組件的生命周期API、watch API、組件更新的回調函數都不是立即執行的,而是放到異步任務隊列里面,然后按一定的規則進行執行的,比如說任務隊列里面同時存在,watch的任務,組件更新的任務,生命周期的任務,它的執行順序是怎么樣的呢?這個就是由調度器的調度算法決定,同時調度算法只調度執行的順序,不負責具體的執行。這樣設計的好處就是即便將來Vue3增加新的異步回調API,也不需要修改調度算法,可以極大的減少 Vue API 和 隊列間耦合。Vue3的Scheduler提供了三個入列方式的API:
queuePreFlushCb API: 加入 Pre 隊列 組件更新前執行
export?function?queuePreFlushCb(cb:?SchedulerJob)?{queueCb(cb,?activePreFlushCbs,?pendingPreFlushCbs,?preFlushIndex) } 復制代碼queueJob API: 加入 queue 隊列 組件更新執行
export?function?queueJob(job:?SchedulerJob)?{} 復制代碼queuePostFlushCb API: 加入 Post 隊列 組件更新后執行
export?function?queuePostFlushCb(cb:?SchedulerJobs)?{queueCb(cb,?activePostFlushCbs,?pendingPostFlushCbs,?postFlushIndex) } 復制代碼由于Vue3只提供了入列方式的API并沒有提供出列方式的API,所以我們只能控制何時入列,而何時出列則由Vue3調度器本身控制。
那么Vue3調度器如何控制出列方式呢?其實也很簡單。
function?flushJobs(seen?)?{isFlushPending?=?false//?組件更新前隊列執行flushPreFlushCbs(seen)try{//?組件更新隊列執行let?jobwhile?(job?=?queue.shift())?{job?&&?job()}}?finally?{//?組件更新后隊列執行flushPostFlushCbs(seen)//?如果在執行異步任務的過程中又產生了新的隊列,那么則繼續回調執行if?(queue.length?||pendingPreFlushCbs.length?||pendingPostFlushCbs.length)?{flushJobs(seen)}} } 復制代碼Vue父子組件的生命周期的執行順序
這里有兩個概念需要厘清的概念,一:父子組件的執行順序,二:父子組件生命周期的執行順序。這兩個是不一樣的
父子組件的執行順序
這個是先執行父組件再執行子組件,先父組件實例化,然后去獲取父組件的虛擬DOM之后在patch的過程中,如果父組件的虛擬DOM中存在組件類型的虛擬DOM也就是子組件,那么在patch的分支中就會去走組件初始化的流程,如此循環。
父子組件生命周期的執行順序
父子組件生命周期的執行順序是在父子組件的執行順序下通過調度算法按Vue的規則進行執行的。首先父組件先實例化進行執行,通過上面的生命周期的調用說明,我們可以知道,父組件在更新函數update第一次執行,也就是組件初始化的時候,先執行父組件的beforeMount,然后去獲取父組件的虛擬DOM,然后在patch的過程中遇到虛擬節點是組件類型的時候,就又會去走組件初始化的流程,這個時候其實就是子組件初始化,那么之后子組件也需要走一遍組件的所有流程,子組件在更新update第一次執行的時候,先執行子組件的beforeMount,再去獲取子組件的虛擬DOM,然后patch子組件的虛擬DOM,如果過程中又遇到節點是組件類型的話,又去走一遍組件初始化的流程,直到子組件patch完成,然后執行子組件的mounted生命周期函數,接著回到父組件的執行棧,執行父組件的mounted生命周期。
所以在初始化創建的時候,是深度遞歸創建子組件的過程,父子組件的生命周期的執行順序是:
父組件 -> beforeMount
子組件 -> beforeMount
子組件 -> mounted
父組件 -> mounted
父子組件更新順序同樣是深度遞歸執行的過程:
如果父子組件沒通過props傳遞數據,那么更新的時候,就各自執行各自的更新生命周期函數。
如果父子組件存在通過props傳遞數據的話,就必須先更新父組件,才能更新子組件。因為父組件 DOM 更新前,需要修改子組件的 props,子組件的 props 才是正確的值。
下面我們來看源碼
if?(next)?{next.el?=?vnode.el//?在組件更新前,先更新一些數據updateComponentPreRender(instance,?next,?optimized) }?else?{next?=?vnode } 復制代碼例如更新props,更新slots
const?updateComponentPreRender?=?(instance:?ComponentInternalInstance,nextVNode:?VNode,optimized:?boolean)?=>?{nextVNode.component?=?instanceconst?prevProps?=?instance.vnode.propsinstance.vnode?=?nextVNodeinstance.next?=?null//?更新propsupdateProps(instance,?nextVNode.props,?prevProps,?optimized)//?更新slotsupdateSlots(instance,?nextVNode.children,?optimized)//?...} 復制代碼所以在父子組件更新的時候,父子組件的生命周期執行順序是:
父組件 -> beforeUpdate
子組件 -> beforeUpdate
子組件 -> updated
父組件 -> updated
同樣卸載的時候父子組件也是深度遞歸遍歷執行的過程:
父組件 -> beforeUnmount
子組件 -> beforeUnmount
子組件 -> unmounted
父組件 -> unmounted
組件卸載的時候,是在卸載些什么呢?
組件卸載的時候主要是卸載模版引用,清除effect里面保存的相關組件的更新函數的副作用函數,如果是緩存組件,則清除相關緩存,最后去移除真實DOM上相關節點。
另外組件 DOM 更新(instance.update)是有保存在調度器的任務隊列中的,組件卸載的時候,也需要把相關的組件更新(instance.update)設置失效。
在源碼的unmountComponent函數中,有這么一段:
if?(update)?{//?把組件更新函數的active設置falseupdate.active?=?falseunmount(subTree,?instance,?parentSuspense,?doRemove) } 復制代碼然后在Scheduler執行queue隊列任務的時候,那些job的active為false的則不執行
const?job?=?queue[flushIndex] //?那些job的active為false的則不執行 if?(job?&&?job.active?!==?false)?{callWithErrorHandling(job,?null,?ErrorCodes.SCHEDULER) } 復制代碼那么組件 DOM 更新(instance.update)什么時候會被刪除呢?
在源碼的updateComponent函數可以找到刪除instance.update的設置
invalidateJob(instance.update) //?立即執行更新任務 instance.update() 復制代碼調度器刪除任務
export?function?invalidateJob(job:?SchedulerJob)?{//?找到?job?的索引const?i?=?queue.indexOf(job)if?(i?>?flushIndex)?{//?刪除?Jobqueue.splice(i,?1)} } 復制代碼由此我們可以得知在一個組件更新的時候,會先把該組件在調度器里的更新任務先刪除。因為組件更新也是一個遞歸執行更新的過程,在遞歸的過程中執行了子組件的更新,那么調度器的任務隊列里面的子組件更新任務就不需要再執行了,所以就要刪除掉,將來子組件依賴的響應式數據發生了更新,那么則重新把子組件的更新任務放到調度器的任務隊列里去。
組件更新的調度器里的隊列任務的失效與刪除的區別
通過上述組件卸載的介紹我們可以總結一下組件更新的調度器里的隊列任務的失效與刪除的區別
失效
組件卸載時,將 Job 設置為失效,Job 從隊列中取出時,不再執行
不能再次加入隊列,因為會被去重
被卸載的組件,無論它依賴的響應式變量如何更新,該組件都不會更新了
刪除
組件更新時,刪除該組件在調度器任務隊列中的 Job
可以再次加入隊列
刪除任務,因為已經更新過了,不需要重復更新。如果依賴的響應式變量再次被修改,仍然需要加入調度器的任務隊列,等待更新
父子組件執行順序與調度器的關系
假設有有這樣一個場景,有一對父子組件,子組件使用watch API監聽某個子組件的響應式數據發生改變之后,然后去修改了N個父組件的響應式數據。那么N個父組件的更新函數都將被放到調度器的任務隊列中等待執行。這種情況調度器怎么確保最頂層的父組件的更新函數最先執行呢?
我們先看看調度器的任務隊列里的Job的數據結構
export?interface?SchedulerJob?extends?Function?{id?:?number??//?用于對隊列中的?job?進行排序,id?小的先執行active?:?booleancomputed?:?booleanallowRecurse?:?boolean?ownerInstance?:?ComponentInternalInstance? } 復制代碼Job是一個函數,并且帶有一些屬性。其中id,表示優先級,用于實現隊列插隊,id 小的先執行,active通過上文我們可以知道active表示 Job 是否有效,失效的 Job 不執行,如組件卸載會導致 Job 失效。
調度器任務隊列的數據結構
const?queue:?SchedulerJob[]?=?[] 復制代碼是一個數組
調度器任務隊列的執行
//?按任務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?內部的錯誤處理函數執行jobcallWithErrorHandling(job,?null,?ErrorCodes.SCHEDULER)}} }?finally?{//?清空?queue?隊列flushIndex?=?0queue.length?=?0 } 復制代碼那么又怎么確保父組件的更新函數的任務id是最小的呢?
通過查看源碼我們可以看在創建組件實例的createComponentInstance函數中有一個uid的屬性,并且它的初始值為0,后續則++
let?uid?=?0?//?初始化為0 export?function?createComponentInstance(vnodeparentsuspense )?{const?instance:?ComponentInternalInstance?=?{uid:?uid++,//?...???} 復制代碼然后在創建組件更新函數的時候可以看到,組件更新函數的id就是該組件實例的uid
const?update?=?(instance.update?=?effect.run.bind(effect)?as?SchedulerJob) update.id?=?instance.uid 復制代碼組件創建的過程是深度遞歸創建子組件的過程,所以最先的父組件是0,后面的子組件則一路++上去,這樣就確保了子組件的更新函數的任務id是一定大于父組件更新函數的id的。所以當調度器的任務隊列里面同時存在很多組件的更新函數的時候,通過優先級排序,就可以確保一定父組件的更新函數最先執行了。
當前中途也可以進行插隊
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的本質就是把狀態變量、副作用函數存到函數組件的fiber對象上,等到將來狀態變量發生改變的時候,相關的函數組件fiber就重新進行更新。Vue3這邊的實現原理也類似,通過上面的生命周期的Hooks實現原理,我們可以知道Vue3的生命周期的Hooks是綁定到具體的組件實例上,而狀態變量,則因為Vue的變量是響應式的,狀態變量會通過effect和具體的組件更新函數進行依賴收集,然后進行綁定,將來狀態變量發生改變的時候,相應的組件更新函數會重新進入調度器的任務隊列進行調度執行。
所以Hooks的本質就是讓那些狀態變量或生命周期函數和組件綁定起來,組件運行到相應時刻執行相應綁定的生命周期函數,那些綁定的變量發生改變的時候,相應的組件也重新進行更新。
最后
下一篇準備寫一下watch API的實現原理,同時watch API也需要和調度器結合進行理解,只要相互串聯理解才可以把Vue3底層設計和實現原理理解得更加透切一些。
最后推薦一個學習vue3源碼的庫,它是基于崔效瑞老師的開源庫mini-vue而來,在mini-vue的基礎上實現更多的vue3核心功能,用于深入學習 vue3, 讓你更輕松地理解 vue3 的核心邏輯。
Github地址:mini-vue3-plus[1]
關于本文
作者:Cobyte
https://juejin.cn/post/7093880734246502414
總結
以上是生活随笔為你收集整理的Vue3 生命周期Hooks函数与调度器Scheduler的原理的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 千万数据去重_基于 Flink 的百亿数
- 下一篇: 性与潜能:性能量是一切天才的创造力源泉