前言

本文主要介紹如下內(nèi)容：

瀏覽器的高層結(jié)構(gòu)
瀏覽器的渲染原理
瀏覽器如何加載JAVAscript腳本
JavaScript引擎如何工作

引入

在瀏覽器中輸入U(xiǎn)RL并回車后都發(fā)生了什么？

讓我們從大家最熟悉的這個(gè)面試問(wèn)題引入，先不往下看文章，你能脫口而出的說(shuō)出答案嘛？如果可以恭喜你，你可以跳過(guò)這一小節(jié)。如果不可以那就還是看一下吧~

URL解析：從URL中抽取出域名字段
DNS域名解析： 查找瀏覽器緩存：瀏覽器會(huì)緩存2-30分鐘訪問(wèn)過(guò)網(wǎng)站的DNS信息，如未找到 檢查系統(tǒng)緩存：檢查hosts文件，它保存了一些訪問(wèn)過(guò)網(wǎng)站的域名和IP的數(shù)據(jù)，如未找到 檢查路由器緩存：路由器有自己的DNS緩存，如未找到 檢查ISP DNS緩存：ISP服務(wù)商DNS緩存（本地服務(wù)器緩存），如未找到 遞歸查詢：從根域名服務(wù)器到頂級(jí)域名服務(wù)器再到極限域名服務(wù)器依次搜索對(duì)應(yīng)目標(biāo)域名的IP
瀏覽器與服務(wù)器建立TCP連接（3次握手）：第一次握手：客戶端向服務(wù)器端發(fā)送請(qǐng)求等待服務(wù)器確認(rèn) 第二次握手：服務(wù)器收到請(qǐng)求并確認(rèn)，回復(fù)一個(gè)指令第三次握手：客戶端收到服務(wù)器的回復(fù)指令并返回確認(rèn)
請(qǐng)求和傳輸數(shù)據(jù)：服務(wù)器解析客戶端請(qǐng)求，并返回相應(yīng)的數(shù)據(jù)
瀏覽器渲染頁(yè)面：這里先空著，我們下面講瀏覽器原理時(shí)展開(kāi)
關(guān)閉TCP連接：當(dāng)數(shù)據(jù)完成請(qǐng)求到返回的過(guò)程之后，根據(jù)Connection的Keep-Alive屬性可以選擇是否斷開(kāi)TCP連接，四次揮手釋放。

Emmmm，到這里這道題目基本解答完畢，但是卻引出了另一個(gè)問(wèn)題，瀏覽器從服務(wù)端拿到數(shù)據(jù)后做了什么才將網(wǎng)頁(yè)呈現(xiàn)到我們的顯示器上，下面就讓我們一起來(lái)探索瀏覽器的秘密吧~~

瀏覽器的高層結(jié)構(gòu)

首先讓我們看一下瀏覽器的主要組件：

用戶界面：包括地址欄、前進(jìn)/后退按鈕、書(shū)簽菜單等。除了瀏覽器主窗口顯示的您請(qǐng)求的頁(yè)面外，其他顯示的各個(gè)部分都屬于用戶界面。
瀏覽器引擎：在用戶界面和呈現(xiàn)引擎之間傳送指令。
呈現(xiàn)引擎：負(fù)責(zé)顯示請(qǐng)求的內(nèi)容。如果請(qǐng)求的內(nèi)容是 html，它就負(fù)責(zé)解析 HTML 和 css 內(nèi)容，并將解析后的內(nèi)容顯示在屏幕上。
網(wǎng)絡(luò)：用于網(wǎng)絡(luò)調(diào)用，比如 HTTP 請(qǐng)求。其接口與平臺(tái)無(wú)關(guān)，并為所有平臺(tái)提供底層實(shí)現(xiàn)。
用戶界面后端：用于繪制基本的窗口小部件，比如組合框和窗口。其公開(kāi)了與平臺(tái)無(wú)關(guān)的通用接口，而在底層使用操作系統(tǒng)的用戶界面方法。
Javascript解析器：用于解析和執(zhí)行 JavaScript 代碼。
數(shù)據(jù)存儲(chǔ)：這是持久層。瀏覽器需要在硬盤上保存各種數(shù)據(jù)，例如 Cookie。新的 HTML 規(guī)范 (HTML5) 定義了“網(wǎng)絡(luò)數(shù)據(jù)庫(kù)”，這是一個(gè)完整（但是輕便）的瀏覽器內(nèi)數(shù)據(jù)庫(kù)。

值得注意的是，和大多數(shù)瀏覽器不同，Chrome瀏覽器的每個(gè)標(biāo)簽頁(yè)都分別對(duì)應(yīng)一個(gè)呈現(xiàn)引擎實(shí)例。每個(gè)標(biāo)簽頁(yè)都是一個(gè)獨(dú)立的進(jìn)程。

瀏覽器的呈現(xiàn)引擎

在瀏覽器的主要組件中我們最關(guān)注的就是瀏覽器的呈現(xiàn)引擎，因?yàn)槌尸F(xiàn)引擎，顧名思義，它決定了呈現(xiàn)在瀏覽器的內(nèi)容。呈現(xiàn)引擎也叫做瀏覽器內(nèi)核，不同瀏覽器使用的呈現(xiàn)引擎是不一樣的。常見(jiàn)瀏覽器使用的呈現(xiàn)引擎如下：

呈現(xiàn)引擎瀏覽器 Trident(MSHTML) IE，MaxThon，TT，The World，360，搜狗瀏覽器等 Gecko Netscape6 及以上版本，F(xiàn)F，MozillaSuite/SeaMonkey 等 Presto Opera7及以上。 [Opera內(nèi)核原為：Presto，現(xiàn)為：Blink] Webkit Safari，Chrome等。[Chrome：Blink（WebKit 的分支）] EdgeHTML Microsoft Edge。 [此內(nèi)核其實(shí)是從 MSHTML fork 而來(lái)，刪掉了幾乎所有的 IE私有特性]

下面我們將以Webkit為例講解瀏覽器呈現(xiàn)引擎工作的主要流程，Gecko的工作流程與Webkit基本是相同的，只是術(shù)語(yǔ)略有不同。

Webkit的主要工作流程

上圖展示的是webkit的主要工作流程，接下來(lái)我們按照?qǐng)D片的流程來(lái)逐漸闡述Webkit是如何工作的。但在這之前我們先要明白從HTTP請(qǐng)求回來(lái)開(kāi)始，呈現(xiàn)引擎的整個(gè)工作流程不是一步做完再做下一步，而是一條流水線。

從HTTP請(qǐng)求回來(lái)，就產(chǎn)生了流式的數(shù)據(jù)，后續(xù)的DOM樹(shù)構(gòu)建、CSS計(jì)算、渲染、合成、繪制，都是盡可能地流式處理前一步的產(chǎn)出：即不需要等到上一步驟完全結(jié)束，就開(kāi)始處理上一步的輸出，這樣我們?cè)跒g覽網(wǎng)頁(yè)時(shí)，才會(huì)看到逐步出現(xiàn)的頁(yè)面。

HTML解析：從HTML到DOM樹(shù)

Webkit會(huì)用HTML解析算法將HTML轉(zhuǎn)換成DOM樹(shù)。下面讓我們看一下HTML到DOM樹(shù)的轉(zhuǎn)換：

接下來(lái)讓我們了解一下HTML解析算法，HTML解析算法的流程如下圖所示：

它分為標(biāo)記化和樹(shù)構(gòu)建兩個(gè)過(guò)程：

標(biāo)記化：將輸入的內(nèi)容解析成多個(gè)標(biāo)記（HTML標(biāo)記包括起始標(biāo)記，結(jié)束標(biāo)記，屬性名稱，屬性值）。標(biāo)記生成器識(shí)別標(biāo)記，傳遞給樹(shù)構(gòu)造器，然后接受下一個(gè)字符以識(shí)別下一個(gè)標(biāo)記；如此反復(fù)直至結(jié)束。標(biāo)記化算法是通過(guò)狀態(tài)機(jī)實(shí)現(xiàn)的。
樹(shù)構(gòu)建：標(biāo)記生成器發(fā)送的每個(gè)節(jié)點(diǎn)都由樹(shù)構(gòu)建器進(jìn)行處理，規(guī)范中定義了每個(gè)標(biāo)記所對(duì)應(yīng)的DOM元素，這些元素會(huì)在接收到對(duì)應(yīng)的標(biāo)記時(shí)構(gòu)建，這些元素不僅會(huì)被添加到DOM樹(shù)，還會(huì)添加到開(kāi)放元素的堆棧中。此堆棧用于糾正嵌套錯(cuò)誤和處理未關(guān)閉的標(biāo)記，其算法也可以用狀態(tài)機(jī)來(lái)表示。

HTML解析完成后，瀏覽器會(huì)將文檔狀態(tài)標(biāo)注為交互狀態(tài)，并開(kāi)始解析那些處于deferred模式的腳本，然后文檔狀態(tài)設(shè)置為完成，一個(gè)加載時(shí)間將隨之觸發(fā)。

CSS解析：從CSS到StyleSheet對(duì)象

CSS解析器會(huì)將CSS文件解析成StyleSheet對(duì)象，下面讓我們來(lái)看一下CSS到StyleSheet的轉(zhuǎn)換：

這里我們不講CSS構(gòu)建的過(guò)程，感興趣的小伙伴可以看一下參考資料里的重學(xué)前端，我們簡(jiǎn)單的介紹一下CSS選擇器的特點(diǎn)，這是由CSS設(shè)計(jì)原則所決定的。

選擇器出現(xiàn)的順序必定跟構(gòu)建DOM樹(shù)的順序一致，即保證選擇器在構(gòu)建到當(dāng)前節(jié)點(diǎn)時(shí)，已經(jīng)可以準(zhǔn)確判斷該節(jié)點(diǎn)所匹配的CSS規(guī)則，不需要后續(xù)節(jié)點(diǎn)信息。
CSS樣式匹配時(shí)是從右向左匹配的，DOM找到它所有匹配的CSS樣式后再做加權(quán)計(jì)算，確定最終樣式，所以也就不難理解chrome操作臺(tái)內(nèi)樣式表信息為何那樣展示了。

構(gòu)建呈現(xiàn)樹(shù)：整合DOM樹(shù)和StyleSheet對(duì)象為呈現(xiàn)樹(shù)

構(gòu)建呈現(xiàn)樹(shù)時(shí)，需要計(jì)算每一個(gè)呈現(xiàn)對(duì)象的可視化屬性。每個(gè)DOM節(jié)點(diǎn)都有一個(gè)"attach"方法，在節(jié)點(diǎn)插入DOM樹(shù)時(shí)會(huì)調(diào)用節(jié)點(diǎn)的attach方法，計(jì)算該節(jié)點(diǎn)的樣式屬性生成呈現(xiàn)器。下面讓我們看一下整合（webkit的術(shù)語(yǔ)叫‘附加’）的過(guò)程：

排版：將呈現(xiàn)器盒子放到對(duì)應(yīng)的位置

所有的呈現(xiàn)器都有一個(gè)“layout”或者“reflow”方法，每一個(gè)呈現(xiàn)器都會(huì)調(diào)用其需要進(jìn)行布局的子代的layout方法。有很多排版方法：正常流文字排版，絕對(duì)定位，浮動(dòng)元素排版，flex排版等。

渲染：把每一個(gè)呈現(xiàn)器對(duì)應(yīng)的盒子變成位圖

這里的渲染是借用計(jì)算機(jī)圖形學(xué)里面的解釋，就是把模型變成位圖的過(guò)程。

位圖就是在內(nèi)存里建立一張二維表格，把一張圖片的每個(gè)像素對(duì)應(yīng)的顏色保存進(jìn)去（位圖信息也是DOM樹(shù)中占據(jù)瀏覽器內(nèi)存最多的信息，我們?cè)谧鰞?nèi)存占用優(yōu)化時(shí)，主要就是考慮這一部分）。

合成：合成位圖，提升性能

這個(gè)過(guò)程實(shí)際上是一個(gè)性能考量，它并非實(shí)現(xiàn)瀏覽器的必要一環(huán)。合成的過(guò)程就是根據(jù)合成策略合并位圖。合成策略就是最大限度的減少繪制次數(shù)，它是“猜測(cè)”可能變化的元素，將它排除到合成之外。

目前，主流瀏覽器一般根據(jù)position、transform等屬性來(lái)決定合成策略，來(lái)“猜測(cè)”這些元素未來(lái)可能發(fā)生變化。但是，這樣的猜測(cè)準(zhǔn)確性有限，所以新的CSS標(biāo)準(zhǔn)中，規(guī)定了will-change屬性，可以由業(yè)務(wù)代碼來(lái)提示瀏覽器的合成策略，靈活運(yùn)用這樣的特性，可以大大提升合成策略的效果。

繪制：將位圖繪制到屏幕上，變成肉眼可見(jiàn)的圖像的過(guò)程

一般來(lái)說(shuō)，瀏覽器并不需要用代碼來(lái)處理這個(gè)過(guò)程，瀏覽器只需要把最終要顯示的位圖交給操作系統(tǒng)即可。

到這里我們已經(jīng)將Webkit主要的工作流程捋了一遍，現(xiàn)在讓我們來(lái)總結(jié)一下，從HTTP請(qǐng)求回來(lái)的數(shù)據(jù)通過(guò)HTML解析器和CSS解析器，分別解析成DOM樹(shù)和StyleSheet對(duì)象，然后整合兩者生成呈現(xiàn)樹(shù)，呈現(xiàn)樹(shù)調(diào)用layout進(jìn)行排版，然后通過(guò)渲染將呈現(xiàn)器盒子變成位圖，根據(jù)合成策略合成位圖提升繪制性能，把位圖給操作系統(tǒng)讓其繪制到屏幕上。看到這里我們很容易就理解了一個(gè)小知識(shí)點(diǎn)：CSS不會(huì)阻塞DOM的解析，但會(huì)阻塞DOM的渲染。

現(xiàn)在我們已經(jīng)以Webkit為例介紹了呈現(xiàn)引擎的主要工作流程，但是我們似乎還遺漏了些什么。對(duì)的，Javascript，我們好像一直沒(méi)有提及當(dāng)Webkit解析到JavaScript代碼時(shí)會(huì)怎么處理，接下來(lái)就讓我們一起來(lái)看一看這一部分知識(shí)吧~~

瀏覽器加載JavaScript腳本

正常加載流程

瀏覽器加載JavaScript腳本，主要通過(guò)<script>元素完成。其正常流程如下

瀏覽器的呈現(xiàn)引擎持有渲染的控制權(quán)，它正常解析HTML頁(yè)面
解析遇到<script>標(biāo)簽，呈現(xiàn)引擎移交控制權(quán)給Javascript引擎（例如chrome的V8）
如果<script>標(biāo)簽引用了外部腳本那就先下載再執(zhí)行，否則直接執(zhí)行代碼
JavaScript引擎執(zhí)行完畢移交控制權(quán)給呈現(xiàn)引擎，呈現(xiàn)引擎繼續(xù)解析

加載外部腳本時(shí)，瀏覽器會(huì)暫停頁(yè)面渲染，等待腳本下載并執(zhí)行完成后，再繼續(xù)渲染。原因是 JavaScript 代碼可以修改 DOM，所以必須把控制權(quán)讓給它，否則會(huì)導(dǎo)致復(fù)雜的線程競(jìng)賽的問(wèn)題。

defer屬性

瀏覽器解析到包含defer屬性的<script>元素時(shí)，其運(yùn)行流程如下

瀏覽器的呈現(xiàn)引擎持有渲染的控制權(quán)，它正常解析HTML頁(yè)面
解析遇到包含defer屬性的<script>標(biāo)簽，繼續(xù)解析HTML，同時(shí)并行下載外鏈腳本
解析完成，文檔處于交互狀態(tài)時(shí)開(kāi)始解析處于deferred模式的腳本
腳本解析完畢后，將文檔狀態(tài)設(shè)置為完成，DOMContentLoaded事件隨之觸發(fā)

使用defer屬性時(shí)需要注意的點(diǎn)：

defer屬性下載的腳本文件在DOMContentLoaded事件觸發(fā)前執(zhí)行（即剛剛讀取完</html>標(biāo)簽）
defer屬性可以保證執(zhí)行順序就是它們?cè)陧?yè)面上出現(xiàn)的順序
對(duì)于內(nèi)置而不是加載外部腳本的script標(biāo)簽，以及動(dòng)態(tài)生成的script標(biāo)簽，defer屬性不起作用
使用defer加載的外部腳本不應(yīng)該使用document.write方法

async屬性

瀏覽器解析到包含async屬性的<script>元素時(shí)，其運(yùn)行流程如下

瀏覽器的呈現(xiàn)引擎持有渲染的控制權(quán)，它正常解析HTML頁(yè)面
解析遇到包含async屬性的<script>標(biāo)簽，繼續(xù)解析HTML，讓另一進(jìn)程同時(shí)并行下載外鏈腳本
腳本下載完成，瀏覽器暫停解析HTML，開(kāi)始執(zhí)行下載的腳本
腳本執(zhí)行完畢，瀏覽器恢復(fù)解析HTML

使用async屬性時(shí)需要注意的點(diǎn)：

async屬性可以保證腳本下載的同時(shí)，瀏覽器繼續(xù)渲染
async屬性無(wú)法保證腳本的執(zhí)行順序，哪個(gè)先下載結(jié)束就先執(zhí)行哪一個(gè)
包含async屬性的腳本不應(yīng)該使用document.write方法
如果同時(shí)使用async和defer屬性，后者不起作用，瀏覽器行為由async屬性決定

腳本的動(dòng)態(tài)加載

CSS阻塞JS加載

因?yàn)镴S腳本可能會(huì)引用DOM的樣式做計(jì)算，所以為了保證腳本計(jì)算的正確性，F(xiàn)irefox瀏覽器會(huì)等到腳本前面的所有樣式表，都下載并解析完，再執(zhí)行腳本；Webkit則是一旦發(fā)現(xiàn)腳本引用了樣式，就會(huì)暫停執(zhí)行腳本，等到樣式表下載并解析完，再恢復(fù)執(zhí)行。

此外，對(duì)于來(lái)自同一個(gè)域名的資源，比如腳本文件、樣式表文件、圖片文件等，瀏覽器一般有限制，同時(shí)最多下載6～20個(gè)資源，即最多同時(shí)打開(kāi)的 TCP 連接有限制，這是為了防止對(duì)服務(wù)器造成太大壓力。如果是來(lái)自不同域名的資源，就沒(méi)有這個(gè)限制。所以，通常把靜態(tài)文件放在不同的域名之下，以加快下載速度。

瀏覽器預(yù)解析

WebKit和Firefox都進(jìn)行了這項(xiàng)優(yōu)化。在執(zhí)行腳本時(shí)，其他線程會(huì)解析文檔的其余部分，找出并加載需要通過(guò)網(wǎng)絡(luò)加載的其他資源。通過(guò)這種方式，資源可以在并行連接上加載，從而提高總體速度。請(qǐng)注意，預(yù)解析器不會(huì)修改DOM樹(shù)，而是將這項(xiàng)工作交由主解析器處理；預(yù)解析器只會(huì)解析外部資源（例如外部腳本、樣式表和圖片）的引用。

Emmmm，到這里我們就了解了瀏覽器的呈現(xiàn)引擎只負(fù)責(zé)解析HTML和CSS，遇到JS時(shí)它會(huì)把控制權(quán)交給JS的引擎來(lái)解析和執(zhí)行。因?yàn)镴S引擎拿走了渲染的控制權(quán)，所以JS顯而易見(jiàn)會(huì)阻塞DOM的解析，為了讓JS不阻塞DOM的解析瀏覽器進(jìn)行了異步加載以及預(yù)解析等優(yōu)化。嗯，我們已經(jīng)了解了呈現(xiàn)引擎，接下來(lái)讓我們了解一下它的小伙伴Javascript引擎的工作流程吧~~

Javascript引擎的工作原理

首先，讓我們了解幾個(gè)概念，這會(huì)幫助我們更好的理解js代碼是如何執(zhí)行的。

Javascript引擎：從頭到尾負(fù)責(zé)整個(gè) JavaScript 程序的編譯及執(zhí)行過(guò)程。
編譯器：負(fù)責(zé)語(yǔ)法分析及代碼生成等臟活累活。具體工作如下圖所示：

了解基礎(chǔ)的概念后，現(xiàn)在讓我們一起來(lái)捋一遍Javascript引擎是如何工作的吧~~

一個(gè)Javascript引擎常駐于內(nèi)存中，它等待著宿主（例如瀏覽器）把Javascript代碼傳遞給它執(zhí)行。
當(dāng)宿主向它傳遞Javascript代碼時(shí)，它將Javascript源代碼丟給編譯器編譯成可執(zhí)行代碼。
然后引擎開(kāi)始執(zhí)行可執(zhí)行代碼，執(zhí)行過(guò)程如下：

將宿主（例如瀏覽器）發(fā)起的宏觀任務(wù)添加到宏觀任務(wù)隊(duì)列，如果JS引擎主線程的任務(wù)棧是空的，它會(huì)自動(dòng)從宏觀任務(wù)隊(duì)列拉取任務(wù)并執(zhí)行，在執(zhí)行過(guò)程中遇到setTimeout等異步代碼會(huì)先放到計(jì)時(shí)器模塊，計(jì)時(shí)器模塊計(jì)時(shí)結(jié)束后加入將其加入宏觀任務(wù)隊(duì)列；在執(zhí)行過(guò)程中遇到Promise等代碼會(huì)將其作為一個(gè)微觀任務(wù)加入到當(dāng)前宏觀任務(wù)末尾的微觀任務(wù)隊(duì)列中。當(dāng)前宏觀任務(wù)正常任務(wù)執(zhí)行完畢后會(huì)執(zhí)行當(dāng)前宏觀任務(wù)末尾的微觀任務(wù)隊(duì)列里面的任務(wù)，微觀任務(wù)隊(duì)列內(nèi)任務(wù)執(zhí)行完畢后該宏觀任務(wù)執(zhí)行完畢，主線程任務(wù)棧會(huì)拉取下一個(gè)宏觀任務(wù)。在此期間宿主環(huán)境隨時(shí)可能在宏觀任務(wù)隊(duì)列添加任務(wù)，JS引擎也隨時(shí)可能在當(dāng)前宏觀任務(wù)隊(duì)列末尾的微觀任務(wù)隊(duì)列添加微觀任務(wù)。如圖所示，形成了一個(gè)事件循環(huán)。

Emmmm，如果小伙伴們想進(jìn)一步的了解JS引擎的工作細(xì)節(jié)，我推薦以下文章和視頻來(lái)chrome的V8引擎是如何工作的。

V8 是怎么跑起來(lái)的 —— V8的JavaScript 執(zhí)行管道
從v8的內(nèi)存管理算法出發(fā)-教你如何管理內(nèi)存

感恩大家還能看到這里，文章可能還有一些地方不是特別完善，我會(huì)慢慢迭代完善的~~

結(jié)尾

最后談一點(diǎn)點(diǎn)自己的感想，我個(gè)人一直覺(jué)得學(xué)習(xí)原理很重要，最近學(xué)習(xí)了圈外解決問(wèn)題的課程就更加堅(jiān)定了我的信念。因?yàn)榻鉀Q問(wèn)題的第一步就是澄清問(wèn)題，而學(xué)習(xí)原理可以幫助我們更快的定位問(wèn)題所在從而解決問(wèn)題。愛(ài)因斯坦曾說(shuō)，如果給我一個(gè)小時(shí)解答一道決定我生死的問(wèn)題，我會(huì)花55分鐘來(lái)弄清楚這道題目到底是在問(wèn)什么。一旦清楚它到底在問(wèn)什么，剩下的5分鐘足夠回答這個(gè)問(wèn)題。在實(shí)際的工作中也確實(shí)如此，一旦程序出了問(wèn)題，我們往往花大量的時(shí)間在調(diào)試上，而一旦找到了問(wèn)題解決起來(lái)就很快了。

因?yàn)榍岸斯こ處煷蚪坏雷疃嗟木褪菫g覽器，了解瀏覽器的工作原理不管是對(duì)寫代碼還是對(duì)項(xiàng)目的性能優(yōu)化都會(huì)有所幫助，所以我斷斷續(xù)續(xù)看了許多關(guān)于瀏覽器工作原理的文章及書(shū)籍小冊(cè)，終于覺(jué)得是時(shí)候整理輸出一些東西，希望可以加深自己的理解，更希望可以對(duì)小伙伴們有所幫助。如果文章中有什么表述不對(duì)的地方，歡迎大家在評(píng)論區(qū)指正。最后感謝閱讀這篇文章的小伙伴們。