摘要:而和的延迟明显是小于的。因为的事件机制是通过事件队列来调度执行,会等主进程执行空闲后进行调度,所以先回去等待所有的进程执行完成之后再去一次更新。因为首先触发了,导致触发了的,从而将更新操作进入的事件队列。这种情况会导致顺序成为了。
背景
我们先来看一段Vue的执行代码:
export default { data () { return { msg: 0 } }, mounted () { this.msg = 1 this.msg = 2 this.msg = 3 }, watch: { msg () { console.log(this.msg) } } }
这段脚本执行我们猜测1000m后会依次打印:1、2、3。但是实际效果中,只会输出一次:3。为什么会出现这样的情况?我们来一探究竟。
queueWatcher我们定义watch监听msg,实际上会被Vue这样调用vm.$watch(keyOrFn, handler, options)。$watch是我们初始化的时候,为vm绑定的一个函数,用于创建Watcher对象。那么我们看看Watcher中是如何处理handler的:
this.deep = this.user = this.lazy = this.sync = false ... update () { if (this.lazy) { this.dirty = true } else if (this.sync) { this.run() } else { queueWatcher(this) } } ...
初始设定this.deep = this.user = this.lazy = this.sync = false,也就是当触发update更新的时候,会去执行queueWatcher方法:
const queue: Array= [] let has: { [key: number]: ?true } = {} let waiting = false let flushing = false ... export function queueWatcher (watcher: Watcher) { const id = watcher.id if (has[id] == null) { has[id] = true if (!flushing) { queue.push(watcher) } else { // if already flushing, splice the watcher based on its id // if already past its id, it will be run next immediately. let i = queue.length - 1 while (i > index && queue[i].id > watcher.id) { i-- } queue.splice(i + 1, 0, watcher) } // queue the flush if (!waiting) { waiting = true nextTick(flushSchedulerQueue) } } }
这里面的nextTick(flushSchedulerQueue)中的flushSchedulerQueue函数其实就是watcher的视图更新:
function flushSchedulerQueue () { flushing = true let watcher, id ... for (index = 0; index < queue.length; index++) { watcher = queue[index] id = watcher.id has[id] = null watcher.run() ... } }
另外,关于waiting变量,这是很重要的一个标志位,它保证flushSchedulerQueue回调只允许被置入callbacks一次。
接下来我们来看看nextTick函数,在说nexTick之前,需要你对Event Loop、microTask、macroTask有一定的了解,Vue nextTick 也是主要用到了这些基础原理。如果你还不了解,可以参考我的这篇文章Event Loop 简介
好了,下面我们来看一下他的实现:
export const nextTick = (function () { const callbacks = [] let pending = false let timerFunc function nextTickHandler () { pending = false const copies = callbacks.slice(0) callbacks.length = 0 for (let i = 0; i < copies.length; i++) { copies[i]() } } // An asynchronous deferring mechanism. // In pre 2.4, we used to use microtasks (Promise/MutationObserver) // but microtasks actually has too high a priority and fires in between // supposedly sequential events (e.g. #4521, #6690) or even between // bubbling of the same event (#6566). Technically setImmediate should be // the ideal choice, but it"s not available everywhere; and the only polyfill // that consistently queues the callback after all DOM events triggered in the // same loop is by using MessageChannel. /* istanbul ignore if */ if (typeof setImmediate !== "undefined" && isNative(setImmediate)) { timerFunc = () => { setImmediate(nextTickHandler) } } else if (typeof MessageChannel !== "undefined" && ( isNative(MessageChannel) || // PhantomJS MessageChannel.toString() === "[object MessageChannelConstructor]" )) { const channel = new MessageChannel() const port = channel.port2 channel.port1.onmessage = nextTickHandler timerFunc = () => { port.postMessage(1) } } else /* istanbul ignore next */ if (typeof Promise !== "undefined" && isNative(Promise)) { // use microtask in non-DOM environments, e.g. Weex const p = Promise.resolve() timerFunc = () => { p.then(nextTickHandler) } } else { // fallback to setTimeout timerFunc = () => { setTimeout(nextTickHandler, 0) } } return function queueNextTick (cb?: Function, ctx?: Object) { let _resolve callbacks.push(() => { if (cb) { try { cb.call(ctx) } catch (e) { handleError(e, ctx, "nextTick") } } else if (_resolve) { _resolve(ctx) } }) if (!pending) { pending = true timerFunc() } // $flow-disable-line if (!cb && typeof Promise !== "undefined") { return new Promise((resolve, reject) => { _resolve = resolve }) } } })()
首先Vue通过callback数组来模拟事件队列,事件队里的事件,通过nextTickHandler方法来执行调用,而何事进行执行,是由timerFunc来决定的。我们来看一下timeFunc的定义:
if (typeof setImmediate !== "undefined" && isNative(setImmediate)) { timerFunc = () => { setImmediate(nextTickHandler) } } else if (typeof MessageChannel !== "undefined" && ( isNative(MessageChannel) || // PhantomJS MessageChannel.toString() === "[object MessageChannelConstructor]" )) { const channel = new MessageChannel() const port = channel.port2 channel.port1.onmessage = nextTickHandler timerFunc = () => { port.postMessage(1) } } else /* istanbul ignore next */ if (typeof Promise !== "undefined" && isNative(Promise)) { // use microtask in non-DOM environments, e.g. Weex const p = Promise.resolve() timerFunc = () => { p.then(nextTickHandler) } } else { // fallback to setTimeout timerFunc = () => { setTimeout(nextTickHandler, 0) } }
可以看出timerFunc的定义优先顺序macroTask --> microTask,在没有Dom的环境中,使用microTask,比如weex
setImmediate、MessageChannel VS setTimeout我们是优先定义setImmediate、MessageChannel为什么要优先用他们创建macroTask而不是setTimeout?
HTML5中规定setTimeout的最小时间延迟是4ms,也就是说理想环境下异步回调最快也是4ms才能触发。Vue使用这么多函数来模拟异步任务,其目的只有一个,就是让回调异步且尽早调用。而MessageChannel 和 setImmediate 的延迟明显是小于setTimeout的。
有了这些基础,我们再看一遍上面提到的问题。因为Vue的事件机制是通过事件队列来调度执行,会等主进程执行空闲后进行调度,所以先回去等待所有的进程执行完成之后再去一次更新。这样的性能优势很明显,比如:
现在有这样的一种情况,mounted的时候test的值会被++循环执行1000次。 每次++时,都会根据响应式触发setter->Dep->Watcher->update->run。 如果这时候没有异步更新视图,那么每次++都会直接操作DOM更新视图,这是非常消耗性能的。 所以Vue实现了一个queue队列,在下一个Tick(或者是当前Tick的微任务阶段)的时候会统一执行queue中Watcher的run。同时,拥有相同id的Watcher不会被重复加入到该queue中去,所以不会执行1000次Watcher的run。最终更新视图只会直接将test对应的DOM的0变成1000。 保证更新视图操作DOM的动作是在当前栈执行完以后下一个Tick(或者是当前Tick的微任务阶段)的时候调用,大大优化了性能。
有趣的问题var vm = new Vue({ el: "#example", data: { msg: "begin", }, mounted () { this.msg = "end" console.log("1") setTimeout(() => { // macroTask console.log("3") }, 0) Promise.resolve().then(function () { //microTask console.log("promise!") }) this.$nextTick(function () { console.log("2") }) } })
这个的执行顺序想必大家都知道先后打印:1、promise、2、3。
因为首先触发了this.msg = "end",导致触发了watcher的update,从而将更新操作callback push进入vue的事件队列。
this.$nextTick也为事件队列push进入了新的一个callback函数,他们都是通过setImmediate --> MessageChannel --> Promise --> setTimeout来定义timeFunc。而 Promise.resolve().then则是microTask,所以会先去打印promise。
在支持MessageChannel和setImmediate的情况下,他们的执行顺序是优先于setTimeout的(在IE11/Edge中,setImmediate延迟可以在1ms以内,而setTimeout有最低4ms的延迟,所以setImmediate比setTimeout(0)更早执行回调函数。其次因为事件队列里,优先收入callback数组)所以会打印2,接着打印3
但是在不支持MessageChannel和setImmediate的情况下,又会通过Promise定义timeFunc,也是老版本Vue 2.4 之前的版本会优先执行promise。这种情况会导致顺序成为了:1、2、promise、3。因为this.msg必定先会触发dom更新函数,dom更新函数会先被callback收纳进入异步时间队列,其次才定义Promise.resolve().then(function () { console.log("promise!")})这样的microTask,接着定义$nextTick又会被callback收纳。我们知道队列满足先进先出的原则,所以优先去执行callback收纳的对象。
后记如果你对Vue源码感兴趣,可以来这里:
更多好玩的Vue约定源码解释
参考文章:
Vue.js 升级踩坑小记
【Vue源码】Vue中DOM的异步更新策略以及nextTick机制
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/94679.html
摘要:在查询了各种资料后,总结了一下其原理和用途,如有错误,请不吝赐教。截取关键部分如下具体来说,异步执行的运行机制如下。知乎上的例子改变数据想要立即使用更新后的。需要注意的是,在和阶段,如果需要操作渲染后的试图,也要使用方法。 对于 Vue.nextTick 方法,自己有些疑惑。在查询了各种资料后,总结了一下其原理和用途,如有错误,请不吝赐教。 概览 官方文档说明: 用法: 在下次 DO...
摘要:而和的延迟明显是小于的。因为的事件机制是通过事件队列来调度执行,会等主进程执行空闲后进行调度,所以先回去等待所有的进程执行完成之后再去一次更新。因为首先触发了,导致触发了的,从而将更新操作进入的事件队列。这种情况会导致顺序成为了。 背景 我们先来看一段Vue的执行代码: export default { data () { return { msg: 0 ...
摘要:复制代码然后在这个文件里还有一个函数叫用来把保存的回调函数给全执行并清空。其实调用的不仅是开发者,更新时,也用到了。但是问题又来了,根据浏览器的渲染机制,渲染线程是在微任务执行完成之后运行的。 当在代码中更新了数据,并希望等到对应的Dom更新之后,再执行一些逻辑。这时,我们就会用到$nextTickfuncion call...
摘要:本篇文章主要是对中的异步更新策略和机制的解析,需要读者有一定的使用经验并且熟悉掌握事件循环模型。这个结果足以说明中的更新并非同步。二是把回调函数放入一个队列,等待适当的时机执行。通过的主动来触发的事件,进而把回调函数作为参与事件循环。 本篇文章主要是对Vue中的DOM异步更新策略和nextTick机制的解析,需要读者有一定的Vue使用经验并且熟悉掌握JavaScript事件循环模型。 ...
阅读 3169·2023-04-26 01:39
阅读 3328·2023-04-25 18:09
阅读 1589·2021-10-08 10:05
阅读 3205·2021-09-22 15:45
阅读 2714·2019-08-30 15:55
阅读 2358·2019-08-30 15:54
阅读 3129·2019-08-30 15:53
阅读 1306·2019-08-29 12:32