在介紹事件迴圈之前我們先簡單瞭解(回顧)一下瀏覽器相關常識
瀏覽器常識介紹
同步和非同步
- 同步:就是在執行棧中(主執行緒)執行的程式碼
- 非同步:就是在非同步佇列(macroTask、microTask)中的程式碼
簡單理解區別就是:非同步是需要延遲執行的程式碼
執行緒和程式
-
程式:程式是應用程式的執行例項,每一個程式都是由私有的虛擬地址空間、程式碼、資料和其它系統資源所組成;程式在執行過程中能夠申請建立和使用系統資源(如獨立的記憶體區域等),這些資源也會隨著程式的終止而被銷燬
-
執行緒:執行緒則是程式內的一個獨立執行單元,在不同的執行緒之間是可以共享程式資源的,是程式內可以排程的實體。比程式更小的獨立執行的基本單位。執行緒也被稱為輕量級程式。
簡單講,一個程式可由多個執行緒構成,執行緒是程式的組成部分。
js是單執行緒的,但瀏覽器並不是,它是一般是多程式的。
以chrome為例: 一個頁籤就是一個獨立的程式。而javascript的執行是其中的一個執行緒,裡面還包含了很多其他執行緒,如:
- GUI渲染執行緒
- http請求執行緒
- 定時器觸發執行緒
- 事件觸發執行緒
- 圖片等資源的載入執行緒。
事件迴圈
ok,常識性內容回顧完畢,我們開始切入正題。
microTask 和 macroTask
常見的macroTask有:setTimeout、setInterval、setImmediate、i/o操作、ui渲染、MessageChannel、postMessage
常見的microTask有:process.nextTick、Promise、Object.observe(已廢棄)、MutationObserver(html5新特性)
用執行緒的理論理解佇列:
- macroTask由事件觸發執行緒維護
- microTask通常由js引擎自己維護
一個完整的事件迴圈(Event loop)過程解析
- 初始狀態:呼叫棧(主執行緒)、microTask佇列、macroTask佇列,macroTask裡只有一個待執行的script指令碼,比如:入口檔案。(如上圖)
- 將這個macro任務(入口檔案)推入呼叫棧,同步執行程式碼。在這過程中,會呼叫一些介面或者觸發一些事件,可產生新的marcoTask與microTask。它們分別會被推入各自的任務佇列。同時該script指令碼會被從macroTask中移除(主執行緒的執行過程就是一個 tick)(如上圖)
- 呼叫棧程式碼執行完當前的程式碼塊後,需要處理microTask中的任務。將裡面的任務依次推入呼叫棧執行。當然,在執行microTask中的任務時同樣可能產生新的macroTask和microTask,同樣插入對應的佇列中(如上圖)
- 然後繼續執行microTask餘下的任務,直至所有micro任務都執行完成。(如上圖)
- 然後進行渲染操作,更新介面 (如上圖)
以上就是一次完整的事件迴圈。
然後將macroTask中優先順序最高的任務推入主執行緒,繼續執行上述過程
注意:單次事件迴圈中,macroTask的任務僅處理優先順序最高的那一個,而microTask要執行完所有。
渲染時機
經過上面的學習我們把非同步拿到的資料放在macroTask中還是microTask中呢?
比如先放在macroTask中:
setTimeout(task, 0)
複製程式碼
那麼按照Event loop,task會被推入macroTask中,本次呼叫棧內容執行完,會執行microTask中的內容,然後進行render。而本次事件迴圈render內容是不包含task的,因為他還在macroTask中尚未執行,需要等到下次事件迴圈才能進行渲染
如果放在microTask中:
Promise.resolve().then(task)
複製程式碼
那麼按照Event loop,task會被推入microTask中,本次呼叫棧內容執行完,會執行microTask中的task內容,然後進行render,也就是在本次的事件迴圈中就可以進行渲染。
總結:我們在非同步任務中修改dom是儘量在microTask完成。
Vue next-tick
vue nextTick是幹什麼用的?
我們先來看一段程式碼
getData().then(res => {
this.xxx = res.data.xxx
this.$nextTick(() => {
// 這裡我們可以獲取更新後的 DOM
})
})
複製程式碼
這段程式碼很簡單,但實際上用到了兩次nextTick。
this.$nextTick()是一次顯示呼叫,沒啥說的。主要是這行
this.xxx = res.data.xxx
複製程式碼
這一行是常見的vue引數設定,然後更新dom,那麼它怎麼就和nextTick產生聯絡了呢?
這就會涉及vue的資料響應原理
當設定新的引數時,會觸發對應屬性的set攔截,然後觸發dep的notify方法,進而呼叫watcher的update方法,再由update呼叫queueWathcer,最終呼叫nextTick方法
vue 資料更新為什麼要採用nextTick非同步佇列更新呢?
先看個例子
data () {
return {
count: 0
}
},
mounted () {
for (let i = 0; i < 1000; i++) {
this.count++
}
}
複製程式碼
如果不用非同步佇列,每一次set劫持都做render的話,那麼render會執行1000次,會非常浪費效能。
如果把這些更新通通放在非同步佇列裡,意味著,會觸發1000次watcher的queueWathcer方法。 但有一點注意,queueWathcer裡面通過id對watcher做了去重處理,雖然被呼叫了1000次,但有效呼叫只有一次。同時也保證,在一個ticket中,同一個引數即使被修改多次,我們在執行wather.update時候仍然保證渲染的是最新的資料。
所以使用nextTick進行渲染,也是vue的一大優化
vue nextTick實現
Vue2.5以後,採用單獨的next-tick.js來維護它。
import { noop } from 'shared/util'
import { handleError } from './error'
import { isIOS, isNative } from './env'
// 所有的callback快取在陣列中
const callbacks = []
// 狀態
let pending = false
// 呼叫陣列中所有的callback,並清空陣列
function flushCallbacks () {
// 重置標誌位
pending = false
const copies = callbacks.slice(0)
callbacks.length = 0
// 呼叫每一個callback
for (let i = 0; i < copies.length; i++) {
copies[i]()
}
}
// Here we have async deferring wrappers using both microtasks and (macro) tasks.
// In < 2.4 we used microtasks everywhere, but there are some scenarios where
// microtasks have too high a priority and fire in between supposedly
// sequential events (e.g. #4521, #6690) or even between bubbling of the same
// event (#6566). However, using (macro) tasks everywhere also has subtle problems
// when state is changed right before repaint (e.g. #6813, out-in transitions).
// Here we use microtask by default, but expose a way to force (macro) task when
// needed (e.g. in event handlers attached by v-on).
// 微任務function
let microTimerFunc
// 巨集任務fuction
let macroTimerFunc
// 是否使用巨集任務標誌位
let useMacroTask = false
// Determine (macro) task defer implementation.
// Technically setImmediate should be the ideal choice, but it’s only available
// in IE. The only polyfill that consistently queues the callback after all DOM
// events triggered in the same loop is by using MessageChannel.
/* istanbul ignore if */
// 優先檢查是否支援setImmediate,這是一個高版本 IE 和 Edge 才支援的特性(和setTimeout差不多,但優先順序最高)
if (typeof setImmediate !== 'undefined' && isNative(setImmediate)) {
macroTimerFunc = () => {
setImmediate(flushCallbacks)
}
// 檢查MessageChannel相容性(優先順序次高)
} else if (typeof MessageChannel !== 'undefined' && (
isNative(MessageChannel) ||
// PhantomJS
MessageChannel.toString() === '[object MessageChannelConstructor]'
)) {
const channel = new MessageChannel()
const port = channel.port2
channel.port1.onmessage = flushCallbacks
macroTimerFunc = () => {
port.postMessage(1)
}
// 相容性最好(優先順序最低)
} else {
/* istanbul ignore next */
macroTimerFunc = () => {
setTimeout(flushCallbacks, 0)
}
}
// Determine microtask defer implementation.
/* istanbul ignore next, $flow-disable-line */
// 微任務用promise來處理
if (typeof Promise !== 'undefined' && isNative(Promise)) {
const p = Promise.resolve()
microTimerFunc = () => {
p.then(flushCallbacks)
// in problematic UIWebViews, Promise.then doesn’t completely break, but
// it can get stuck in a weird state where callbacks are pushed into the
// microtask queue but the queue isn’t being flushed, until the browser
// needs to do some other work, e.g. handle a timer. Therefore we can
// "force" the microtask queue to be flushed by adding an empty timer.
if (isIOS) setTimeout(noop)
}
// promise不支援直接用巨集任務
} else {
// fallback to macro
microTimerFunc = macroTimerFunc
}
/**
* Wrap a function so that if any code inside triggers state change,
* the changes are queued using a (macro) task instead of a microtask.
*/
// 強制走巨集任務,比如dom互動事件,v-on (這種情況就需要強制走macroTask)
export function withMacroTask (fn: Function): Function {
return fn._withTask || (fn._withTask = function () {
useMacroTask = true
const res = fn.apply(null, arguments)
useMacroTask = false
return res
})
}
export function nextTick (cb?: Function, ctx?: Object) {
let _resolve
// 快取傳入的callback
callbacks.push(() => {
if (cb) {
try {
cb.call(ctx)
} catch (e) {
handleError(e, ctx, 'nextTick')
}
} else if (_resolve) {
_resolve(ctx)
}
})
// 如果pending為false,則開始執行
if (!pending) {
// 變更標誌位
pending = true
if (useMacroTask) {
macroTimerFunc()
} else {
microTimerFunc()
}
}
// $flow-disable-line
// 當為傳入callback,提供一個promise化的呼叫
if (!cb && typeof Promise !== 'undefined') {
return new Promise(resolve => {
_resolve = resolve
})
}
}
複製程式碼
這段程式碼主要定義了Vue.nextTick的實現。 核心邏輯:
- 定義當前環境支援的microTimerFunc和macroTimerFunc(呼叫時會執行flushCallbacks方法)
- 外部呼叫nextTick時,會快取傳入的callback
- pending設定為false,變更標誌位,執行microTimerFunc或macroTimerFunc(也就是執行flushCallbacks方法)
- 執行完flushCallbacks後,pending重置為false,清空陣列
所以vue的資料更新是一個非同步的過程。
思考問題
還是之前的例子
getData().then(res => {
this.xxx = res.data.xxx
this.$nextTick(() => {
// 這裡我們可以獲取更新後的 DOM
})
})
複製程式碼
這裡提一個疑問~
前面不是說UI Render是在microTask都執行完之後才進行麼。
而通過對vue的$nextTick分析,它實際是用promise包裝的,屬於microTask。
在getData.then中,執行了this.xxx= res.data,它實際也是通過wather呼叫$nextTick
隨後,又執行了一個$nextTick
按理說目前還處在同一個事件迴圈,而且還沒有進行UI Render,怎麼在$nextTick就能拿到剛渲染的dom呢?
UI render理解
我們先看一個例子
<template>
<div>
<div class="title" ref="test">{{title}}</div>
</div>
</template>
<script lang="ts">
import { Component, Vue } from 'vue-property-decorator'
@Component
export default class Index extends Vue {
// 和vue data()是一樣的,我們這裡是ts寫法
title: string = 'nothing'
mounted () {
// 模擬介面獲取資料
setTimeout(() => {
this.title = '測試標題'
this.$nextTick(() => {
console.log('debug:', this.title, this.$refs.test['innerHTML'])
alert('渲染完了麼?')
})
}, 0)
}
</script>
<style lang="scss">
.title{
font-size: pxToRem(158px);
text-align: center;
}
</style>
複製程式碼
看看瀏覽器的渲染情況
因為alert能夠阻塞渲染,所以這裡用到它。
在alert之前我們console了最新設定dom的內容,從控制檯已經拿到了最新設定的title。但是瀏覽器還沒有進行渲染。再點選“確定”後,瀏覽器才進行渲染。
我之前一直以為獲取新的dom節點必須等UI Render完成之後才能獲取到,然而並不是這樣的。
結論:
在主執行緒及microTask執行過程中,每一次dom或css更新,瀏覽器都會進行計算,而計算的結果並不會被立刻渲染,而是在當所有的microTask佇列中任務都執行完畢後,統一進行渲染(這也是瀏覽器為了提高渲染效能和體驗做的優化)所以,這個時候通過js訪問更新後的dom節點或者css是可以拿到的,因為瀏覽器已經完成計算,僅僅是它們還沒被渲染而已。
這也就完美解決了我之前的疑問。
OK,以上就是對瀏覽器事件迴圈全部介紹,歡迎大家學習交流