Vue3生命周期Hooks的原理及其与调度器(Scheduler)的关系

Vue3生命周期的实现原理相对简单，但要了解整个生命周期Vue3的生命周期应与整个生命周期相结合Vue因为Vue一些生命周期的执行机制是通过Vue3的调度器是完成的，所以我想彻底了解它Vue还必须结合3的生命周期原理Vue了解调度器的实现原理。同时通过对Vue3.加深对调度器的理解Vue对一些设计原则和规则的理解，所以本文的目标是理解Vue3生命周期Hooks原则及通过Vue3生命周期Hooks的运行了解Vue3调度器(Scheduler)的原理。

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', // 卸载之后  // ... }  

// 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创建了这个函数

// 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通过闭包缓存绑定相应的生命周期定为闭包函数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     } }  

instance.update = effect(() => {     if (!instance.isMounted) {         const { bm, m } = instance         // 生命周期：beforeMount hook         if (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         // 生命周期：mounted         if(m) {             // mounted需要通过Scheduler调用函数             queuePostFlushCb(m)         }     } else {         // 响应值变更后，逻辑将从这里执行         // 主要是拿到新的 vnode ，和以前一样 vnode 进行对比          // 拿到最新的 subTree         const { bu, u, next, vnode } = instance         // 如果有 next 的话， 说明需要更新组件的数据（props，slots 等）         // 在继续比较当前组件的子元素之前，续比较当前组件的子元素         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调用函数             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的一些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 job
        while (job = queue.shift()) {
            job && job()
        }
    } finally {
        // 组件更新后队列执行
        flushPostFlushCbs(seen)
        // 如果在执行异步任务的过程中又产生了新的队列，那么则继续回调执行
        if (
            queue.length ||
            pendingPreFlushCbs.length ||
            pendingPostFlushCbs.length
        ) {
            flushJobs(seen)
        }
    }
} 

这里有两个概念需要厘清的概念，一：父子组件的执行顺序，二：父子组件生命周期的执行顺序。这两个是不一样的

这个是先执行父组件再执行子组件，先父组件实例化，然后去获取父组件的虚拟DOM之后在patch的过程中，如果父组件的虚拟DOM中存在组件类型的虚拟DOM也就是子组件，那么在patch的分支中就会去走组件初始化的流程，如此循环。

父子组件生命周期的执行顺序是在父子组件的执行顺序下通过调度算法按Vue的规则进行执行的。首先父组件先实例化进行执行，通过上面的生命周期的调用说明，我们可以知道，父组件在更新函数update第一次执行，也就是组件初始化的时候，先执行父组件的beforeMount，然后去获取父组件的虚拟DOM，然后在patch的过程中遇到虚拟节点是组件类型的时候，就又会去走组件初始化的流程，这个时候其实就是子组件初始化，那么之后子组件也需要走一遍组件的所有流程，子组件在更新update第一次执行的时候，先执行子组件的beforeMount，再去获取子组件的虚拟DOM，然后patch子组件的虚拟DOM，如果过程中又遇到节点是组件类型的话，又去走一遍组件初始化的流程，直到子组件patch完成，然后执行子组件的mounted生命周期函数，接着回到父组件的执行栈，执行父组件的mounted生命周期。

所以在初始化创建的时候，是深度递归创建子组件的过程，父子组件的生命周期的执行顺序是：

1. 父组件 -> beforeMount
2. 子组件 -> beforeMount
3. 子组件 -> mounted
4. 父组件 -> mounted

父子组件更新顺序同样是深度递归执行的过程：

1. 如果父子组件没通过props传递数据，那么更新的时候，就各自执行各自的更新生命周期函数。
2. 如果父子组件存在通过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 = 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)
	// ...
  } 

所以在父子组件更新的时候，父子组件的生命周期执行顺序是：

1. 父组件 -> beforeUpdate
2. 子组件 -> beforeUpdate
3. 子组件 -> updated
4. 父组件 -> updated

同样卸载的时候父子组件也是深度递归遍历执行的过程：

1. 父组件 -> beforeUnmount
2. 子组件 -> beforeUnmount
3. 子组件 -> unmounted
4. 父组件 -> unmounted

组件卸载的时候主要是卸载模版引用，清除effect里面保存的相关组件的更新函数的副作用函数，如果是缓存组件，则清除相关缓存，最后去移除真实DOM上相关节点。

另外组件 DOM 更新（instance.update）是有保存在调度器的任务队列中的，组件卸载的时候，也需要把相关的组件更新（instance.update）设置失效。

在源码的unmountComponent函数中，有这么一段：

if (update) {
    // 把组件更新函数的active设置false
    update.active = false
    unmount(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) {
    // 删除 Job
    queue.splice(i, 1)
  }
} 

由此我们可以得知在一个组件更新的时候，会先把该组件在调度器里的更新任务先删除。因为组件更新也是一个递归执行更新的过程，在递归的过程中执行了子组件的更新，那么调度器的任务队列里面的子组件更新任务就不需要再执行了，所以就要删除掉，将来子组件依赖的响应式数据发生了更新，那么则重新把子组件的更新任务放到调度器的任务队列里去。

通过上述组件卸载的介绍我们可以总结一下组件更新的调度器里的队列任务的失效与删除的区别

失效

• 组件卸载时，将 Job 设置为失效，Job 从队列中取出时，不再执行
• 不能再次加入队列，因为会被去重
• 被卸载的组件，无论它依赖的响应式变量如何更新，该组件都不会更新了

删除

• 组件更新时，删除该组件在调度器任务队列中的 Job
• 可以再次加入队列
• 删除任务，因为已经更新过了，不需要重复更新。 如果依赖的响应式变量再次被修改，仍然需要加入调度器的任务队列，等待更新

假设有有这样一个场景，有一对父子组件，子组件使用watch API监听某个子组件的响应式数据发生改变之后，然后去修改了N个父组件的响应式数据。那么N个父组件的更新函数都将被放到调度器的任务队列中等待执行。这种情况调度器怎么确保最顶层的父组件的更新函数最先执行呢？

我们先看看调度器的任务队列里的Job的数据结构

export interface SchedulerJob extends Function {
  id?: number  // 用于对队列中的 job 进行排序，id 小的先执行
  active?: boolean
  computed?: boolean
  allowRecurse?: 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 内部的错误处理函数执行job
            callWithErrorHandling(job, null, ErrorCodes.SCHEDULER)
        }
    }
} finally {
    // 清空 queue 队列
    flushIndex = 0
    queue.length = 0
} 

那么又怎么确保父组件的更新函数的任务id是最小的呢？

通过查看源码我们可以看在创建组件实例的createComponentInstance函数中有一个uid的属性，并且它的初始值为0，后续则++

let uid = 0 // 初始化为0
export function createComponentInstance( vnode
  parent
  suspense ) {
  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的本质

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