大廠(chǎng)技術(shù)??高級(jí)前端??Node進(jìn)階

點(diǎn)擊上方?程序員成長(zhǎng)指北，關(guān)注公眾號(hào)

回復(fù)1，加入高級(jí)Node交流群

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

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

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

生命周期類(lèi)型

//?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',?//?卸載之后//?... } 復(fù)制代碼

各個(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) 復(fù)制代碼

可以看到各個(gè)生命周期的Hooks函數(shù)是通過(guò)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) 復(fù)制代碼

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

injectHook函數(shù)

injectHook是一個(gè)閉包函數(shù)，通過(guò)閉包緩存綁定對(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} } 復(fù)制代碼

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

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

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

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

組件掛載和更新則是異步的，需要通過(guò)Scheduler來(lái)處理。

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

在Vue3的一些API，例如：組件的生命周期API、watch API、組件更新的回調(diào)函數(shù)都不是立即執(zhí)行的，而是放到異步任務(wù)隊(duì)列里面，然后按一定的規(guī)則進(jìn)行執(zhí)行的，比如說(shuō)任務(wù)隊(duì)列里面同時(shí)存在，watch的任務(wù)，組件更新的任務(wù)，生命周期的任務(wù)，它的執(zhí)行順序是怎么樣的呢？這個(gè)就是由調(diào)度器的調(diào)度算法決定，同時(shí)調(diào)度算法只調(diào)度執(zhí)行的順序，不負(fù)責(zé)具體的執(zhí)行。這樣設(shè)計(jì)的好處就是即便將來(lái)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) } 復(fù)制代碼

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

export?function?queueJob(job:?SchedulerJob)?{} 復(fù)制代碼

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

export?function?queuePostFlushCb(cb:?SchedulerJobs)?{queueCb(cb,?activePostFlushCbs,?pendingPostFlushCbs,?postFlushIndex) } 復(fù)制代碼

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

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

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

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

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

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

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

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

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

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

父組件 -> beforeMount

子組件 -> beforeMount

子組件 -> mounted

父組件 -> mounted

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

如果父子組件沒(méi)通過(guò)props傳遞數(shù)據(jù)，那么更新的時(shí)候，就各自執(zhí)行各自的更新生命周期函數(shù)。

如果父子組件存在通過(guò)props傳遞數(shù)據(jù)的話(huà)，就必須先更新父組件，才能更新子組件。因?yàn)楦附M件 DOM 更新前，需要修改子組件的 props，子組件的 props 才是正確的值。

下面我們來(lái)看源碼

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

例如更新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)//?...} 復(fù)制代碼

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

父組件 -> beforeUpdate

子組件 -> beforeUpdate

子組件 -> updated

父組件 -> updated

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

父組件 -> 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è)置falseupdate.active?=?falseunmount(subTree,?instance,?parentSuspense,?doRemove) } 復(fù)制代碼

然后在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) } 復(fù)制代碼

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

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

invalidateJob(instance.update) //?立即執(zhí)行更新任務(wù) instance.update() 復(fù)制代碼

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

export?function?invalidateJob(job:?SchedulerJob)?{//?找到?job?的索引const?i?=?queue.indexOf(job)if?(i?>?flushIndex)?{//?刪除?Jobqueue.splice(i,?1)} } 復(fù)制代碼

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

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

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

失效

• 組件卸載時(shí)，將 Job 設(shè)置為失效，Job 從隊(duì)列中取出時(shí)，不再執(zhí)行

• 不能再次加入隊(duì)列，因?yàn)闀?huì)被去重

• 被卸載的組件，無(wú)論它依賴(lài)的響應(yīng)式變量如何更新，該組件都不會(huì)更新了

刪除

• 組件更新時(shí)，刪除該組件在調(diào)度器任務(wù)隊(duì)列中的 Job

• 可以再次加入隊(duì)列

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

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

假設(shè)有有這樣一個(gè)場(chǎng)景，有一對(duì)父子組件，子組件使用watch API監(jiān)聽(tīng)某個(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?:?booleancomputed?:?booleanallowRecurse?:?boolean?ownerInstance?:?ComponentInternalInstance? } 復(fù)制代碼

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

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

const?queue:?SchedulerJob[]?=?[] 復(fù)制代碼

是一個(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í)行jobcallWithErrorHandling(job,?null,?ErrorCodes.SCHEDULER)}} }?finally?{//?清空?queue?隊(duì)列flushIndex?=?0queue.length?=?0 } 復(fù)制代碼

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

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

let?uid?=?0?//?初始化為0 export?function?createComponentInstance(vnodeparentsuspense )?{const?instance:?ComponentInternalInstance?=?{uid:?uid++,//?...???} 復(fù)制代碼

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

const?update?=?(instance.update?=?effect.run.bind(effect)?as?SchedulerJob) update.id?=?instance.uid 復(fù)制代碼

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

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

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

Hooks的本質(zhì)

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

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

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

最后

下一篇準(zhǔn)備寫(xiě)一下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āi)源庫(kù)mini-vue而來(lái)，在mini-vue的基礎(chǔ)上實(shí)現(xiàn)更多的vue3核心功能，用于深入學(xué)習(xí) vue3， 讓你更輕松地理解 vue3 的核心邏輯。

Github地址：mini-vue3-plus^[1]

關(guān)于本文

作者：Cobyte

https://juejin.cn/post/7093880734246502414

Node 社群我組建了一個(gè)氛圍特別好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你對(duì)Node.js學(xué)習(xí)感興趣的話(huà)（后續(xù)有計(jì)劃也可以），我們可以一起進(jìn)行Node.js相關(guān)的交流、學(xué)習(xí)、共建。下方加 考拉 好友回復(fù)「Node」即可。如果你覺(jué)得這篇內(nèi)容對(duì)你有幫助，我想請(qǐng)你幫我2個(gè)小忙：1. 點(diǎn)個(gè)「在看」，讓更多人也能看到這篇文章2. 訂閱官方博客?www.inode.club?讓我們一起成長(zhǎng)點(diǎn)贊和在看就是最大的支持

總結(jié)

以上是生活随笔為你收集整理的Vue3 生命周期Hooks函数与调度器Scheduler的原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。