任務和微不是所有都一個待遇

前面我們已經(jīng)介紹過了，頁面中的大部分任務都是在主線程上執(zhí)行的，這些任務包括渲染（如解析DOM、計算布局、繪制用戶交互（如鼠標點擊、滾動頁面、放大縮小等JavaScript執(zhí)行網(wǎng)絡請求完成、文件讀寫完成為了協(xié)調(diào)這些任務有條不紊地在主線程上執(zhí)行，頁面進程引入了消息隊列和循環(huán)機制，渲染進程內(nèi)部會多個消息隊列，比如延遲執(zhí)行隊列和普通的消息隊列。然后主線程采用一個for循環(huán)，不斷地從這些任務隊列中取出任務并執(zhí)行任務。我們把這些消息隊列中的任務稱為宏任務。消息隊列中的任務是通過循環(huán)系統(tǒng)來執(zhí)行的，這里我們在WHATWG規(guī)范中由于規(guī)范需要支持語義上的完備性，所以通常寫得都會比較啰嗦，這里我就大致總結WHATWG規(guī)范定義的大致流程先從多個消息隊列中選出一個最老的任務，這個任務稱為然后循環(huán)系統(tǒng)記錄任務開始執(zhí)行的時間，并把這個oldestTask置為當前正在執(zhí)行的任當任務執(zhí)行完成之后，刪除當前正在執(zhí)行的任務，并從對應的消息隊列中刪除掉這最后統(tǒng)計執(zhí)行完成的時長等信前面我們，頁面的渲染、各種IO的完成、執(zhí)行JavaScript的、用JavaScript碼不能準確掌控任務要添加到隊列中的位置，控制不了任務在消息隊列中的代<!DOCTYPE<div <scriptfunction function 20在這段代碼中，我的目的是想通過seTimeout來設置兩個回調(diào)任務，并讓它們按照前后順序來執(zhí)行，中間也不要再插入其他的任務，因為如果這兩個任務的中間插入了其他的任務，就很有可能會影響到第二個定時器的執(zhí)行時間了。但實際情況是我們不能控制的，比如在你調(diào)用setTimeout來設置回調(diào)任務的間隙，消息隊列中就有可能入很多系統(tǒng)級的任務。你可以打開Performance工具，來記錄下這段任Performance記錄setTimeout函數(shù)觸發(fā)的回調(diào)函數(shù)都是宏任務，如圖中，左右兩個黃色塊就是觸發(fā)的兩個定時器任現(xiàn)在你可以重點觀察上圖中間淺紅域，這里有很多一段一段的任務，這些是被渲染引擎插在兩個定時器任務中間的任務。試想一下，如果中間入的任務執(zhí)行時間過久的話，那么就會影響到后面任務的執(zhí)行了。所以說宏任務的時間粒度比較大，執(zhí)行的時間間隔是不能精確控制的，對一些高實時性的需求就不太符合了，比如后面要介紹的DOM變化的需求。在理解了宏任務之后，下面我們就可以來看看什么是微任務了。在上一篇文章中，我們介紹過異步回調(diào)的概念，其主要有兩種方式。務的時候執(zhí)行回調(diào)函數(shù)。這種比較好理解，我們前面介紹的setTimeout和XMLHttpRequest的回調(diào)函數(shù)都是通過這種方式來實現(xiàn)的。那這里說的微任務到底是什么不過要搞清楚微任務系統(tǒng)是怎么運轉(zhuǎn)起來的，就得站在V8引擎的層面來分析我們知道當JaaSipt執(zhí)行一段的時候，8會為其創(chuàng)建一個全局執(zhí)行上下文，在創(chuàng)建全局執(zhí)行上下文的同時，V8引擎也會在內(nèi)部創(chuàng)建一個微任務隊列。顧名思義，這個微任務隊列就是用來存放微任務的，因為在當前宏任務執(zhí)行的過程中，有時候會產(chǎn)生多個微任務，這時候就需要使用這個微任務隊列來保存這些微任務了。不過這個微任務隊列是給V8引擎的，所以你是無法通過Jaacrit直接的。我們先來看看微任務是怎么產(chǎn)生的？在現(xiàn)代瀏覽器里面，產(chǎn)生微任務有兩種方第式是使用MutationObserver某個DOM節(jié)點，然后再通過JavaScript來修改這個節(jié)點，或者為這個節(jié)點添加、刪除部分子節(jié)點，當DOM節(jié)點發(fā)生變化時，就會產(chǎn)生DOM變化記錄的微任務。第二種方式是使用Promise，當調(diào)用Promise.resolve()或者Promise.reject()的時候，也通過DOM節(jié)點變化產(chǎn)生的微任務或者使用Promise產(chǎn)生的微任務都會被JavaScript引擎好了，現(xiàn)在微任務隊列中有了微任務了，那接下來就要看看微任務隊列是何時被執(zhí)行通常情況下，在當前宏任務中的JavaScript快執(zhí)行完成時，也就在JavaScript引擎準備退出全局執(zhí)行上下文并清空調(diào)用棧的時候，JavaScript引擎會檢查全局執(zhí)行上下文中的微任務隊列，然后按照順序執(zhí)行隊列中的微任務。WHATWG把執(zhí)行微任務的時間點稱為檢查點。當然除了在退出全局執(zhí)行上下文式這個檢查點之外，還有其他的檢查點，不過不是太重要，V8引擎一直循環(huán)執(zhí)行微任務隊列中的任務，直到隊列為空才算執(zhí)行結束。也就是說在執(zhí)行微任務過程中產(chǎn)生的新的微任務并不會推下個宏任務中執(zhí)行，而是在當前的宏任務中繼微任務添加和執(zhí)行流程示意該示意圖是在執(zhí)行一個ParseHTML的宏任務，在執(zhí)行過程中，遇到了JavaScript，那么就暫停解析流程，進入到JavaScript的執(zhí)行環(huán)境。從圖中可以看到，全局上下文中包在JavaScript的后續(xù)執(zhí)行過程中，分別通過Promise和removeChild創(chuàng)建了兩個微任務，并被添加到微任務列表中。接著JavaScript執(zhí)行結束，準備退出全局執(zhí)行上下文，這時候就到了檢查點了，JavaScript引擎會檢查微任務列表，發(fā)現(xiàn)微任務列表中有微任以上就是微任務的工作流程，從上面分析我們可以得出如下幾個結論微任務和宏任務是綁定的，每個宏任務在執(zhí)行時，會創(chuàng)建自己的微任務隊微任務的執(zhí)行時長會影響到當前宏任務的時長。比如一個宏任務在執(zhí)行過程中，產(chǎn)生100個微任務，執(zhí)行每個微任務的時間是10毫秒，那么執(zhí)行這100個微任務的時間1000秒，也可以說這100微任務讓宏任務的執(zhí)行時間延長了1000秒。所以MutationObserver中的。MutationObserver是用來DOM變化的一套方法，而監(jiān)聽DOM變化一直是前端工程師一項非常的需求。比如許多Web應用都利用HTML與JavaScript構建其自定義控件，與一些內(nèi)置控件不改、響應和用戶交互。因此，Web應用需要監(jiān)視DOM變化并及時地做出響應。雖然DOM的需求是如此重要，不過早期頁面并沒有提供對的支持，所以那時要觀察DOM是否變化，唯一能做的就是輪詢檢測，比如使用setTimeout或者setInterval來定時檢測DOM是否有改變。這種方式簡單，但是會遇到兩個問題：如果時間間隔設置過長，DOM變化響應不夠及時；反過來如果時間間隔設置過短，又會浪費很多無用的工作量去檢查DOM，會讓頁面變得低效。直到2000的時候引入了MutationEvent，MutationEvent用了觀察者的設計模式，當DOM有變動時就會立刻觸發(fā)相應的，這種方式屬于同步回調(diào)。采用MutationEvent解決了實時性的問題，因為DOM一旦發(fā)生變化，就會立即調(diào)用JavaScript接口。但也正是這種實時性造成了嚴重的性能問題，因為每次DOM變動，渲染引擎都會去調(diào)用JavaScript，這樣會產(chǎn)生較大的性能開銷。比如利用JavaScript動態(tài)創(chuàng)建或動態(tài)修改50個節(jié)點內(nèi)容，就會觸發(fā)50次回調(diào)，而且每個回調(diào)函數(shù)都需要一定的執(zhí)行時間，這里我們假設每次回調(diào)的執(zhí)行時間是4毫秒，那么50次回調(diào)的執(zhí)行時間就是200毫秒，若此時瀏覽器正在執(zhí)行一個動畫效果，由于MutationEvent觸發(fā)回調(diào)，就會導也正是因為使用MutationEvent會導致頁面性能問題，所以MutationEvent被使用，并逐步從Web標準中刪除了。為了解決了MutationEvent由于同步調(diào)用JavaScript而造成的性能問題，從DOM4開始，推薦使用MutationObserver代替MutationEvent。MutationObserverAPI可以用來監(jiān)視DOM的變化，包括屬性的變化、節(jié)點的增減、內(nèi)容的變化等。那么相比較MutationEvent，MutationObserver到底做了哪些改進首先，MutationObserver將響應函數(shù)改成異步調(diào)用，可以不用在每次DOM變化都觸發(fā)異步調(diào)用，而是等多次DOM變化后，一次觸發(fā)異步調(diào)用，并且還會使用一個數(shù)據(jù)結構來記錄這期間所有的DOM變化。這樣即使頻繁地DOM，也不會對性能造成太大的影我們通過異步調(diào)用和減少觸發(fā)次數(shù)來緩解了性能問題，那么如何保持消息通知的及時性呢？如果采用setTimeout創(chuàng)建宏任務來觸發(fā)回調(diào)的話，那么實時性就會大打折扣，因為上面我們分析過，在兩個任務之間，可能會被渲染進程插入其他的，從而影響到響應的實時性。這時候，微任務就可以上場了，在每次DOM節(jié)點發(fā)生變化的時候，渲染引擎將變化記錄封裝成微任務，并將微任務添加進當前的微任務隊列中。這樣當執(zhí)行到檢查點的時候，V8綜上所述MutationObserver用了“任務”的策略。通過微任務解決了實時性的問題好了，今天就介紹到這里，下面我來總結下今天的內(nèi)接下來我們詳細分析了瀏覽器是如何實現(xiàn)微任務的，包括微任務隊列、檢查點等概最后我們介紹了DOM變化技術方案的演化史，從輪詢到MutationEvent再到使用的MutationObserver。MutationObserver方案的就是采用了微任務機制，有下篇文章我會從Promise產(chǎn)生的動機角度來分析Promise，這需要一定的Promise基礎，所以今天留給你的作業(yè)是搞清楚Promise工作原理，弄清楚下面這段代碼的輸出結代1functionexecutor(resolve,reject)2letrand=345if(rand>6789}p0=newp1=p0.then((value)=>console.log("succeed-returnnewp3=p1.then((value)=>console.log("succeed-returnnew23varp4=p3.then((value)=>returnnew29p4.catch((error)=> 3132覺得這篇文章對你有幫助的話，也歡迎把它給的朋友。 歸科技所有 不得售賣。頁面已增加防盜追蹤，將依 上一 17|WebAPI：XMLHttpRequest是怎么實現(xiàn)的言精選留言言1 創(chuàng)建promise賦值，打印1rand2，3，如果rand0.5，promise被resolve，打印success，并返回新的promse賦值展1執(zhí)行過程如下：（描述起來有點亂，一個流程圖更好展現(xiàn)如果第10行中：rand進入失敗方法