從瀏覽器多進程到JS單線程，JS運行機制最全面的一次梳理

m_ytes18do 6年前發布 | 36K 次閱讀多進程 JavaScript開發 JavaScript

前言

見解有限，如有描述不當之處，請幫忙及時指出，如有錯誤，會及時修正。

———-超長文+多圖預警，需要花費不少時間。———-

如果看完本文后，還對進程線程傻傻分不清，不清楚瀏覽器多進程、瀏覽器內核多線程、JS單線程、JS運行機制的區別。那么請回復我，一定是我寫的還不夠清晰，我來改。。。

———-正文開始———-

最近發現有不少介紹JS單線程運行機制的文章，但是發現很多都僅僅是介紹某一部分的知識，而且各個地方的說法還不統一，容易造成困惑。因此準備梳理這塊知識點，結合已有的認知，基于網上的大量參考資料，從瀏覽器多進程到JS單線程，將JS引擎的運行機制系統的梳理一遍。

展現形式：由于是屬于系統梳理型，就沒有由淺入深了，而是從頭到尾的梳理知識體系，重點是將關鍵節點的知識點串聯起來，而不是僅僅剖析某一部分知識。

內容是：從瀏覽器進程，再到瀏覽器內核運行，再到JS引擎單線程，再到JS事件循環機制，從頭到尾系統的梳理一遍，擺脫碎片化，形成一個知識體系

目標是：看完這篇文章后，對瀏覽器多進程，JS單線程，JS事件循環機制這些都能有一定理解，有一個知識體系骨架，而不是似懂非懂的感覺。

另外，本文適合有一定經驗的前端人員， 新手請規避 ，避免受到過多的概念沖擊。可以先存起來，有了一定理解后再看，也可以分成多批次觀看，避免過度疲勞。

大綱

區分進程和線程
瀏覽器是多進程的
- 瀏覽器都包含哪些進程？
- 瀏覽器多進程的優勢
- 重點是瀏覽器內核（渲染進程）
- Browser進程和瀏覽器內核（Renderer進程）的通信過程
</li>

梳理瀏覽器內核中線程之間的關系

GUI渲染線程與JS引擎線程互斥
JS阻塞頁面加載
WebWorker，JS的多線程？
WebWorker與SharedWorker

簡單梳理下瀏覽器渲染流程

load事件與DOMContentLoaded事件的先后
css加載是否會阻塞dom樹渲染？
普通圖層和復合圖層

從Event Loop談JS的運行機制

事件循環機制進一步補充
單獨說說定時器
setTimeout而不是setInterval
事件循環進階：macrotask與microtask
寫在最后的話

區分進程和線程

線程和進程區分不清，是很多新手都會犯的錯誤，沒有關系。這很正常。先看看下面這個形象的比喻：

進程是一個工廠，工廠有它的獨立資源
工廠之間相互獨立
線程是工廠中的工人，多個工人協作完成任務
工廠內有一個或多個工人
工人之間共享空間</pre>
再完善完善概念：
工廠的資源 -> 系統分配的內存（獨立的一塊內存）
工廠之間的相互獨立 -> 進程之間相互獨立
多個工人協作完成任務 -> 多個線程在進程中協作完成任務
工廠內有一個或多個工人 -> 一個進程由一個或多個線程組成

工人之間共享空間 -> 同一進程下的各個線程之間共享程序的內存空間（包括代碼段、數據集、堆等）</pre>

然后再鞏固下：

如果是windows電腦中，可以打開任務管理器，可以看到有一個后臺進程列表。對，那里就是查看進程的地方，而且可以看到每個進程的內存資源信息以及cpu占有率。

所以，應該更容易理解了： 進程是cpu資源分配的最小單位（系統會給它分配內存）

最后，再用較為官方的術語描述一遍：

進程是cpu資源分配的最小單位（是能擁有資源和獨立運行的最小單位）
線程是cpu調度的最小單位（線程是建立在進程的基礎上的一次程序運行單位，一個進程中可以有多個線程）

tips

不同進程之間也可以通信，不過代價較大
現在，一般通用的叫法： 單線程與多線程 ，都是指 在一個進程內 的單和多。（所以核心還是得屬于一個進程才行）

瀏覽器是多進程的

理解了進程與線程了區別后，接下來對瀏覽器進行一定程度上的認識：（先看下簡化理解）

瀏覽器是多進程的
瀏覽器之所以能夠運行，是因為系統給它的進程分配了資源（cpu、內存）
簡單點理解，每打開一個Tab頁，就相當于創建了一個獨立的瀏覽器進程。

關于以上幾點的驗證， 請再第一張圖 ：

圖中打開了 Chrome 瀏覽器的多個標簽頁，然后可以在 Chrome的任務管理器中看到有多個進程（分別是每一個Tab頁面有一個獨立的進程，以及一個主進程）。感興趣的可以自行嘗試下，如果再多打開一個Tab頁，進程正常會+1以上

注意：在這里瀏覽器應該也有自己的優化機制，有時候打開多個tab頁后，可以在Chrome任務管理器中看到，有些進程被合并了（所以每一個Tab標簽對應一個進程并不一定是絕對的）

瀏覽器都包含哪些進程？

知道了瀏覽器是多進程后，再來看看它到底包含哪些進程：（為了簡化理解，僅列舉主要進程）

Browser進程：瀏覽器的主進程（負責協調、主控），只有一個。作用有
- 負責瀏覽器界面顯示，與用戶交互。如前進，后退等
- 負責各個頁面的管理，創建和銷毀其他進程
- 將Renderer進程得到的內存中的Bitmap，繪制到用戶界面上
- 網絡資源的管理，下載等
第三方插件進程：每種類型的插件對應一個進程，僅當使用該插件時才創建
GPU進程：最多一個，用于3D繪制等
瀏覽器渲染進程（瀏覽器內核）（Renderer進程，內部是多線程的）：默認每個Tab頁面一個進程，互不影響。主要作用為
- 頁面渲染，腳本執行，事件處理等

強化記憶：在瀏覽器中打開一個網頁相當于新起了一個進程（進程內有自己的多線程）

當然，瀏覽器有時會將多個進程合并（譬如打開多個空白標簽頁后，會發現多個空白標簽頁被合并成了一個進程），如圖

另外，可以通過Chrome的更多工具 -> 任務管理器自行驗證

瀏覽器多進程的優勢

相比于單進程瀏覽器，多進程有如下優點：

避免單個page crash影響整個瀏覽器
避免第三方插件crash影響整個瀏覽器
多進程充分利用多核優勢
方便使用沙盒模型隔離插件等進程，提高瀏覽器穩定性

簡單點理解：如果瀏覽器是單進程，那么某個Tab頁崩潰了，就影響了整個瀏覽器，體驗有多差；同理如果是單進程，插件崩潰了也會影響整個瀏覽器；而且多進程還有其它的諸多優勢。。。

當然，內存等資源消耗也會更大，有點空間換時間的意思。

重點是瀏覽器內核（渲染進程）

重點來了，我們可以看到，上面提到了這么多的進程，那么，對于普通的前端操作來說，最終要的是什么呢？答案是 渲染進程

可以這樣理解，頁面的渲染，JS的執行，事件的循環，都在這個進程內進行。接下來重點分析這個進程

請牢記，瀏覽器的渲染進程是多線程的（這點如果不理解， 請回頭看進程和線程的區分 ）

終于到了線程這個概念了:sob:，好親切。那么接下來看看它都包含了哪些線程（列舉一些主要常駐線程）：

GUI渲染線程
- 負責渲染瀏覽器界面，解析HTML，CSS，構建DOM樹和RenderObject樹，布局和繪制等。
- 當界面需要重繪（Repaint）或由于某種操作引發回流(reflow)時，該線程就會執行
- 注意， GUI渲染線程與JS引擎線程是互斥的 ，當JS引擎執行時GUI線程會被掛起（相當于被凍結了），GUI更新會被保存在一個隊列中 等到JS引擎空閑時 立即被執行。
JS引擎線程
- 也稱為JS內核，負責處理Javascript腳本程序。（例如V8引擎）
- JS引擎線程負責解析Javascript腳本，運行代碼。
- JS引擎一直等待著任務隊列中任務的到來，然后加以處理，瀏覽器無論什么時候都只有一個JS線程在運行JS程序
- 同樣注意， GUI渲染線程與JS引擎線程是互斥的 ，所以如果JS執行的時間過長，這樣就會造成頁面的渲染不連貫，導致頁面渲染加載阻塞。
事件觸發線程
- 歸屬于瀏覽器而不是JS引擎，用來控制事件循環（可以理解，JS引擎自己都忙不過來，需要瀏覽器另開線程協助）
- 當JS引擎執行代碼塊如setTimeOut時（也可來自瀏覽器內核的其他線程,如鼠標點擊、AJAX異步請求等），會將對應任務添加到事件線程中
- 當對應的事件符合觸發條件被觸發時，該線程會把事件添加到待處理隊列的隊尾，等待JS引擎的處理
- 注意，由于JS的單線程關系，所以這些待處理隊列中的事件都得排隊等待JS引擎處理（當JS引擎空閑時才會去執行）
定時觸發器線程
- 傳說中的 setInternal 與 setTimeout 所在線程
- 瀏覽器定時計數器并不是由JavaScript引擎計數的,（因為JavaScript引擎是單線程的, 如果處于阻塞線程狀態就會影響記計時的準確）
- 因此通過單獨線程來計時并觸發定時（計時完畢后，添加到事件隊列中，等待JS引擎空閑后執行）
- 注意，W3C在HTML標準中規定，規定要求setTimeout中低于4ms的時間間隔算為4ms。
異步http請求線程
- 在XMLHttpRequest在連接后是通過瀏覽器新開一個線程請求
- 將檢測到狀態變更時，如果設置有回調函數，異步線程就 產生狀態變更事件 ，將這個回調再放入事件隊列中。再由JavaScript引擎執行。

看到這里，如果覺得累了，可以先休息下，這些概念需要被消化，畢竟后續將提到的事件循環機制就是基于事件觸發線程的，所以如果僅僅是看某個碎片化知識，可能會有一種似懂非懂的感覺。要完成的梳理一遍才能快速沉淀，不易遺忘。放張圖鞏固下吧：

再說一點，為什么JS引擎是單線程的？額，這個問題其實應該沒有標準答案，譬如，可能僅僅是因為由于多線程的復雜性，譬如多線程操作一般要加鎖，因此最初設計時選擇了單線程。。。

Browser進程和瀏覽器內核（Renderer進程）的通信過程

看到這里，首先，應該對瀏覽器內的進程和線程都有一定理解了，那么接下來，再談談瀏覽器的Browser進程（控制進程）是如何和內核通信的，這點也理解后，就可以將這部分的知識串聯起來，從頭到尾有一個完整的概念。

如果自己打開任務管理器，然后打開一個瀏覽器，就可以看到：任務管理器中出現了兩個進程（一個是主控進程，一個則是打開Tab頁的渲染進程），然后在這前提下，看下整個的過程：(簡化了很多)

Browser進程收到用戶請求，首先需要獲取頁面內容（譬如通過網絡下載資源），隨后將該任務通過RendererHost接口傳遞給Render進程
Renderer進程的Renderer接口收到消息，簡單解釋后，交給渲染線程，然后開始渲染
- 渲染線程接收請求，加載網頁并渲染網頁，這其中可能需要Browser進程獲取資源和需要GPU進程來幫助渲染
- 當然可能會有JS線程操作DOM（這樣可能會造成回流并重繪）
- 最后Render進程將結果傳遞給Browser進程
</li>
Browser進程接收到結果并將結果繪制出來

這里繪一張簡單的圖：（很簡化）

看完這一整套流程，應該對瀏覽器的運作有了一定理解了，這樣有了知識架構的基礎后，后續就方便往上填充內容。

這塊再往深處講的話就涉及到瀏覽器內核源碼解析了，不屬于本文范圍。

如果這一塊要深挖，建議去讀一些瀏覽器內核源碼解析文章，或者可以先看看參考下來源中的第一篇文章，寫的不錯

梳理瀏覽器內核中線程之間的關系

到了這里，已經對瀏覽器的運行有了一個整體的概念，接下來，先簡單梳理一些概念

GUI渲染線程與JS引擎線程互斥

由于JavaScript是可操縱DOM的，如果在修改這些元素屬性同時渲染界面（即JS線程和UI線程同時運行），那么渲染線程前后獲得的元素數據就可能不一致了。

因此為了防止渲染出現不可預期的結果，瀏覽器設置GUI渲染線程與JS引擎為互斥的關系，當JS引擎執行時GUI線程會被掛起， GUI更新則會被保存在一個隊列中等到JS引擎線程空閑時立即被執行。

JS阻塞頁面加載

從上述的互斥關系，可以推導出，JS如果執行時間過長就會阻塞頁面。

譬如，假設JS引擎正在進行巨量的計算，此時就算GUI有更新，也會被保存到隊列中，等待JS引擎空閑后執行。然后，由于巨量計算，所以JS引擎很可能很久很久后才能空閑，自然會感覺到巨卡無比。

所以，要盡量避免JS執行時間過長，這樣就會造成頁面的渲染不連貫，導致頁面渲染加載阻塞的感覺。

WebWorker，JS的多線程？

前文中有提到JS引擎是單線程的，而且JS執行時間過長會阻塞頁面，那么JS就真的對cpu密集型計算無能為力么？

所以，后來HTML5中支持了 Web Worker 。

MDN的官方解釋是：

Web Worker為Web內容在后臺線程中運行腳本提供了一種簡單的方法。線程可以執行任務而不干擾用戶界面

一個worker是使用一個構造函數創建的一個對象(e.g. Worker()) 運行一個命名的JavaScript文件

這個文件包含將在工作線程中運行的代碼; workers 運行在另一個全局上下文中,不同于當前的window

因此，使用 window快捷方式獲取當前全局的范圍 (而不是self) 在一個 Worker 內將返回錯誤</pre>

這樣理解下：

創建Worker時，JS引擎向瀏覽器申請開一個子線程（子線程是瀏覽器開的，完全受主線程控制，而且不能操作DOM）
JS引擎線程與worker線程間通過特定的方式通信（postMessage API，需要通過序列化對象來與線程交互特定的數據）

所以，如果有非常耗時的工作，請單獨開一個Worker線程，這樣里面不管如何翻天覆地都不會影響JS引擎主線程，只待計算出結果后，將結果通信給主線程即可，perfect!

而且注意下， JS引擎是單線程的 ，這一點的本質仍然未改變，Worker可以理解是瀏覽器給JS引擎開的外掛，專門用來解決那些大量計算問題。

其它，關于Worker的詳解就不是本文的范疇了，因此不再贅述。

WebWorker與SharedWorker

既然都到了這里，就再提一下 SharedWorker （避免后續將這兩個概念搞混）

WebWorker只屬于某個頁面，不會和其他頁面的Render進程（瀏覽器內核進程）共享
- 所以Chrome在Render進程中（每一個Tab頁就是一個render進程）創建一個新的線程來運行Worker中的JavaScript程序。
</li>

SharedWorker是瀏覽器所有頁面共享的，不能采用與Worker同樣的方式實現，因為它不隸屬于某個Render進程，可以為多個Render進程共享使用

所以Chrome瀏覽器為SharedWorker單獨創建一個進程來運行JavaScript程序，在瀏覽器中每個相同的JavaScript只存在一個SharedWorker進程，不管它被創建多少次。

看到這里，應該就很容易明白了，本質上就是進程和線程的區別。SharedWorker由獨立的進程管理，WebWorker只是屬于render進程下的一個線程

簡單梳理下瀏覽器渲染流程

本來是直接計劃開始談JS運行機制的，但想了想，既然上述都一直在談瀏覽器，直接跳到JS可能再突兀，因此，中間再補充下瀏覽器的渲染流程（簡單版本）

為了簡化理解，前期工作直接省略成：（要展開的或完全可以寫另一篇超長文）

瀏覽器輸入url，瀏覽器主進程接管，開一個下載線程，然后進行 http請求（略去DNS查詢，IP尋址等等操作），然后等待響應，獲取內容，隨后將內容通過RendererHost接口轉交給Renderer進程
瀏覽器渲染流程開始</pre>
瀏覽器器內核拿到內容后，渲染大概可以劃分成以下幾個步驟：
1. 解析html建立dom樹
2. 解析css構建render樹（將CSS代碼解析成樹形的數據結構，然后結合DOM合并成render樹）
3. 布局render樹（Layout/reflow），負責各元素尺寸、位置的計算
4. 繪制render樹（paint），繪制頁面像素信息
5. 瀏覽器會將各層的信息發送給GPU，GPU會將各層合成（composite），顯示在屏幕上。
所有詳細步驟都已經略去，渲染完畢后就是 load 事件了，之后就是自己的JS邏輯處理了

既然略去了一些詳細的步驟，那么就提一些可能需要注意的細節把。

load事件與DOMContentLoaded事件的先后

上面提到，渲染完畢后會觸發 load 事件，那么你能分清楚 load 事件與 DOMContentLoaded 事件的先后么？

很簡單，知道它們的定義就可以了：
- 當 DOMContentLoaded 事件觸發時，僅當DOM加載完成，不包括樣式表，圖片。 (譬如如果有async加載的腳本就不一定完成)
- 當 onload 事件觸發時，頁面上所有的DOM，樣式表，腳本，圖片都已經加載完成了。（渲染完畢了）
所以，順序是： DOMContentLoaded -> load

css加載是否會阻塞dom樹渲染？

這里說的是頭部引入css的情況

首先，我們都知道： css是由單獨的下載線程異步下載的。

然后再說下幾個現象：
- css加載不會阻塞DOM樹解析（異步加載時DOM照常構建）
- 但會阻塞render樹渲染（渲染時需等css加載完畢，因為render樹需要css信息）
這可能也是瀏覽器的一種優化機制。

因為你加載css的時候，可能會修改下面DOM節點的樣式，如果css加載不阻塞render樹渲染的話，那么當css加載完之后， render樹可能又得重新重繪或者回流了，這就造成了一些沒有必要的損耗。所以干脆就先把DOM樹的結構先解析完，把可以做的工作做完，然后等你css加載完之后，在根據最終的樣式來渲染render樹，這種做法性能方面確實會比較好一點。

普通圖層和復合圖層

渲染步驟中就提到了 composite 概念。

可以簡單的這樣理解，瀏覽器渲染的圖層一般包含兩大類：普通圖層以及復合圖層

首先，普通文檔流內可以理解為一個復合圖層（這里稱為默認復合層，里面不管添加多少元素，其實都是在同一個復合圖層中）

其次，absolute布局（fixed也一樣），雖然可以脫離普通文檔流，但它仍然屬于默認復合層。

然后，可以通過硬件加速的方式，聲明一個新的復合圖層，它會單獨分配資源（當然也會脫離普通文檔流，這樣一來，不管這個復合圖層中怎么變化，也不會影響默認復合層里的回流重繪）

可以簡單理解下： GPU中，各個復合圖層是單獨繪制的，所以互不影響 ，這也是為什么某些場景硬件加速效果一級棒

可以 Chrome源碼調試 -> More Tools -> Rendering -> Layer borders 中看到，黃色的就是復合圖層信息

如下圖。可以驗證上述的說法

如何變成復合圖層（硬件加速）

將該元素變成一個復合圖層，就是傳說中的硬件加速技術
- 最常用的方式： translate3d 、 translateZ
- opacity 屬性/過渡動畫（需要動畫執行的過程中才會創建合成層，動畫沒有開始或結束后元素還會回到之前的狀態）
- will-chang 屬性（這個比較偏僻），一般配合opacity與translate使用（而且經測試，除了上述可以引發硬件加速的屬性外，其它屬性并不會變成復合層），作用是提前告訴瀏覽器要變化，這樣瀏覽器會開始做一些優化工作（這個最好用完后就釋放）
- <video><iframe><canvas><webgl> 等元素
- 其它，譬如以前的flash插件
absolute和硬件加速的區別

可以看到，absolute雖然可以脫離普通文檔流，但是無法脫離默認復合層。所以，就算absolute中信息改變時不會改變普通文檔流中render樹，但是，瀏覽器最終繪制時，是整個復合層繪制的，所以absolute中信息的改變，仍然會影響整個復合層的繪制。（瀏覽器會重繪它，如果復合層中內容多，absolute帶來的繪制信息變化過大，資源消耗是非常嚴重的）

而硬件加速直接就是在另一個復合層了（另起爐灶），所以它的信息改變不會影響默認復合層（當然了，內部肯定會影響屬于自己的復合層），僅僅是引發最后的合成（輸出視圖）

復合圖層的作用？

一般一個元素開啟硬件加速后會變成復合圖層，可以獨立于普通文檔流中，改動后可以避免整個頁面重繪，提升性能

但是盡量不要大量使用復合圖層，否則由于資源消耗過度，頁面反而會變的更卡

硬件加速時請使用index

使用硬件加速時，盡可能的使用index，防止瀏覽器默認給后續的元素創建復合層渲染

具體的原理時這樣的： webkit CSS3中，如果這個元素添加了硬件加速，并且index層級比較低，那么在這個元素的后面其它元素（層級比這個元素高的，或者相同的，并且releative或absolute屬性相同的），會默認變為復合層渲染，如果處理不當會極大的影響性能

簡單點理解，其實可以認為是一個隱式合成的概念：如果a是一個復合圖層，而且b在a上面，那么b也會被隱式轉為一個復合圖層，這點需要特別注意

另外，這個問題可以在這個地址看到重現（原作者分析的挺到位的，直接上鏈接）：

http://web.jobbole.com/83575/

從Event Loop談JS的運行機制

到此時，已經是屬于瀏覽器頁面初次渲染完畢后的事情，JS引擎的一些運行機制分析。

注意，這里不談可執行上下文， VO ， scop chain 等概念（這些完全可以整理成另一篇文章了），這里主要是結合 Event Loop 來談JS代碼是如何執行的。

讀這部分的前提是已經知道了JS引擎是單線程，而且這里會用到上文中的幾個概念：（如果不是很理解，可以回頭溫習）
- JS引擎線程
- 事件觸發線程
- 定時觸發器線程
然后再理解一個概念：
- JS分為同步任務和異步任務
- 同步任務都在主線程上執行，形成一個執行棧
- 主線程之外， 事件觸發線程 管理著一個任務隊列，只要異步任務有了運行結果，就在任務隊列之中放置一個事件。
- 一旦執行棧中的所有同步任務執行完畢（此時JS引擎空閑），系統就會讀取任務隊列，將可運行的異步任務添加到可執行棧中，開始執行。
看圖：

看到這里，應該就可以理解了：為什么有時候setTimeout推入的事件不能準時執行？因為可能在它推入到事件列表時，主線程還不空閑，正在執行其它代碼，所以自然有誤差。

事件循環機制進一步補充

這里就直接引用一張圖片來協助理解：（參考自Philip Roberts的演講《 Help, I’m stuck in an event-loop 》）

上圖大致描述就是：
- 主線程運行時會產生執行棧，棧中的代碼調用某些api時，它們會在事件隊列中添加各種事件（當滿足觸發條件后，如ajax請求完畢）
- 而棧中的代碼執行完畢，就會讀取事件隊列中的事件，去執行那些回調
- 如此循環
- 注意，總是要等待棧中的代碼執行完畢后才會去讀取事件隊列中的事件
單獨說說定時器

上述事件循環機制的核心是：JS引擎線程和事件觸發線程

但事件上，里面還有一些隱藏細節，譬如調用 setTimeout 后，是如何等待特定時間后才添加到事件隊列中的？

是JS引擎檢測的么？當然不是了。它是由 定時器線程 控制（因為JS引擎自己都忙不過來，根本無暇分身）

為什么要單獨的定時器線程？因為JavaScript引擎是單線程的, 如果處于阻塞線程狀態就會影響記計時的準確，因此很有必要單獨開一個線程用來計時。

什么時候會用到定時器線程？ 當使用 setTimeout 或 setInterval 時 ，它需要定時器線程計時，計時完成后就會將特定的事件推入事件隊列中。

譬如:
```
setTimeout(function(){
  console.log('hello!');
}, 1000);
```
這段代碼的作用是當 1000 毫秒計時完畢后（由定時器線程計時），將回調函數推入事件隊列中，等待主線程執行
```
setTimeout(function(){
  console.log('hello!');
}, 0);
```

console.log('begin');</pre>

這段代碼的效果是最快的時間內將回調函數推入事件隊列中，等待主線程執行

注意：

執行結果是：先 begin 后 hello!
雖然代碼的本意是0毫秒后就推入事件隊列，但是W3C在HTML標準中規定，規定要求setTimeout中低于4ms的時間間隔算為4ms。 (不過也有一說是不同瀏覽器有不同的最小時間設定)
就算不等待4秒，就算假設0毫秒就推入事件隊列，也會先執行 begin （因為只有可執行棧內空了后才會主動讀取事件隊列）

setTimeout而不是setInterval

用setTimeout模擬定期計時和直接用setInterval是有區別的。

因為每次setTimeout計時到后就會去執行，然后執行一段時間后才會繼續setTimeout，中間就多了誤差（誤差多少與代碼執行時間有關）

而setInterval則是每次都精確的隔一段時間推入一個事件（但是，事件的實際執行時間不一定就準確，還有可能是這個事件還沒執行完畢，下一個事件就來了）

而且setInterval有一些比較致命的問題就是：

累計效應（上面提到的），如果setInterval代碼在（setInterval）再次添加到隊列之前還沒有完成執行，就會導致定時器代碼連續運行好幾次，而之間沒有間隔。就算正常間隔執行，多個setInterval的代碼執行時間可能會比預期小（因為代碼執行需要一定時間）
譬如像iOS的webview,或者Safari等瀏覽器中都有一個特點， 在滾動的時候是不執行JS的 ，如果使用了setInterval，會發現在滾動結束后會執行多次由于滾動不執行JS積攢回調，如果回調執行時間過長,就會非常容器造成卡頓問題和一些不可知的錯誤
而且把瀏覽器最小化顯示等操作時，setInterval并不是不執行程序，它會把setInterval的回調函數放在隊列中，等瀏覽器窗口再次打開時，一瞬間全部執行時

所以，鑒于這么多但問題，目前一般認為的最佳方案是：用setTimeout模擬setInterval，或者特殊場合直接用requestAnimationFrame

事件循環進階：macrotask與microtask

這段參考了參考來源中的第2篇文章（英文版的），（加了下自己的理解重新描述了下），強烈推薦有英文基礎的同學直接觀看原文，作者描述的很清晰，示例也很不錯，如下：

https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

上文中將JS事件循環機制梳理了一遍，在ES5的情況是夠用了，但是在ES6盛行的現在，仍然會遇到一些問題，譬如下面這題：

console.log('script start');

setTimeout(function() { console.log('setTimeout'); }, 0);

Promise.resolve().then(function() { console.log('promise1'); }).then(function() { console.log('promise2'); });

console.log('script end');</pre>

嗯哼，它的正確執行順序是這樣子的：

script start
script end
promise1
promise2
setTimeout

為什么呢？因為Promise里有了一個一個新的概念： microtask

或者，進一步，JS中分為兩種任務類型： macrotask 和 microtask ，在ECMAScript中，microtask稱為 jobs ，macrotask可稱為 task

它們的定義？區別？簡單點可以按如下理解：

macrotask（又稱之為宏任務），可以理解是每次執行棧執行的代碼就是一個宏任務（包括每次從事件隊列中獲取一個事件回調并放到執行棧中執行）
- 每一個task會從頭到尾將這個任務執行完畢，不會執行其它
- 瀏覽器為了能夠使得JS內部task與DOM任務能夠有序的執行，會在一個task執行結束后，在下一個 task 執行開始前，對頁面進行重新渲染（ task->渲染->task->... ）
</li>
microtask（又稱為微任務），可以理解是在當前 task 執行結束后立即執行的任務
- 也就是說，在當前task任務后，下一個task之前，在渲染之前
- 所以它的響應速度相比setTimeout（setTimeout是task）會更快，因為無需等渲染
- 也就是說，在某一個macrotask執行完后，就會將在它執行期間產生的所有microtask都執行完畢（在渲染前）

本文由用戶 m_ytes18do 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1516596740503.html

多進程 JavaScript開發 JavaScript

從瀏覽器多進程到JS單線程，JS運行機制最全面的一次梳理

前言

大綱

區分進程和線程

瀏覽器是多進程的

瀏覽器都包含哪些進程？

瀏覽器多進程的優勢

重點是瀏覽器內核（渲染進程）

Browser進程和瀏覽器內核（Renderer進程）的通信過程

梳理瀏覽器內核中線程之間的關系

GUI渲染線程與JS引擎線程互斥

JS阻塞頁面加載

WebWorker，JS的多線程？

WebWorker與SharedWorker

簡單梳理下瀏覽器渲染流程

load事件與DOMContentLoaded事件的先后

css加載是否會阻塞dom樹渲染？

普通圖層和復合圖層

從Event Loop談JS的運行機制

事件循環機制進一步補充

單獨說說定時器

setTimeout而不是setInterval

事件循環進階：macrotask與microtask

寫在最后的話

附錄

博客

參考資料

相關經驗

相關資訊

相關文檔

目錄