摘要：書接上文瀏覽器內(nèi)核之資源加載與網(wǎng)絡(luò)棧本文介紹的模型之后，深入的核心部分，剖析的解釋器是如何將從網(wǎng)絡(luò)或者本地文件獲取的字節(jié)流轉(zhuǎn)成內(nèi)部表示的結(jié)構(gòu)樹。事件處理最重要就是事件捕獲和事件冒泡這兩種機(jī)制。

微信公眾號：愛寫bugger的阿拉斯加
如有問題或建議，請后臺留言，我會盡力解決你的問題。

此文章是我最近在看的【W(wǎng)ebKit 技術(shù)內(nèi)幕】一書的一些理解和做的筆記。
而【W(wǎng)ebKit 技術(shù)內(nèi)幕】是基于 WebKit 的 Chromium 項目的講解。

書接上文 瀏覽器內(nèi)核之資源加載與網(wǎng)絡(luò)棧

本文介紹 W3C 的 DOM 模型之后，深入 WebKit 的核心部分，剖析 WebKit 的 HTML 解釋器是如何將從網(wǎng)絡(luò)或者本地文件獲取的字節(jié)流轉(zhuǎn)成內(nèi)部表示的結(jié)構(gòu) --- DOM 樹。

DOM （Document Object Model）的全稱是文檔對象模型，它可以以一種獨立于平臺和語言的方式訪問和修改一個文檔的內(nèi)容和結(jié)構(gòu)。這里的文檔可以是 HTML 文檔、XML 文檔或者 XHTML 文檔。DOM 以面向?qū)ο蟮姆绞絹砻枋鑫臋n，在 HTML 文檔中，Web 開發(fā)者可以使用 JavaScript 語言來訪問、創(chuàng)建、刪除或者修改 DOM 結(jié)構(gòu)，其主要目的是動態(tài)改變 HTML 文檔的結(jié)構(gòu)。

使用 DOM 表示的文檔被描述成一個樹形結(jié)構(gòu)，使用 DOM 的接口可以對 DOM 樹結(jié)構(gòu)進(jìn)行操作。

每一級的版本都對以前的版本進(jìn)行了補充并伴隨新功能的加入，每個版本都對 DOM 的不同部分進(jìn)行了定義。

DOM 結(jié)構(gòu)構(gòu)成的基本要素是 “節(jié)點” ，而文檔的 DOM 結(jié)構(gòu)就是由層次化的節(jié)點組成。在 DOM 模型中，節(jié)點的概念很寬泛，整個文檔（Document ）就是一個節(jié)點，稱為文檔節(jié)點。HTML 中的標(biāo)記（Tag）也是一種節(jié)點，稱為元素（Element）節(jié)點。還有一些其他類型的節(jié)點，例如 屬性節(jié)點（標(biāo)記的屬性）、Entity 節(jié)點、ProcessingIntruction 節(jié)點、CDataSection 節(jié)點、注釋（Comment）節(jié)點等。

眾多的節(jié)點按照層次組織構(gòu)成一個 DOM 樹結(jié)構(gòu)。
如圖 5 - 4

DOM 樹的根就是 HTMLDocument , HTML 網(wǎng)頁中的標(biāo)簽則被轉(zhuǎn)換成一個個的元素節(jié)點。同數(shù)據(jù)結(jié)構(gòu)中的樹形結(jié)構(gòu)一樣，這些節(jié)點之間也存在父子或兄弟關(guān)系。

HTML 解釋器的工作就是將網(wǎng)絡(luò)或者本地磁盤獲取的 HTML 網(wǎng)頁和資源從字節(jié)流解釋成 DOM 樹結(jié)構(gòu)。這一過程大致可以理解成圖 5-5所述的步驟。

這過程中，WebKit 內(nèi)部對網(wǎng)頁內(nèi)容在各個階段的結(jié)構(gòu)表示。 WebKit 中這一過程如下：首先是字節(jié)流，經(jīng)過解碼之后是字符流，然后通過詞法分析器會被解釋成詞語（Tokens），之后經(jīng)過語法分析器構(gòu)建成節(jié)點，最后這些節(jié)點被組建成一棵 DOM 樹。

在進(jìn)行詞法分析之前，解釋器首先要做的事情就是檢查該網(wǎng)頁內(nèi)容使用的編碼格式，以便后面使用合適的解碼器。如果解釋器在 HTML 網(wǎng)頁中找到了設(shè)置的編碼格式， WebKit 會使用相應(yīng)的解碼器來將字節(jié)流轉(zhuǎn)換成特定格式的字符串。如果沒有特殊格式，詞法分析器 HTMLTokenizer 類可以直接進(jìn)行詞法分析。

詞法分析的工作都是由 HTMLTokenizer 來完成 ，簡單來說，它就是一個狀態(tài)機(jī)---輸入的是字符串，輸出的是一個個詞語。因為字節(jié)流可能是分段的，所以輸入的字符串可能也是分段的，但是這對詞法分析器來說沒有什么特別之處，它會自己維護(hù)內(nèi)部的狀態(tài)信息。

詞法分析器的主要接口是 “nextToken” 函數(shù)，調(diào)用者只需要關(guān)鍵字符串傳入，然后就會得到一個詞語，并對傳入的字符串設(shè)置相應(yīng)的信息，表示當(dāng)前處理完的位置，如此循環(huán)，如果詞法分析器遇到錯誤，則報告狀態(tài)錯誤碼，主要邏輯在圖 5-8 中給予了描述。

對于 “nextToken” 函數(shù)的調(diào)用者而言，它首先設(shè)置輸入需要解釋的字符串，然后循環(huán)調(diào)用 NextToken 函數(shù),直到處理結(jié)束。 “nextToken” 方法每次輸出一個詞語，同時會標(biāo)記輸入的字符串，表明哪些字符已經(jīng)被處理過了。因此，每次詞法分析器都會根據(jù)上次設(shè)置的內(nèi)部狀態(tài)和上次處理之后的字符串來生成一個新的詞語。 “nextToken” 函數(shù)內(nèi)部使用了超過 70 種狀態(tài)，圖中只顯示了 3 種狀態(tài)。對于每個不同的狀態(tài)，都有相應(yīng)的處理邏輯。

當(dāng)詞語生成之后，WebKit 需要使用 XSSAuditor 來驗證詞語流（Token Stream）。XSS 指的是 Cross Site Security , 主要是針對安全方面的考慮。

根據(jù) XSS 的安全機(jī)制，對于解析出來的這些詞語，可能會阻礙某些內(nèi)容的進(jìn)一步執(zhí)行，所以 XSSAuditor 類主要負(fù)責(zé)過濾這些被阻止的內(nèi)容，只有通過的詞語才會作后面的處理。

經(jīng)過詞法分析器解釋之后的詞語隨之被 XSSAuditor 過濾并且在沒有被阻止之后，將被 WebKit 用來構(gòu)建 DOM 節(jié)點。從詞語到構(gòu)建節(jié)點的步驟是由 HTMLDocumentParser 類調(diào)用 HTMLTreeBuilder 類的 “constructTree” 函數(shù)來實現(xiàn)。

從節(jié)點到構(gòu)建 DOM 樹，包括為樹中的元素節(jié)點創(chuàng)建屬性節(jié)點等工作由 HTMLConstructionSite 類來完成。正如前面介紹的，該類包含一個 DOM 樹的根節(jié)點 ——HTMLDocument 對象，其他的元素節(jié)點都是它的后代。

因為 HTML 文檔的 Tag 標(biāo)簽是有開始和結(jié)束標(biāo)記的，所以構(gòu)建這一過程可以使用棧結(jié)構(gòu)來幫忙。HTMLConstructionSite 類中包含一個 “HTMLElementStack” 變量，它是一個保存元素節(jié)點的棧，其中的元素節(jié)點是當(dāng)前有開始標(biāo)記但是還沒有結(jié)束標(biāo)記的元素節(jié)點。想象一下 HTML 文檔的特點，例如一個片段 “

同 DOM 標(biāo)準(zhǔn)一樣，一切的基礎(chǔ)都是 Node 類。在 WebKit 中， DOM 中的接口 Interface 對應(yīng)于 C++ 的類，Node 類是其他類的基類，圖 5-10 顯示了 DOM 的主要相關(guān)節(jié)點類。圖中的 Node 類實際上繼承自 EventTarget 類，它表明 Node 類能夠接受事件，這個會在 DOM 事件處理中介紹。Node 類還繼承自另外一個基類 ——ScriptWrappable，這個跟 JavaScript 引擎相關(guān)。

Node 的子類就是 DOM 中定義的同名接口，元素類，文檔類和屬性類均繼承自一個抽象出來的 ContainerNode 類，表明它們能夠包含其他的節(jié)點對象?；氐?HTML 文檔來說，元素和文檔對應(yīng)的類注是 HTMLElement 類和 HTMLDocument 類，實際上 HTML 規(guī)范還包含眾多的 HTMLElement 子類，用于表示 HTML 語法中眾多的標(biāo)簽。

上面介紹了 Frame 、Document 等 WebKit 中的基礎(chǔ)類，這些都是網(wǎng)頁內(nèi)部的概念，實際上，WebKit 提供了更高層次的設(shè)施，用于表示整個網(wǎng)頁的一些類，WebKit 中的 接口部分 就是基于它們來提供的，表示網(wǎng)頁的類既提供了構(gòu)建 DOM 樹等操作，同時也提供了接口用于布局。渲染等操作。

在 Renderer 進(jìn)程中有一個線程，該線程用來處理 HTML 文檔的解釋任務(wù)，在 HTML 解釋器的步驟中，WebKit 的 Chromium 移植跟其他的 WebKit 移植也存在不同之處。

線程化的解釋器就是利用多帶帶的線程來解釋 HTML 文檔。因為在WebKit 中，網(wǎng)絡(luò)資源的字節(jié)流自 IO 線程傳遞給渲染線程之后，后面的解釋、布局和渲染等工作基本上就是工作在該線程，也就是渲染線程完成的（這不是絕對的）。因為 DOM 樹只能在渲染線程上創(chuàng)建和訪問，這也就是說構(gòu)建 DOM 樹的過程只能在渲染線程中進(jìn)行。但是，從字符到詞語這個階段可以交給多帶帶的線程來做，Chromium 瀏覽器使用的就是這個思想。

具體的實現(xiàn)過程：

字符串 （傳給）=> HTMLDocumentParser類 （創(chuàng)建一個新的對象）=> BackgroundHTMLParser 來負(fù)責(zé)處理 （交給）=> 前一步創(chuàng)建的對象

WebKit 會檢查是否需要創(chuàng)建用于解釋字符串的線程 HTMLParserThread 。如果該線程已存在，WebKit 就將剛剛的任務(wù)傳遞給這一新線程， 圖 5-13 描述了這一過程。

在 HTMLParserThread 線程中，WebKit 所做的事情包括將字符串解釋成一個個詞語，然后使用之前提到的 XSSAuditor 進(jìn)行安全檢查。這是在一個新的線程中執(zhí)行。主要區(qū)別在于解釋成詞語之后，WebKit 會分批次地將結(jié)果詞語傳遞給渲染線程。

在 HTML 解釋器的工作過程中，可能會有 JavaScript 代碼（全局作用域的代碼）需要執(zhí)行，它發(fā)生在將字符串解釋成詞語之后、創(chuàng)建各種節(jié)點的時候。這也是全局執(zhí)行的 JavaScript 代碼不能訪問 DOM 樹的原因——因為 DOM 樹還沒有被創(chuàng)建完。

所以建議 JavaScript 的使用如下：

1、將 “script” 元素加上 “async” 屬性，表明這是一個可以異步執(zhí)行的 JavaScript 代碼。

2、將 “script” 元素放在 “body” 元素的最后，這樣它不會阻礙其他資源的并發(fā)下載。

但是不這樣做的時候，WebKit 使用預(yù)掃描和預(yù)加載機(jī)制來實現(xiàn)資源的并發(fā)下載而不被 JavaScript 的執(zhí)行所阻礙。

具體做法是：當(dāng)遇到需要執(zhí)行 JavaScript 代碼的時候，WebKit 先暫停當(dāng)前 JavaScript 代碼的執(zhí)行，使用預(yù)先掃描器 HTMLPreloadScanner 類來掃描后面的詞語。如果 WebKit 發(fā)現(xiàn)它們需要使用其他資源，那么使用預(yù)資源加載器 HTMLPreloadScanner 類來發(fā)送請求，在這之后，才執(zhí)行 JavaScript代碼。預(yù)先掃描器本身并不創(chuàng)建節(jié)點對象，也不會構(gòu)建 DOM 樹，所以速度比較快。

當(dāng) DOM 樹構(gòu)建完之后，WebKit 觸發(fā) “DOMContentLoaded” 事件，注冊在該事件上的 JavaScript 函數(shù)會被調(diào)用。當(dāng)所在資源都被加載完之后，WebKit 觸發(fā) “onload” 事件。

WebKit 將 DOM 樹創(chuàng)建過程中需要執(zhí)行的 JavaScript 代碼交由 HTMLScriptRunner 類來負(fù)責(zé)。工作方式很簡單，就是利用 JavaScript 引擎來執(zhí)行 Node 節(jié)點中包含的代碼，具體可以參考 “HTMLScriptRunner::executeParsingBlockingScript” 方法。

事件在工作過程中使用兩個主體，第一個是事件（event），第二個是事件目標(biāo)（EventTarget）。WebKit 中用 EventTarget 類來表示 DOM 規(guī)范中 Events 部分定義的事件目標(biāo)。

每個 事件都有屬性來標(biāo)記該事件的事件目標(biāo)。當(dāng)事件到達(dá)事件目標(biāo)（如一個元素節(jié)點）的時候，在這個目標(biāo)上注冊的監(jiān)聽者（Event Listeners）都會有觸發(fā)調(diào)用，而這些監(jiān)聽者的調(diào)用順序不是固定的，所以不能依賴監(jiān)聽者注冊的順序來決定你的代碼邏輯。

圖 5-17 是 EventTarget 接口的定義。圖中的接口是用來注冊和移除監(jiān)聽者的。

事件處理最重要就是事件捕獲（Event capture）和事件冒泡（Event bubbling）這兩種機(jī)制。圖 5-18 是事件捕獲和事件冒泡的過程。

當(dāng)渲染引擎接收到一個事件的時候，它會通過 HitTest（WebKit 中的一種檢查觸發(fā)gkwrd哪個區(qū)域的算法）檢查哪個元素是直接的事件目標(biāo)。在圖 5-18 中，以 “img” 為例，假設(shè)它是事件的直接目標(biāo)，這樣，事件會經(jīng)過自頂向下和自底向上的兩個過程。

事件的捕獲是自頂向下，事件先是到 document 節(jié)點，然后一路到達(dá)目標(biāo)節(jié)點。在圖 5-18 中，順序就是 “#document” -> "HTML" -> "body" -> "img" 這樣一個順序。事件可以在這一傳遞過程中被捕獲，只需要在注冊監(jiān)聽者的時候設(shè)置相應(yīng)參數(shù)即可。默認(rèn)情況下，其他節(jié)點不捕獲這樣的事件。如果網(wǎng)頁注冊了這樣的監(jiān)聽者，那么監(jiān)聽者的回調(diào)函數(shù)會被調(diào)用，函數(shù)可以通過事件的 “stopPropagation” 函數(shù)來阻止事件向下傳遞。

事件的冒泡過程是從下向上的順序，它的默認(rèn)行為是不冒泡，但是是事件包含一個是否冒泡的屬性。當(dāng)這一屬性為真的時候，渲染引擎會將該事件首先傳遞給事件的目標(biāo)節(jié)點的父親，然后是父親的父親，以此類推。同捕獲動作一樣，這此監(jiān)聽函數(shù)也可以使用 “stopPropagation” 函數(shù)來阻止事件向上傳遞。

DOM 的事件分為很多種，與用戶相關(guān)的只是其中的一種，稱為 UIEvent ，其他的包括 CustomEvent、MutationEvent 等。UIEvent 又可以分為很多種，包括但是不限于 FocusEvent、MouseEvent、KeyboardEvent、Composition 等。

基于 WebKit 的瀏覽器事件處理過程，首先是做 HitTest ,查找事件發(fā)生處的元素，檢查該元素有無監(jiān)聽者。如果網(wǎng)頁的相關(guān)節(jié)點注冊了事件的監(jiān)聽者，那么瀏覽器會把事件派發(fā)給 WebKit 內(nèi)核來處理。同時，瀏覽器也可能需要理解和處理這樣的事件。這主要是因為，有些事件瀏覽器必須響應(yīng)從而對網(wǎng)頁作默認(rèn)處理。

EventHandler 類是處理事件的核心類，它除了需要將各種事件傳給 JavaScript 引擎以調(diào)用響應(yīng)的監(jiān)聽者之外，它還會識別鼠標(biāo)事件，來觸發(fā)調(diào)用右鍵菜單、拖放效果等與事件密切相關(guān)的工作，而且 EventHandler 類還支持網(wǎng)頁的多框結(jié)構(gòu)。EventHandler 類的接口比較容易理解，但是它的處理邏輯極其復(fù)雜。

圖 5-20 簡單描述了鼠標(biāo)事件的調(diào)用過程，這一過程本身是比較簡單的，復(fù)雜之處在于 WebKit 的 EventHandler 類。

WebKit 中還有些跟事件處理相關(guān)的其他類，例如 EventPathWalker、EventDispatcher 類等，這些類都是為了解決事件在 DOM 樹中傳遞的問題。

影子 DOM 是一個新東西，主要解決了一個文檔中可能需要大量交互的多個 DOM 樹建立和維護(hù)各自的功能邊界的問題。

當(dāng)開發(fā)這樣一個用戶界面的控件——這個控件可能由一些 HTML 的標(biāo)簽元素組成，這些元素可以組成一顆 DOM 樹的子樹。這樣一個 HTML 控件可以被到處使用，但是問題隨之而來，那就是每個使用控件的地方都會知道這個子樹的結(jié)構(gòu)。

當(dāng)網(wǎng)頁的開發(fā)者需要訪問網(wǎng)頁 DOM 樹的時候，這些控件內(nèi)部的 DOM 子樹都會暴露出來，這些暴露的節(jié)點不僅可能給 DOM 樹的遍歷帶來很多麻煩，而且也可能給 CSS 的樣式選擇帶來問題，因為選擇器無意中可能會改變這些內(nèi)部節(jié)點的樣式，從而導(dǎo)致很奇怪的控件界面。

如何將內(nèi)部的節(jié)點信息封裝起來，就像 C++ 語言的類一樣，同時又能夠?qū)⑦@些節(jié)點渲染出來呢 ？ W3C 工作組提出的影子 DOM 概念。影子 DOM 的規(guī)范草案能夠使得一些 DOM 節(jié)點在特定范圍內(nèi)可見，而在網(wǎng)頁的 DOM 樹中卻不可見，但是網(wǎng)頁渲染的結(jié)果中包含了這些節(jié)點，這就使得封裝變得容易很多。

圖 5-21 描述了 HTML 文檔對應(yīng)的 DOM 樹和 “div” 元素包含的一個影子 DOM 子樹。當(dāng)使用 JavaScript 代碼訪問 HTML 文檔的 DOM 樹的時候，通常的接口是不能直接訪問到影子 DOM 子樹中的節(jié)點的，JavaScript 代碼只能通過特殊的接口方式。

HTML5 支持了很多新的特性，例如對視頻、音頻的支持，讀者會發(fā)現(xiàn)這些元素其實是由很復(fù)雜的控制界面組成，這些界面也是使用 HTML 元素編寫，但是在 DOM 樹中，你無法找到相應(yīng)的節(jié)點，這其實也是使用了影子 DOM 的思想。

因為影子 DOM 的子樹在整個網(wǎng)頁的 DOM 樹中不可見，那么事件是如何處理的呢 ？事件中需要包含事件目標(biāo)，這個目標(biāo)當(dāng)然不能是不可見的 DOM 節(jié)點，所以事件目標(biāo)其實就是包含影子 DOM 子樹的節(jié)點對象。事件捕獲的邏輯沒有發(fā)生變化，在影子 DOM 子樹內(nèi)也會繼續(xù)傳遞。當(dāng)影子 DOM 子樹中的事件向上冒泡的時候， WebKit 會同時向整個文檔的 DOM 上傳遞該事件，以避免一些很奇怪的行為。

WebKit 已經(jīng)支持影子 DOM 的規(guī)范草案，雖然還存在一些問題。支持影子 DOM 的相關(guān)類在目錄 “Source/core/dom/shadow” 下，里面的主要類是 ShadowRoot ，表示的是影子 DOM 的根節(jié)點。ShadowRoot 類繼承自 DocumentFragment 類，所以它同樣有 Node 節(jié)點的屬性和方法，因而在影子 DOM 樹的內(nèi)部，遍歷樹沒有什么特別不同的地方。

當(dāng)遍歷 HTML 文檔對應(yīng) DOM 樹的時候，WebKit 需要做特別的判斷，所以讀者會發(fā)現(xiàn)在 WebKit 的 Node 類實現(xiàn)中存在大量的條件語句，用來檢查當(dāng)前節(jié)點是否是 ShadowRoot 對象，如果是該類的對象，把它作為不同 DOM 樹之間的邊界。有時候 WebKit 還需要對 ShadowRoot 對象作出特別處理，比如某些情況會略過它的子樹，同樣的，在事件處理的支持類 EventPathWalker 和 EventRetargeter 中，也需要做一些特別的處理邏輯，原理就是上面所述，細(xì)節(jié)不再介紹。

示例代碼 5-2 給出了一個簡單的使用 webkitCreateShadowRoot 接口來創(chuàng)建影子 DOM 子樹的例子。網(wǎng)頁只包含了一個 “div” 元素，JavaScript 代碼使用該元素創(chuàng)建了一個影子 DOM 子樹的根節(jié)點，然后該根節(jié)點下加入了兩個子女，第一個是圖片元素，第二個是 “div” 元素，該元素內(nèi)部包含了一些文本。

讀者可以打開 Chrom 瀏覽器的開發(fā)者工具，然后打開控制臺，在其中輸入 “document.firstChild.firstChild.nextElementSibling.firstElementChild.firstElementChild” 后會發(fā)現(xiàn)結(jié)果是空的，根據(jù)對應(yīng)關(guān)系 “#document-> html -> head -> body -> div -> null”,雖然網(wǎng)頁中沒有 ‘head’ 元素，但是 DOM 樹仍然會創(chuàng)建該節(jié)點。同時讀者會發(fā)現(xiàn) “div” 元素沒有子女，影子 DOM 子樹真的被隱藏起來了，成為真正的影子。

希望本文對你有點幫助。

下期分享 第六章 CSS 解釋器和樣式布局 敬請期待。

對 全棧開發(fā) 有興趣的朋友可以掃下方二維碼關(guān)注我的公眾號 —— 愛寫bugger的阿拉斯加

分享 web 開發(fā)相關(guān)的技術(shù)文章，熱點資源，全棧程序員的成長之路。