這篇文章帶給大家的內容是關於瀏覽器事件循環的深入了解(程式碼範例),有一定的參考價值,有需要的朋友可以參考一下,希望對你有幫助。
瀏覽器的事件循環,前端再熟悉不過了,每天都會接觸的東西。但我以前一直都是死記硬背:事件任務隊列分為macrotask和microtask,瀏覽器先從macrotask取出一個任務執行,再執行microtask內的所有任務,接著又去macrotask取出一個任務執行.. .,這樣一直循環下去。但對於下面的程式碼,我一直在懵逼,setTimeout屬於macrotask,按照上面的規則,setTimeout應該先被取出來執行啊,但是我卻被執行結果打臉了。
<script> setTimeout(() => { console.log(1) }, 0) new Promise((resolve) => { console.log(2) resolve() }).then(() => { console.log(3) }) // 我曾经的预期是:2 1 3 // 实际输出:2 3 1 </script>
經過再仔細看別人對任務佇列的介紹,才知道,同步執行的js程式碼其實就算一個macrotask(準確地說是每一個script標籤內的程式碼都是一個macrotask),所以上面的規則中說的先取出一個macrotask執行 是沒有問題的。
網路上很多文章都是像上面這樣解釋的,我也一直認為這是HTML對事件循環的規範,我們記得就是。直到最近看了李銀城大佬的文章(見文末的參考連結),我才恍然大悟,之前看的文章都沒有明確地從瀏覽器的多線程模型這個角度分析,所以讓我們覺得瀏覽器的事件循環是基於上述的約定,但其實這是瀏覽器的多執行緒模型所導致的結果。
macrotask本質上是瀏覽器多個執行緒之間通訊的一個訊息佇列
在chrome裡,每個頁面都對應一個進程,該進程又有多個線程,例如js線程、渲染線程、io線程、網路線程、計時器線程等,這些線程之間的通信,則是透過向對方的任務佇列中新增一個任務(PostTask)來實現的。
瀏覽器的各種線程都是常駐線程,它們運行在一個for死循環裡面,每個線程都有屬於自己的若干任務隊列,線程自己或者其它線程都可能通過PostTask向這些任務佇列新增任務,這些執行緒會不斷地從自己的任務佇列中取出任務執行,或是處於睡眠狀態直到設定的時間或是有人PostTask的時候把它們喚醒。
可以簡單地理解為,瀏覽器的各個執行緒都在不停地從自己的任務佇列中取出任務,執行,再取出任務,再執行,這樣無限地循環下去。
以下面的程式碼為例:
<script> console.log(1) setTimeout(() => { console.log(2) }, 1000) console.log(3) </script>
首先,script標籤中的程式碼作為一個任務放入js執行緒的任務佇列,js執行緒被喚醒,然後取出該任務執行
先執行console.log(1),然後執行setTimeout,向定時器執行緒新增一個任務,接著執行console.log(3),此時js執行緒的任務佇列為空,js執行緒進入休眠
大約1000ms後,定時器執行緒向js執行緒的任務佇列加入定時任務(定時器的回呼),js執行緒又被喚醒,執行定時回呼函數,最後執行console.log(2)。
可以看到,所謂的macrotask並不是瀏覽器定義了哪些任務是macrotask,瀏覽器各個執行緒只是忠實地循環自己的任務佇列,不停地執行其中的任務而已。
比起macrotask是瀏覽器的多執行緒模型造成的“假象”,microtask是確實存在的一個佇列,microtask是屬於目前執行緒的,而不是其他執行緒PostTask過來的任務,只是延遲執行了而已(準確地說是放到了目前執行的同步程式碼之後執行),例如Promise.then、MutationObserver都屬於這種情況。
以下面的程式碼為例:
<script> new Promise((resolve) => { resolve() console.log(1) setTimeout(() => { console.log(2) },0) }).then(() => { console.log(3) }) // 输出:1 3 2 </script>
首先,script標籤中的程式碼作為一個任務放入js執行緒的任務佇列,js執行緒被喚醒,然後取出該任務執行
然後執行new Promise以及Promise中的resolve,resolve後,promise的then的回呼函數會作為需要延遲執行的任務,放到目前執行的所有同步程式碼之後
接著執行setTimeout,在定時器執行緒上新增一個任務
此時同步程式碼執行完畢,接著執行被延遲執行的任務,也就是promise的then的回呼函數,即執行console.log(3)
最後,js執行緒的任務隊列為空,js執行緒進入休眠,大約1000ms後,定時器執行緒為js執行緒的任務佇列加入定時任務(定時器的回呼),js執行緒又被喚醒,執行定時回呼函數,即console.log(2)。
通过上面的分析,可以看到,文章开头提到的规则:浏览器先从macrotask取出一个任务执行,再执行microtask内的所有任务,接着又去macrotask取出一个任务执行...,并没有说错,但这只是浏览器执行机制造成的现象,而不是说浏览器按照这样的规则去执行的代码。
这篇文章中的所有干货都来自李银成大佬的文章,我只是按照自己的理解,做了简化描述,方便大家理解,也加深自己的印象。
最后,看了这篇文章,大家能够基于浏览器的运行机制,分析出下面代码的执行结果了吗(ps:不要用死记硬背的规则去分析哟)
console.log('start') const interval = setInterval(() => { console.log('setInterval') }, 0) setTimeout(() => { console.log('setTimeout 1') Promise.resolve() .then(() => { console.log('promise 3') }) .then(() => { console.log('promise 4') }) .then(() => { setTimeout(() => { console.log('setTimeout 2') Promise.resolve() .then(() => { console.log('promise 5') }) .then(() => { console.log('promise 6') }) .then(() => { clearInterval(interval) }) }, 0) }) }, 0) Promise.resolve() .then(() => { console.log('promise 1') }) .then(() => { console.log('promise 2') }) // 执行结果 /* start promise 1 promise 2 setInterval setTimeout 1 promise 3 promise 4 setInterval setTimeout 2 promise 5 promise 6 */
以上是瀏覽器事件循環的深入了解(程式碼範例)的詳細內容。更多資訊請關注PHP中文網其他相關文章!