摘要：瀏覽器渲染進(jìn)程瀏覽器內(nèi)核進(jìn)程，內(nèi)部是多線程的默認(rèn)每個頁面一個進(jìn)程，互不影響。事件觸發(fā)線程歸屬于瀏覽器而不是引擎，用來控制事件循環(huán)可以理解成引擎自己都忙不過來，需要瀏覽器另開線程協(xié)助。

線程和進(jìn)程

進(jìn)程和線程的概念可以這樣理解：

進(jìn)程是一個工廠，工廠有它的獨立資源--工廠之間相互獨立--線程是工廠中的工人，多個工人協(xié)作完成任務(wù)--工廠內(nèi)有一個或多個工人--工人之間共享空間

工廠有多個工人，就相當(dāng)于一個進(jìn)程可以有多個線程，而且線程共享進(jìn)程的空間。

進(jìn)程是cpu資源分配的最小單位（是能擁有資源和獨立運行的最小單位，系統(tǒng)會給它分配內(nèi)存）
線程是cpu調(diào)試的最小單位（線程是建立在進(jìn)程的基礎(chǔ)上的一次程序運行單位，一個進(jìn)程中可以有多個線程。核心還是屬于一個進(jìn)程。）

瀏覽器是多進(jìn)程的

瀏覽器是多進(jìn)程的，每打開一個tab頁，就相當(dāng)于創(chuàng)建了一個獨立的瀏覽器進(jìn)程。

瀏覽器包含的進(jìn)程：

Browser進(jìn)程：瀏覽器的主進(jìn)程（負(fù)責(zé)協(xié)調(diào)，主控），只有一個，作用有：

負(fù)責(zé)瀏覽器的界面顯示，與用戶交互，如前進(jìn)，后退等

負(fù)責(zé)各個頁面的管理，創(chuàng)建和銷毀其它進(jìn)程

將Rendered進(jìn)程得到的內(nèi)存中的Bitmap,繪制到用戶界面上

網(wǎng)絡(luò)資源的管理，下載

第三方插件進(jìn)程：每種類型的插件對應(yīng)一個進(jìn)程，僅當(dāng)使用該插件時才創(chuàng)建。

GPU進(jìn)程：最多一個，用于3D繪制等。

瀏覽器渲染進(jìn)程（瀏覽器內(nèi)核）（Render進(jìn)程，內(nèi)部是多線程的）：默認(rèn)每個Tab頁面一個進(jìn)程，互不影響。主要作用為：

頁面渲染，腳本執(zhí)行，事件處理等

在瀏覽器中打開一個網(wǎng)頁相當(dāng)于新起了一個進(jìn)程（進(jìn)程內(nèi)有自己的多線程）

瀏覽器多進(jìn)程的優(yōu)勢

避免單個page crash影響整個瀏覽器

避免第三方插件crash影響整個瀏覽器

多進(jìn)程充分利用多核優(yōu)勢

方便使用沙盒模型隔離插件等進(jìn)程，提高瀏覽器穩(wěn)定性

簡單理解就是：如果瀏覽器是單進(jìn)程的，某個Tab頁崩潰了，就影響了整個瀏覽器，體驗就會很差。同理如果是單進(jìn)程的，插件崩潰了也會影響整個瀏覽器;
當(dāng)然，內(nèi)存等資源消耗也會更大，像空間換時間一樣。

重點是瀏覽器內(nèi)核（渲染進(jìn)程）

對于普通的前端操作來說，最重要的渲染進(jìn)程：頁面的渲染，js的執(zhí)行，事件的循環(huán)等都在這個進(jìn)程內(nèi)執(zhí)行;

瀏覽器是多進(jìn)程的，瀏覽器的渲染進(jìn)程是多線程的；

GUI渲染線程

負(fù)責(zé)渲染瀏覽器界面，解析HTML,CSS,構(gòu)建DOM樹和RenderObject樹，布局和繪制等。

當(dāng)界面需要重繪或由于某種操作引發(fā)回流時，該線程就會執(zhí)行。

注意，GUI渲染線程與JS引擎線程是互斥的，當(dāng)JS引擎執(zhí)行時GUI線程會被掛起（相當(dāng)于凍結(jié)了）,GUI更新會被保存在一個隊列中等到JS引擎空閑時立即被執(zhí)行。

JS引擎線程

也稱為JS內(nèi)核，負(fù)責(zé)處理JavaScript腳本程序。（例如V8引擎）。

JS引擎線程負(fù)責(zé)解析JavaScript腳本，運行代碼。

JS引擎一直等待著任務(wù)隊列中任務(wù)的到來，然后加以處理，一個Tab頁（render進(jìn)程）中無論什么時候都只有一個JS線程在運行JS程序。

同樣注意，GUI渲染線程與JS引擎線程是互斥的，所以如果JS執(zhí)行的時間過長，這樣就會造成頁面的渲染不連貫，導(dǎo)致頁面渲染加載阻塞。

事件觸發(fā)線程

歸屬于瀏覽器而不是JS引擎，用來控制事件循環(huán)（可以理解成JS引擎自己都忙不過來，需要瀏覽器另開線程協(xié)助）。

當(dāng)JS引擎執(zhí)行代碼塊如setTimeout時（也可來自瀏覽器內(nèi)核的其它線程，如鼠標(biāo)點擊，AJAX異步請求等），會將對應(yīng)任務(wù)添加到事件線程中。

當(dāng)對應(yīng)的事件符合觸發(fā)條件被觸發(fā)時，該線程會把事件添加到待處理隊列的隊尾，等待JS引擎的處理。

注意，由于JS的單線程關(guān)系，所以這些待處理隊列中的事件都得排隊等待JS引擎處理（當(dāng)JS引擎空閑時才會去執(zhí)行）。

定時觸發(fā)器線程

傳說中的setTimeout和setInterval所在的線程

瀏覽器定時計數(shù)器并不是由JavaScript引擎計數(shù)的，（因為JavaScript引擎是單線程的，如果處于阻塞線程狀態(tài)就會影響計時的準(zhǔn)確）

因此通過多帶帶線程來計時并觸發(fā)定時（計時完畢后，添加到事件隊列中，等待JS引擎空閑后執(zhí)行）

注意，W3C在HTML標(biāo)準(zhǔn)中規(guī)定，規(guī)定要求setTimeout中低于4ms的時間間隔算為4ms。

異步http請求線程

在XMLHttpRequest在連接后是通過瀏覽器新型一個線程請求

將檢測到狀態(tài)變更時，如果設(shè)置有回調(diào)函數(shù)，異步線程就產(chǎn)生狀態(tài)變更事件，將這個回調(diào)再放入事件隊列中，再由JavaScript引擎執(zhí)行

總結(jié)下來，渲染進(jìn)程如下：

Browser主進(jìn)程和瀏覽器內(nèi)核（渲染進(jìn)程）的通信過程

打開一個瀏覽器，可以看到：任務(wù)管理器出現(xiàn)了2個進(jìn)程（一個主進(jìn)程，一個是打開Tab頁的渲染進(jìn)程）；

Browser主進(jìn)程收到用戶請求，首先需要獲取頁面內(nèi)容（如通過網(wǎng)絡(luò)下載資源）,隨后將該任務(wù)通過RendererHost接口傳遞給Render渲染進(jìn)程

Render渲染進(jìn)程的Renderer接口收到消息，簡單解釋后，交給渲染線程GUI，然后開始渲染

GUI渲染線程接收請求，加載網(wǎng)頁并渲染網(wǎng)頁，這其中可能需要Browser主進(jìn)程獲取資源和需要GPU進(jìn)程來幫助渲染

當(dāng)然可能會有JS線程操作DOM（這可能會造成回流并重繪）

最后Render渲染進(jìn)程將結(jié)果傳遞給Browser主進(jìn)程

Browser主進(jìn)程接收到結(jié)果并將結(jié)果繪制出來

瀏覽器內(nèi)核（渲染進(jìn)程）中線程之間的關(guān)系

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

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

因此，為了防止渲染出現(xiàn)不可預(yù)期的結(jié)果，瀏覽器就設(shè)置了互斥的關(guān)系，當(dāng)JS引擎執(zhí)行時GUI線程會被掛起。GUI更新則會被保存在一個隊列中等到JS引擎線程空閑時立即被執(zhí)行。

JS阻塞頁面加載

從上述的互斥關(guān)系，可以推導(dǎo)出，JS如果執(zhí)行時間過長就會阻塞頁面。

譬如，假設(shè)JS引擎正在進(jìn)行巨量的計算，此時就算GUI有更新，也會被保存在隊列中，要等到JS引擎空閑后執(zhí)行。然后由于巨量計算，所以JS引擎可能很久很久才能空閑，肯定就會感覺很卡。

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

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

這里說的是頭部引入css的情況
首先，我們都知道：css是由多帶帶的下載線程異步下載的。
然后還有幾個現(xiàn)象：

css加載不會阻塞DOM樹解析（異步加載時dom照常構(gòu)建）

但會阻塞render樹渲染（渲染時需要等css加載完畢，因為render樹需要css信息）

這可能也是瀏覽器的一種優(yōu)化機制
因為你加載css的時候，可能會修改下面DOM節(jié)點的樣式，如果css加載不阻塞render樹渲染的話，那么當(dāng)css加載完之后，render樹可能又得重新重繪或者回流了，這就造成了一些沒有必要的損耗
所以干脆把DOM樹的結(jié)構(gòu)先解析完，把可以做的工作做完，然后等css加載完之后，在根據(jù)最終的樣式來渲染render樹，這種做法確實對性能好一點。

WebWorker,JS的多線程？

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

所以，后來HTML5中支持了WebWorker。

這樣理解下：

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

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

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

WebWorker與SharedWorker

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

WebWorker只屬于某個頁面，不會和其他頁面的Render進(jìn)程（瀏覽器內(nèi)核進(jìn)程）共享
所以Chrome在Render進(jìn)程中（每一個Tab頁就是一個render進(jìn)程）創(chuàng)建一個新的線程來運行Worker中的JavaScript程序。

SharedWorker是瀏覽器所有頁面共享的，不能采用與Worker同樣的方式實現(xiàn)，因為它不隸屬于某個Render進(jìn)程，可以為多個Render進(jìn)程共享使用
所以Chrome瀏覽器為SharedWorker多帶帶創(chuàng)建一個進(jìn)程來運行JavaScript程序，在瀏覽器中每個相同的JavaScript只存在一個SharedWorker進(jìn)程，不管它被創(chuàng)建多少次。

看到這里，應(yīng)該就很容易明白了，本質(zhì)上就是進(jìn)程和線程的區(qū)別。SharedWorker由獨立的進(jìn)程管理，WebWorker只是屬于render進(jìn)程下的一個線程

總結(jié)瀏覽器渲染流程

瀏覽器輸入url，瀏覽器主進(jìn)程接管，開一個下載線程，然后進(jìn)行http請求（略去DNS查詢，IP尋址等等操作），然后等待響應(yīng)，獲取內(nèi)容，隨后將內(nèi)容通過RendererHost接口轉(zhuǎn)交給Render進(jìn)程--瀏覽器渲染流程開始

瀏覽器內(nèi)核拿到內(nèi)容后，渲染大概可以劃分為：

解析html建立dom要

解析css構(gòu)建render樹（將css代碼解析成樹形的數(shù)據(jù)結(jié)構(gòu)，然后結(jié)合dom合并成render樹）

布局render樹（Layout/reflow）,負(fù)責(zé)各元素尺寸，位置的計算

繪制render樹（paint），繪制頁面像素信息

瀏覽器會將各層的信息發(fā)送給GPU，GPU會將各層合成（composite）,顯示在屏幕上

渲染完畢后就是load事件了，之后就是自己的JS邏輯處理了，略去了詳細(xì)步驟。

load事件與DOMContentLoaded事件的先后

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

很簡單，知道它們的定義就可以了：

當(dāng) DOMContentLoaded 事件觸發(fā)時，僅當(dāng)DOM加載完成，不包括樣式表，圖片。
(譬如如果有async加載的腳本就不一定完成)

當(dāng) onload 事件觸發(fā)時，頁面上所有的DOM，樣式表，腳本，圖片都已經(jīng)加載完成了。（渲染完畢了）

所以，順序是：DOMContentLoaded -> load

普通圖層和復(fù)合圖層

渲染步驟就提到了composite概念;瀏覽器渲染的圖層一般包含兩大類：普通圖層以及復(fù)合圖層。

普通文檔流內(nèi)可以理解為一個復(fù)合圖層（這里默認(rèn)復(fù)合層，里面不管添加多少元素，其實都是在同個復(fù)合圖層中）

absolute布局（fixed也一樣），雖然可以脫離文檔流，但它仍然屬于默認(rèn)復(fù)合層

可以通過硬件加速的方式，聲明一個新的復(fù)合圖層，它會多帶帶分配資源（當(dāng)然也會脫離普通文檔流，這樣一來，不管這個復(fù)合圖層中怎么變化，也不會影響默認(rèn)復(fù)合層里的回流重繪）

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

如何變成復(fù)合圖層（硬件加速）

將元素變成一個復(fù)合圖層，就是傳說中的硬件加速技術(shù)

最常用的方式：translate3d,translatez

opacity屬性/過渡動畫（需要動畫執(zhí)行的過程中才會創(chuàng)建合成層，動畫沒有開始或結(jié)束后元素還會回到之前的狀態(tài)）

will-chang屬性（這個比較偏僻），一般配合opacity與translate使用（而且經(jīng)測試，除了上述可以引發(fā)硬件加速的屬性外，其它屬性并不會變成復(fù)合層），作用是提前告訴瀏覽器要變化，這樣瀏覽器會開始做一些優(yōu)化工作（這個最好用完后就釋放）