--- theme: qklhk-chocolate highlight: a11y-dark --- > 您说什么、希望什么、期待什么、想什么都不重要，只有你做了什么才算数 >
>
> ------博恩.崔西 # 前言这是一个Vue源码系列文章，建议从第一篇文章 [Vue源码系列（一）：Vue源码解读的正确姿势](https://juejin.cn/post/7017628727345414152/ "https://juejin.cn/post/7017628727345414152/") 开始阅读。文章是我个人学习源码的一个历程，这边分享出来希望对大家有所帮助。本文要讲解的是Vue异步更新机制和nextTick原理。
大家都知道，异步更新和响应式原理一样，都是Vue的核心之一。在我们使用Vue的过程中，基本大部分的 *watcher* 更新都需要经过异步更新的处理。而 *nextTick* 则是异步更新的核心。
接下来我将从源码入手，然后再以例子讲解，让小伙伴们都能弄懂这Vue的一个核心原理。 # 源码解析源码解析我们需要找一个入口，那入口又是什么呢？？
在上上篇文章 [Vue源码系列（三）：数据响应式原理🔥🔥](https://juejin.cn/post/7019960001942781989) 中咱们说了vue的数据响应式原理，其中在 *dep.js*（也就是“代码块8”）中，我们说过一个方法：*notify()*，当时我对他的解析是：*通知更新*。它就是本篇文章的入口，不记得的可以回顾一下上上篇文章。
接下来从入口 *notify()* 方法，开始本章的源码解读。 ## dep.js ```js 代码块 1 // src/core/observer/dep.js ... // 遍历dep的所有watcher 然后执行他们的update notify () { // 获取dep所收集的所有watcher const subs = this.subs.slice() // 在非生产环境并且同步执行的时候做排序处理 if (process.env.NODE_ENV !== 'production' && !config.async) { subs.sort((a, b) => a.id - b.id) } // 遍历所有watcher，并执行他们各自的update()方法 for (let i = 0, l = subs.length; i < l; i++) { subs[i].update() } } ... ``` ## watcher.js 接下来看看 *watcher* 调用的 update() 方法具体做了什么。 ```js 代码块 2 // src/core/observer/watcher.js ... // 更新 update () { if (this.lazy) { // 懒执行走这里，比如：computed（） this.dirty = true } else if (this.sync) { // 同步执行更新视图执行下面的run函数 this.run() } else { // 异步推送进入更新队列将watcher放到观察者队列中具体实现查看【代码块 3】 queueWatcher(this) } } // 更新视图 run () { if (this.active) { // 调用get方法 const value = this.get() if ( value !== this.value || isObject(value) || this.deep ) { // 更新旧值为新值 const oldValue = this.value this.value = value if (this.user) { const info = `callback for watcher "${this.expression}"` invokeWithErrorHandling(this.cb, this.vm, [value, oldValue], this.vm, info) } else { // 渲染watcher this.cb.call(this.vm, value, oldValue) } } } } ... ``` ## scheduler.js 继续看看将watcher放到观察者队列中的 queueWatcher 方法 ```js 【代码块 3】 // /src/core/observer/scheduler.js export function queueWatcher (watcher: Watcher) { const id = watcher.id /** * 当我们调用某个watcher的callback之前会先将它在has中的标记置为null * * 注意这里是==而不是=== * 如果has[id]不存在，则has[id]为undefined,undefined==null结果为true * 如果has[id]存在且为null，则为true * 如果has[id]存在且为true，则为false * 这个if表示，如果这个watcher尚未被 flush 则 return */ // 做一个判重如果 watcher 已经存在，则不会重复进入队列 if (has[id] == null) { // 再次把watcher置为true 说明已经在队列中了保证只有一个watcher，避免重复 has[id] = true if (!flushing) { // 如果没有在刷新队列中，则将watcher push入队列中 queue.push(watcher) } else { // 如果在刷新队列中则根据当前 watcher.id 遍历 // 这个循环其实是在处理边界情况。即：在watcher队列更新过程中，用户再次更新了队列中的某个watcher let i = queue.length - 1 while (i > index && queue[i].id > watcher.id) { i-- } // 倒序查找，找到小于自己的则将自己插入下一个位置 queue.splice(i + 1, 0, watcher) } if (!waiting) { // 通过waiting 保证nextTick只执行一次 waiting = true // 在非生产环境并且同步执行的时候刷新调度队列 if (process.env.NODE_ENV !== 'production' && !config.async) { flushSchedulerQueue() return } // 最终会把所有更新动作（flushSchedulerQueue）放入nextTick中，推入到异步队列中执行 nextTick(flushSchedulerQueue) } } } ``` ## next-tick.js 最后就是看看nextTick具体做了什么。 ```js 【代码块 4】 // src/core/util/next-tick.js // 引入一些需要的方法 import { noop } from 'shared/util' import { handleError } from './error' import { isIE, isIOS, isNative } from './env' // 是否使用微任务 export let isUsingMicroTask = false // 其实就是需要处理的事件队列 const callbacks = [] // 如果已经有timerFunc推送到任务队列中则不再推送 let pending = false // 最终执行nextTick方法传进来的回调函数（执行事件队列中的事件） function flushCallbacks () { pending = false const copies = callbacks.slice(0) callbacks.length = 0 // 遍历callbacks，执行存储在其中的flushSchedulerQueue函数 for (let i = 0; i < copies.length; i++) { copies[i]() } } /** * 这里先翻译一下源码中注释的大概意思, 以下是对源码注释的一个翻译： * * Here we have async deferring wrappers using microtasks. * 这里我们使用微任务的异步延迟包装器 * In 2.5 we used (macro) tasks (in combination with microtasks). * 在 2.5 版本我们使用宏任务和微任务相结合 * However, it has subtle problems when state is changed right before repaint * 然而，当状态在重新绘制之前更改时，有一些微妙的问题 * Also, using (macro) tasks in event handler would cause some weird behaviors * 此外，在事件处理程序中使用宏任务会导致一些无法回避的奇怪行为 * So we now use microtasks everywhere, again. * 所以我们现在重新使用微任务（microtasks） * A major drawback of this tradeoff is that there are some scenarios where microtasks have too high a priority and fire in between supposedly sequential events or even between bubbling of the same event * 这种权衡的一个主要缺点是，在某些情况下，微任务的优先级太高，在假定的连续事件之间，甚至在同一事件的冒泡之间触发 * */ // 设置一个函数指针，将该指针添加到任务队列，待主线程任务执行完毕后，再将任务队列中的 timerFunc 函数添加到执行栈中执行 let timerFunc /** * 这边其实是一个“优雅降级”处理 * 执行的优先顺序为 promise => MutationObserver => setImmediate => setTimeout */ // 首先判断是否原生支持Promise if (typeof Promise !== 'undefined' && isNative(Promise)) { const p = Promise.resolve() timerFunc = () => { p.then(flushCallbacks) if (isIOS) setTimeout(noop) } isUsingMicroTask = true // 其次判断是否原生支持MutationObserver // MutationObserver: 该方法提供了监视对DOM树所做更改的能力 } else if (!isIE && typeof MutationObserver !== 'undefined' && ( isNative(MutationObserver) || MutationObserver.toString() === '[object MutationObserverConstructor]' )) { let counter = 1 // 如果支持MutationObserver 用MutationObserver执行flushCallbacks const observer = new MutationObserver(flushCallbacks) const textNode = document.createTextNode(String(counter)) observer.observe(textNode, { characterData: true }) timerFunc = () => { counter = (counter + 1) % 2 textNode.data = String(counter) } isUsingMicroTask = true // 再次判断是否原生支持setImmediate } else if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) { timerFunc = () => { // 如果原生支持setImmediate 用setImmediate执行flushCallbacks // 该方法用来把一些需要长时间运行的操作放在一个回调函数里，在浏览器完成后面的其他语句后，就立刻执行这个回调函数。 setImmediate(flushCallbacks) } // 最后都不支持的情况下则使用setTimeout来兜底 } else { timerFunc = () => { setTimeout(flushCallbacks, 0) } } // 将回调函数cb包装成一个箭头函数push到事件队列callbacks中 export function nextTick (cb?: Function, ctx?: Object) { let _resolve // 向事件队列中添加箭头函数作为参数，并且使用callbacks存储包装好的cb函数 callbacks.push(() => { if (cb) { // try catch 包装回调函数，是为了错误捕获 try { cb.call(ctx) } catch (e) { handleError(e, ctx, 'nextTick') } } else if (_resolve) { _resolve(ctx) } }) // 在事件队列执行(flushCallbacks调用)的时候pending才设为false // pending 为 flushCallbacks 被添加到队列里到尚未执行这段时间 if (!pending) { pending = true timerFunc() } if (!cb && typeof Promise !== 'undefined') { return new Promise(resolve => { _resolve = resolve }) } } ``` # 源码解析小结到此就是vue异步更新源码和nextTick的源码解析。咱们稍作总结一下： - 异步更新机制是vue的核心原理之一，主要运用的是浏览器的异步任务队列。（这里之后会出一个Event Loop的文章，之后文章OK以后再把链接贴上来） - 数据更新以后调用 *dep.js* 中的 *notify()* 遍历 *dep* 的所有 *watcher*，然后执行他们的 *update()* - 然后 *watcher.js* 中的 *update()* 将 *watcher* 放到观察者队列中， - 最后执行 *scheduler.js* 中的 *queueWatcher()* 最终会把所有更新动作（flushSchedulerQueue）放入 *nextTick*中，并推入到异步队列中执行。在回调中，对 *queueWatcher()* 中的 *watcher* 进行排序，然后执行对应的DOM更新 # Vue的数据更新为什么要使用异步呢? 以下面的代码为例，展开说明 ```html ``` 上面的代码本意是想在点击 *h1* 标签的时候更新 *h1* 的内容为 *nextTick*。但是在实际过程中我们会发现，这么简单的逻辑既然实现不了，打印出来以后既然不是我们想象的结果。如图↓ ![img1.gif](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1624259f514a43a4a064a818a70f29d0~tplv-k3u1fbpfcp-watermark.image?) 从上图可以看出，在第一次点击的时候，我们打印出来的还是原来的值 *异步更新* 而不是 *nextTick*。在第二次点击的时候才会变成 *nextTick*。那么如果我们想在第一次点击的时候就更新做一些别的事，就会无法实现。
那么为什么会出现这种情况呢？
这就是因为vue对dom的更新时异步的。当vue观察到data中的数据变化时，就会缓存在一个事件循环中，只有等js的引擎清空了这个事件队列中的缓存以后，在下一个事件的时候才会去渲染。
所以咱们打印的时候是打印不到想要的结果的。那么想要打印到我们想要的结果怎么办呢？其实也很简单，加一个 *nextTick* 就OK。上代码↓
```js ``` 效果如下↓ ![img2.gif](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/869954c6421f442eaef0506032cebd39~tplv-k3u1fbpfcp-watermark.image?) 那么问题来了，Vue的数据更新为什么要使用异步呢？看着没啥用的感觉。接下来再看一个例子 🌰 ```html ``` 一样的当我们点击 *h1* 的时候看一下效果↓ ![img3.gif](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3293b0d4d2394b7a90df3a941e65e46d~tplv-k3u1fbpfcp-watermark.image?) 如图，在我们正常的想法中 this.value 从0依次变到10，视图也会从0依次变到10，结果视图只是从0直接变为10，中间并没有过渡。这就是Vue的数据更新使用异步的原因：
*Vue每一次的更新都会渲染整个组件，如果是同步的话，一旦修改了data属性，便会触发对应的watcher，然后调用对应watcher下的update方法更新视图，这样就会造成渲染太过频繁。而异步更新则Vue会在本轮数据更新后，再去异步更新视图，这样就能大大的优化性能。*

本文到此也就结束了，希望对大家有所帮助。同时看到这里了也希望XDM献上免费小爱心，不胜感激🙏 🙏 🙏

Vue2.x系列的源码文章也就到这篇文章为止，基本常规的vue源码面试题也都差不多了，之后会继续Vue3.x的系列文章，希望大家继续多多支持🙏 🙏 🙏 。

{{ message }}

{{ message }}

{{ value }}