瀏覽器的工作原理：新式網絡瀏覽器幕後揭秘

1.1我們要討論的瀏覽器

目前使用的主流瀏覽器有五個：Internet Explorer、Firefox、Safari、Chrome 瀏覽器和 Opera。本文中以開放源代碼瀏覽器為例，即 Firefox、Chrome 瀏覽器和 Safari（部分開源）。根據StatCounter 瀏覽器統計數據，目前（2011 年 8 月）Firefox、Safari 和 Chrome 瀏覽器的總市場占有率將近 60%。由此可見，如今開放源代碼瀏覽器在瀏覽器市場中占據了非常堅實的部分。

1.2瀏覽器的主要功能

瀏覽器的主要功能就是向服務器發出請求，在瀏覽器窗口中展示您選擇的網絡資源。這裏所說的資源一般是指 HTML 文檔，也可以是 PDF、圖片或其他的類型。資源的位置由用戶使用 URI（統一資源標示符）指定。

瀏覽器解釋並顯示 HTML 文件的方式是在 HTML 和 CSS 規範中指定的。這些規範由網絡標準化組織W3C（萬維網聯盟）進行維護。 
多年以來，各瀏覽器都沒有完全遵從這些規範，同時還在開發自己獨有的擴展程序，這給網絡開發人員帶來了嚴重的兼容性問題。如今，大多數的瀏覽器都是或多或少地遵從規範。

瀏覽器的用戶界麵有很多彼此相同的元素，其中包括：

• 用來輸入 URI 的地址欄
• 前進和後退按鈕
• 書簽設置選項
• 用於刷新和停止加載當前文檔的刷新和停止按鈕
• 用於返回主頁的主頁按鈕

奇怪的是，瀏覽器的用戶界麵並沒有任何正式的規範，這是多年來的最佳實踐自然發展以及彼此之間相互模仿的結果。HTML5 也沒有定義瀏覽器必須具有的用戶界麵元素，但列出了一些通用的元素，例如地址欄、狀態欄和工具欄等。當然，各瀏覽器也可以有自己獨特的功能，比如 Firefox 的下載管理器。

1.3瀏覽器的高層結構

瀏覽器的主要組件為 (1.1)：

1. 用戶界麵 - 包括地址欄、前進/後退按鈕、書簽菜單等。除了瀏覽器主窗口顯示的您請求的頁麵外，其他顯示的各個部分都屬於用戶界麵。
2. 瀏覽器引擎 - 在用戶界麵和呈現引擎之間傳送指令。
3. 呈現引擎 - 負責顯示請求的內容。如果請求的內容是 HTML，它就負責解析 HTML 和 CSS 內容，並將解析後的內容顯示在屏幕上。
4. 網絡 - 用於網絡調用，比如 HTTP 請求。其接口與平台無關，並為所有平台提供底層實現。
5. 用戶界麵後端 - 用於繪製基本的窗口小部件，比如組合框和窗口。其公開了與平台無關的通用接口，而在底層使用操作係統的用戶界麵方法。
6. JavaScript 解釋器。用於解析和執行 JavaScript 代碼。
7. 數據存儲。這是持久層。瀏覽器需要在硬盤上保存各種數據，例如 Cookie。新的 HTML 規範 (HTML5) 定義了“網絡數據庫”，這是一個完整（但是輕便）的瀏覽器內數據庫。

圖：瀏覽器的主要組件。

值得注意的是，和大多數瀏覽器不同，Chrome 瀏覽器的每個標簽頁都分別對應一個呈現引擎實例。每個標簽頁都是一個獨立的進程。

Chapter 2

呈現引擎

呈現引擎的作用嘛...當然就是“呈現”了，也就是在瀏覽器的屏幕上顯示請求的內容。

默認情況下，呈現引擎可顯示 HTML 和 XML 文檔與圖片。通過插件（或瀏覽器擴展程序），還可以顯示其它類型的內容；例如，使用 PDF 查看器插件就能顯示 PDF 文檔。但是在本章中，我們將集中介紹其主要用途：顯示使用 CSS 格式化的 HTML 內容和圖片。

2.1呈現引擎

本文所討論的瀏覽器（Firefox、Chrome 瀏覽器和 Safari）是基於兩種呈現引擎構建的。Firefox 使用的是 Gecko，這是 Mozilla 公司“自製”的呈現引擎。而 Safari 和 Chrome 瀏覽器使用的都是 Webkit。

Webkit 是一種開放源代碼呈現引擎，起初用於 Linux 平台，隨後由 Apple 公司進行修改，從而支持蘋果機和 Windows。有關詳情，請參閱 webkit.org。

2.2主流程

呈現引擎一開始會從網絡層獲取請求文檔的內容，內容的大小一般限製在 8000 個塊以內。

然後進行如下所示的基本流程：

圖：呈現引擎的基本流程。

呈現引擎將開始解析 HTML 文檔，並將各標記逐個轉化成“內容樹”上的 DOM 節點。同時也會解析外部 CSS 文件以及樣式元素中的樣式數據。HTML 中這些帶有視覺指令的樣式信息將用於創建另一個樹結構：呈現樹。

呈現樹包含多個帶有視覺屬性（如顏色和尺寸）的矩形。這些矩形的排列順序就是它們將在屏幕上顯示的順序。

呈現樹構建完畢之後，進入“布局”處理階段，也就是為每個節點分配一個應出現在屏幕上的確切坐標。下一個階段是繪製 - 呈現引擎會遍曆呈現樹，由用戶界麵後端層將每個節點繪製出來。

需要著重指出的是，這是一個漸進的過程。為達到更好的用戶體驗，呈現引擎會力求盡快將內容顯示在屏幕上。它不必等到整個 HTML 文檔解析完畢之後，就會開始構建呈現樹和設置布局。在不斷接收和處理來自網絡的其餘內容的同時，呈現引擎會將部分內容解析並顯示出來。

2.3主流程示例

圖：Webkit 主流程圖：Mozilla 的 Gecko 呈現引擎主流程 (3.6)

從圖 3 和圖 4 可以看出，雖然 Webkit 和 Gecko 使用的術語略有不同，但整體流程是基本相同的。

Gecko 將視覺格式化元素組成的樹稱為“框架樹”。每個元素都是一個框架。Webkit 使用的術語是“呈現樹”，它由“呈現對象”組成。對於元素的放置，Webkit 使用的術語是“布局”，而 Gecko 稱之為“重排”。對於連接 DOM 節點和可視化信息從而創建呈現樹的過程，Webkit 使用的術語是“附加”。有一個細微的非語義差別，就是 Gecko 在 HTML 與 DOM 樹之間還有一個稱為“內容槽”的層，用於生成 DOM 元素。我們會逐一論述流程中的每一部分：

Chapter 3

3.1解析 - 綜述

解析是呈現引擎中非常重要的一個環節，因此我們要更深入地講解。首先，來介紹一下解析。

解析文檔是指將文檔轉化成為有意義的結構，也就是可讓代碼理解和使用的結構。解析得到的結果通常是代表了文檔結構的節點樹，它稱作解析樹或者語法樹。

示例 - 解析 2 + 3 - 1 這個表達式，會返回下麵的樹：

圖：數學表達式樹節點

3.1.1語法

解析是以文檔所遵循的語法規則（編寫文檔所用的語言或格式）為基礎的。所有可以解析的格式都必須對應確定的語法（由詞匯和語法規則構成）。這稱為與上下文無關的語法。人類語言並不屬於這樣的語言，因此無法用常規的解析技術進行解析。

3.1.2解析器和詞法分析器的組合

解析的過程可以分成兩個子過程：詞法分析和語法分析。

詞法分析是將輸入內容分割成大量標記的過程。標記是語言中的詞匯，即構成內容的單位。在人類語言中，它相當於語言字典中的單詞。

語法分析是應用語言的語法規則的過程。

解析器通常將解析工作分給以下兩個組件來處理：詞法分析器（有時也稱為標記生成器），負責將輸入內容分解成一個個有效標記；而解析器負責根據語言的語法規則分析文檔的結構，從而構建解析樹。詞法分析器知道如何將無關的字符（比如空格和換行符）分離出來。

圖：從源文檔到解析樹

解析是一個迭代的過程。通常，解析器會向詞法分析器請求一個新標記，並嚐試將其與某條語法規則進行匹配。如果發現了匹配規則，解析器會將一個對應於該標記的節點添加到解析樹中，然後繼續請求下一個標記。

如果沒有規則可以匹配，解析器就會將標記存儲到內部，並繼續請求標記，直至找到可與所有內部存儲的標記匹配的規則。如果找不到任何匹配規則，解析器就會引發一個異常。這意味著文檔無效，包含語法錯誤。

3.1.3翻譯

很多時候，解析樹還不是最終產品。解析通常是在翻譯過程中使用的，而翻譯是指將輸入文檔轉換成另一種格式。編譯就是這樣一個例子。編譯器可將源代碼編譯成機器代碼，具體過程是首先將源代碼解析成解析樹，然後將解析樹翻譯成機器代碼文檔。

圖：編譯流程

3.1.4解析示例

在圖 5 中，我們通過一個數學表達式建立了解析樹。現在，讓我們試著定義一個簡單的數學語言，用來演示解析的過程。

詞匯：我們用的語言可包含整數、加號和減號。

語法：

1. 構成語言的語法單位是表達式、項和運算符。
2. 我們用的語言可以包含任意數量的表達式。
3. 表達式的定義是：一個“項”接一個“運算符”，然後再接一個“項”。
4. 運算符是加號或減號。
5. 項是一個整數或一個表達式。

讓我們分析一下 2 + 3 - 1。 
匹配語法規則的第一個子串是 2，而根據第 5 條語法規則，這是一個項。匹配語法規則的第二個子串是 2 + 3，而根據第 3 條規則（一個項接一個運算符，然後再接一個項），這是一個表達式。下一個匹配項已經到了輸入的結束。2 + 3 - 1 是一個表達式，因為我們已經知道 2 + 3 是一個項，這樣就符合“一個項接一個運算符，然後再接一個項”的規則。2 + + 不與任何規則匹配，因此是無效的輸入。

3.1.5詞匯和語法的正式定義

詞匯通常用正則表達式表示。

例如，我們的示例語言可以定義如下：

INTEGER :0|[1-9][0-9]*
PLUS : +
MINUS: -

正如您所看到的，這裏用正則表達式給出了整數的定義。

語法通常使用一種稱為 BNF 的格式來定義。我們的示例語言可以定義如下：

expression :=  term  operation  term
operation :=  PLUS | MINUS
term := INTEGER | expression

之前我們說過，如果語言的語法是與上下文無關的語法，就可以由常規解析器進行解析。與上下文無關的語法的直觀定義就是可以完全用 BNF 格式表達的語法。有關正式定義，請參閱關於與上下文無關的語法的維基百科文章。

3.1.6解析器類型

有兩種基本類型的解析器：自上而下解析器和自下而上解析器。直觀地來說，自上而下的解析器從語法的高層結構出發，嚐試從中找到匹配的結構。而自下而上的解析器從低層規則出發，將輸入內容逐步轉化為語法規則，直至滿足高層規則。

讓我們來看看這兩種解析器會如何解析我們的示例：

自上而下的解析器會從高層的規則開始：首先將 2 + 3 標識為一個表達式，然後將 2 + 3 - 1 標識為一個表達式（標識表達式的過程涉及到匹配其他規則，但是起點是最高級別的規則）。

自下而上的解析器將掃描輸入內容，找到匹配的規則後，將匹配的輸入內容替換成規則。如此繼續替換，直到輸入內容的結尾。部分匹配的表達式保存在解析器的堆棧中。

堆棧	輸入
	2 + 3 - 1
項	+ 3 - 1
項運算	3 - 1
表達式	- 1
表達式運算符	1
表達式

這種自下而上的解析器稱為移位歸約解析器，因為輸入在向右移位（設想有一個指針從輸入內容的開頭移動到結尾），並且逐漸歸約到語法規則上。

3.1.7自動生成解析器

有一些工具可以幫助您生成解析器，它們稱為解析器生成器。您隻要向其提供您所用語言的語法（詞匯和語法規則），它就會生成相應的解析器。創建解析器需要對解析有深刻理解，而人工創建優化的解析器並不是一件容易的事情，所以解析器生成器是非常實用的。

Webkit 使用了兩種非常有名的解析器生成器：用於創建詞法分析器的 Flex 以及用於創建解析器的Bison（您也可能遇到 Lex 和 Yacc 這樣的別名）。Flex 的輸入是包含標記的正則表達式定義的文件。Bison 的輸入是采用 BNF 格式的語言語法規則。

3.2HTML 解析器

HTML 解析器的任務是將 HTML 標記解析成解析樹。

3.2.1HTML 語法定義

HTML 的詞匯和語法在 W3C 組織創建的規範中進行了定義。當前的版本是 HTML4，HTML5 正在處理過程中。

3.2.2非與上下文無關的語法

正如我們在解析過程的簡介中已經了解到的，語法可以用 BNF 等格式進行正式定義。

很遺憾，所有的常規解析器都不適用於 HTML（我並不是開玩笑，它們可以用於解析 CSS 和 JavaScript）。HTML 並不能很容易地用解析器所需的與上下文無關的語法來定義。

有一種可以定義 HTML 的正規格式：DTD（Document Type Definition，文檔類型定義），但它不是與上下文無關的語法。

這初看起來很奇怪：HTML 和 XML 非常相似。有很多 XML 解析器可以使用。HTML 存在一個 XML 變體 (XHTML)，那麼有什麼大的區別呢？

區別在於 HTML 的處理更為“寬容”，它允許您省略某些隱式添加的標記，有時還能省略一些起始或者結束標記等等。和 XML 嚴格的語法不同，HTML 整體來看是一種“軟性”的語法。

顯然，這種看上去細微的差別實際上卻帶來了巨大的影響。一方麵，這是 HTML 如此流行的原因：它能包容您的錯誤，簡化網絡開發。另一方麵，這使得它很難編寫正式的語法。概括地說，HTML 無法很容易地通過常規解析器解析（因為它的語法不是與上下文無關的語法），也無法通過 XML 解析器來解析。

3.2.3HTML DTD

HTML 的定義采用了 DTD 格式。此格式可用於定義 SGML 族的語言。它包括所有允許使用的元素及其屬性和層次結構的定義。如上文所述，HTML DTD 無法構成與上下文無關的語法。

DTD 存在一些變體。嚴格模式完全遵守 HTML 規範，而其他模式可支持以前的瀏覽器所使用的標記。這樣做的目的是確保向下兼容一些早期版本的內容。最新的嚴格模式 DTD 可以在這裏找到：www.w3.org/TR/html4/strict.dtd

3.2.4DOM

解析器的輸出“解析樹”是由 DOM 元素和屬性節點構成的樹結構。DOM 是文檔對象模型 (Document Object Model) 的縮寫。它是 HTML 文檔的對象表示，同時也是外部內容（例如 JavaScript）與 HTML 元素之間的接口。 
解析樹的根節點是“Document”對象。

DOM 與標記之間幾乎是一一對應的關係。比如下麵這段標記：

<html>
  <body>
    <p>
      Hello World
    </p>
    <div> <img src="example.png"/></div>
  </body>
</html>

可翻譯成如下的 DOM 樹：

圖：示例標記的 DOM 樹

和 HTML 一樣，DOM 也是由 W3C 組織指定的。請參見 www.w3.org/DOM/DOMTR。這是關於文檔操作的通用規範。其中一個特定模塊描述針對 HTML 的元素。HTML 的定義可以在這裏找到：www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.html。

我所說的樹包含 DOM 節點，指的是樹是由實現了某個 DOM 接口的元素構成的。瀏覽器所用的具體實現也會具有一些其他屬性，供瀏覽器在內部使用。

3.2.5解析算法

我們在之前章節已經說過，HTML 無法用常規的自上而下或自下而上的解析器進行解析。

原因在於：

1. 語言的寬容本質。
2. 瀏覽器曆來對一些常見的無效 HTML 用法采取包容態度。
3. 解析過程需要不斷地反複。源內容在解析過程中通常不會改變，但是在 HTML 中，腳本標記如果包含document.write，就會添加額外的標記，這樣解析過程實際上就更改了輸入內容。

由於不能使用常規的解析技術，瀏覽器就創建了自定義的解析器來解析 HTML。

HTML5 規範詳細地描述了解析算法。此算法由兩個階段組成：標記化和樹構建。

標記化是詞法分析過程，將輸入內容解析成多個標記。HTML 標記包括起始標記、結束標記、屬性名稱和屬性值。

標記生成器識別標記，傳遞給樹構造器，然後接受下一個字符以識別下一個標記；如此反複直到輸入的結束。

圖：HTML 解析流程（摘自 HTML5 規範）

3.2.6標記化算法

該算法的輸出結果是 HTML 標記。該算法使用狀態機來表示。每一個狀態接收來自輸入信息流的一個或多個字符，並根據這些字符更新下一個狀態。當前的標記化狀態和樹結構狀態會影響進入下一狀態的決定。這意味著，即使接收的字符相同，對於下一個正確的狀態也會產生不同的結果，具體取決於當前的狀態。該算法相當複雜，無法在此詳述，所以我們通過一個簡單的示例來幫助大家理解其原理。

基本示例 - 將下麵的 HTML 代碼標記化：

<html>
  <body>
    Hello world
  </body>
</html>

初始狀態是數據狀態。遇到字符 < 時，狀態更改為“標記打開狀態”。接收一個 a-z 字符會創建“起始標記”，狀態更改為“標記名稱狀態”。這個狀態會一直保持到接收 > 字符。在此期間接收的每個字符都會附加到新的標記名稱上。在本例中，我們創建的標記是 html 標記。

遇到 > 標記時，會發送當前的標記，狀態改回“數據狀態”。<body> 標記也會進行同樣的處理。目前 html 和 body 標記均已發出。現在我們回到“數據狀態”。接收到 Hello world 中的 H 字符時，將創建並發送字符標記，直到接收 </body> 中的 <。我們將為 Hello world 中的每個字符都發送一個字符標記。

現在我們回到“標記打開狀態”。接收下一個輸入字符 / 時，會創建 end tag token 並改為“標記名稱狀態”。我們會再次保持這個狀態，直到接收 >。然後將發送新的標記，並回到“數據狀態”。</html> 輸入也會進行同樣的處理。

圖：對示例輸入進行標記化

3.2.7樹構建算法

在創建解析器的同時，也會創建 Document 對象。在樹構建階段，以 Document 為根節點的 DOM 樹也會不斷進行修改，向其中添加各種元素。標記生成器發送的每個節點都會由樹構建器進行處理。規範中定義了每個標記所對應的 DOM 元素，這些元素會在接收到相應的標記時創建。這些元素不僅會添加到 DOM 樹中，還會添加到開放元素的堆棧中。此堆棧用於糾正嵌套錯誤和處理未關閉的標記。其算法也可以用狀態機來描述。這些狀態稱為“插入模式”。

讓我們來看看示例輸入的樹構建過程：

<html>
  <body>
    Hello world
  </body>
</html>

樹構建階段的輸入是一個來自標記化階段的標記序列。第一個模式是“initial mode”。接收 HTML 標記後轉為“before html”模式，並在這個模式下重新處理此標記。這樣會創建一個 HTMLHtmlElement 元素，並將其附加到 Document 根對象上。

然後狀態將改為“before head”。此時我們接收“body”標記。即使我們的示例中沒有“head”標記，係統也會隱式創建一個 HTMLHeadElement，並將其添加到樹中。

現在我們進入了“in head”模式，然後轉入“after head”模式。係統對 body 標記進行重新處理，創建並插入 HTMLBodyElement，同時模式轉變為“body”。

現在，接收由“Hello world”字符串生成的一係列字符標記。接收第一個字符時會創建並插入“Text”節點，而其他字符也將附加到該節點。

接收 body 結束標記會觸發“after body”模式。現在我們將接收 HTML 結束標記，然後進入“after after body”模式。接收到文件結束標記後，解析過程就此結束。

圖：示例 HTML 的樹構建

3.2.8解析結束後的操作

在此階段，瀏覽器會將文檔標注為交互狀態，並開始解析那些處於“deferred”模式的腳本，也就是那些應在文檔解析完成後才執行的腳本。然後，文檔狀態將設置為“完成”，一個“加載”事件將隨之觸發。

您可以在 HTML5 規範中查看標記化和樹構建的完整算法

3.2.9瀏覽器的容錯機製

您在瀏覽 HTML 網頁時從來不會看到“語法無效”的錯誤。這是因為瀏覽器會糾正任何無效內容，然後繼續工作。

以下麵的 HTML 代碼為例：

<html>
  <mytag>
  </mytag>
  <div>
  <p>
  </div>
    Really lousy HTML
  </p>
</html>

在這裏，我已經違反了很多語法規則（“mytag”不是標準的標記，“p”和“div”元素之間的嵌套有誤等等），但是瀏覽器仍然會正確地顯示這些內容，並且毫無怨言。因為有大量的解析器代碼會糾正 HTML 網頁作者的錯誤。

不同瀏覽器的錯誤處理機製相當一致，但令人稱奇的是，這種機製並不是 HTML 當前規範的一部分。和書簽管理以及前進/後退按鈕一樣，它也是瀏覽器在多年發展中的產物。很多網站都普遍存在著一些已知的無效 HTML 結構，每一種瀏覽器都會嚐試通過和其他瀏覽器一樣的方式來修複這些無效結構。

HTML5 規範定義了一部分這樣的要求。Webkit 在 HTML 解析器類的開頭注釋中對此做了很好的概括。

解析器對標記化輸入內容進行解析，以構建文檔樹。如果文檔的格式正確，就直接進行解析。

遺憾的是，我們不得不處理很多格式錯誤的 HTML 文檔，所以解析器必須具備一定的容錯性。

我們至少要能夠處理以下錯誤情況：

1. 明顯不能在某些外部標記中添加的元素。在此情況下，我們應該關閉所有標記，直到出現禁止添加的元素，然後再加入該元素。
2. 我們不能直接添加的元素。這很可能是網頁作者忘記添加了其中的一些標記（或者其中的標記是可選的）。這些標簽可能包括：HTML HEAD BODY TBODY TR TD LI（還有遺漏的嗎？）。
3. 向 inline 元素內添加 block 元素。關閉所有 inline 元素，直到出現下一個較高級的 block 元素。
4. 如果這樣仍然無效，可關閉所有元素，直到可以添加元素為止，或者忽略該標記。

讓我們看一些 Webkit 容錯的示例：

使用了 </br> 而不是 <br>

有些網站使用了 </br> 而不是 <br>。為了與 IE 和 Firefox 兼容，Webkit 將其與 <br> 做同樣的處理。 
代碼如下：

if (t->isCloseTag(brTag) && m_document->inCompatMode()) {
     reportError(MalformedBRError);
     t->beginTag = true;
}

請注意，錯誤處理是在內部進行的，用戶並不會看到這個過程。

離散表格

離散表格是指位於其他表格內容中，但又不在任何一個單元格內的表格。 
比如以下的示例：

<table>
    <table>
        <tr><td>inner table</td></tr>
    </table>
    <tr><td>outer table</td></tr>
</table>

Webkit 會將其層次結構更改為兩個同級表格：

<table>
    <tr><td>outer table</td></tr>
</table>
<table>
    <tr><td>inner table</td></tr>
</table>

代碼如下：

if (m_inStrayTableContent && localName == tableTag)
        popBlock(tableTag);

Webkit 使用一個堆棧來保存當前的元素內容，它會從外部表格的堆棧中彈出內部表格。現在，這兩個表格就變成了同級關係。

嵌套的表單元素

如果用戶在一個表單元素中又放入了另一個表單，那麼第二個表單將被忽略。 
代碼如下：

if (!m_currentFormElement) {
        m_currentFormElement = new HTMLFormElement(formTag,    m_document);
}

過於複雜的標記層次結構

代碼的注釋已經說得很清楚了。 

bool HTMLParser::allowNestedRedundantTag(const AtomicString& tagName)
{

unsigned i = 0;
for (HTMLStackElem* curr = m_blockStack;
         i < cMaxRedundantTagDepth && curr && curr->tagName == tagName;
     curr = curr->next, i++) { }
return i != cMaxRedundantTagDepth;
}

放錯位置的 html 或者 body 結束標記

同樣，代碼的注釋已經說得很清楚了。

支持格式非常糟糕的 HTML 代碼。我們從不關閉 body 標記，因為一些愚蠢的網頁會在實際文檔結束之前就關閉。我們通過調用 end() 來執行關閉操作。

if (t->tagName == htmlTag || t->tagName == bodyTag )
        return;

所以網頁作者需要注意，除非您想作為反麵教材出現在 Webkit 容錯代碼段的示例中，否則還請編寫格式正確的 HTML 代碼。

3.3CSS 解析

還記得簡介中解析的概念嗎？和 HTML 不同，CSS 是上下文無關的語法，可以使用簡介中描述的各種解析器進行解析。事實上，CSS 規範定義了 CSS 的詞法和語法。

讓我們來看一些示例： 
詞法語法（詞匯）是針對各個標記用正則表達式定義的：

comment   \/\*[^*]*\*+([^/*][^*]*\*+)*\/
num   [0-9]+|[0-9]*"."[0-9]+
nonascii  [\200-\377]
nmstart   [_a-z]|{nonascii}|{escape}
nmchar    [_a-z0-9-]|{nonascii}|{escape}
name    {nmchar}+
ident   {nmstart}{nmchar}*

“ident”是標識符 (identifier) 的縮寫，比如類名。“name”是元素的 ID（通過“#”來引用）。

語法是采用 BNF 格式描述的。

ruleset
  : selector [ ',' S* selector ]*
    '{' S* declaration [ ';' S* declaration ]* '}' S*
  ;
selector
  : simple_selector [ combinator selector | S+ [ combinator? selector ]? ]?
  ;
simple_selector
  : element_name [ HASH | class | attrib | pseudo ]*
  | [ HASH | class | attrib | pseudo ]+
  ;
class
  : '.' IDENT
  ;
element_name
  : IDENT | '*'
  ;
attrib
  : '[' S* IDENT S* [ [ '=' | INCLUDES | DASHMATCH ] S*
    [ IDENT | STRING ] S* ] ']'
  ;
pseudo
  : ':' [ IDENT | FUNCTION S* [IDENT S*] ')' ]
  ;

解釋：這是一個規則集的結構：

div.error , a.error {
  color:red;
  font-weight:bold;
}

div.error 和 a.error 是選擇器。大括號內的部分包含了由此規則集應用的規則。此結構的正式定義是這樣的：

ruleset
  : selector [ ',' S* selector ]*
    '{' S* declaration [ ';' S* declaration ]* '}' S*
  ;

這表示一個規則集就是一個選擇器，或者由逗號和空格（S 表示空格）分隔的多個（數量可選）選擇器。規則集包含了大括號，以及其中的一個或多個（數量可選）由分號分隔的聲明。“聲明”和“選擇器”將由下麵的 BNF 格式定義。

3.3.1Webkit CSS 解析器

Webkit 使用 Flex 和 Bison 解析器生成器，通過 CSS 語法文件自動創建解析器。正如我們之前在解析器簡介中所說，Bison 會創建自下而上的移位歸約解析器。Firefox 使用的是人工編寫的自上而下的解析器。這兩種解析器都會將 CSS 文件解析成 StyleSheet 對象，且每個對象都包含 CSS 規則。CSS 規則對象則包含選擇器和聲明對象，以及其他與 CSS 語法對應的對象。

圖：解析 CSS

3.4處理腳本和樣式表的順序

3.4.1腳本

網絡的模型是同步的。網頁作者希望解析器遇到 <script> 標記時立即解析並執行腳本。文檔的解析將停止，直到腳本執行完畢。如果腳本是外部的，那麼解析過程會停止，直到從網絡同步抓取資源完成後再繼續。此模型已經使用了多年，也在 HTML4 和 HTML5 規範中進行了指定。作者也可以將腳本標注為“defer”，這樣它就不會停止文檔解析，而是等到解析結束才執行。HTML5 增加了一個選項，可將腳本標記為異步，以便由其他線程解析和執行。

3.4.2預解析

Webkit 和 Firefox 都進行了這項優化。在執行腳本時，其他線程會解析文檔的其餘部分，找出並加載需要通過網絡加載的其他資源。通過這種方式，資源可以在並行連接上加載，從而提高總體速度。請注意，預解析器不會修改 DOM 樹，而是將這項工作交由主解析器處理；預解析器隻會解析外部資源（例如外部腳本、樣式表和圖片）的引用。

3.4.3樣式表

另一方麵，樣式表有著不同的模型。理論上來說，應用樣式表不會更改 DOM 樹，因此似乎沒有必要等待樣式表並停止文檔解析。但這涉及到一個問題，就是腳本在文檔解析階段會請求樣式信息。如果當時還沒有加載和解析樣式，腳本就會獲得錯誤的回複，這樣顯然會產生很多問題。這看上去是一個非典型案例，但事實上非常普遍。Firefox 在樣式表加載和解析的過程中，會禁止所有腳本。而對於 Webkit 而言，僅當腳本嚐試訪問的樣式屬性可能受尚未加載的樣式表影響時，它才會禁止該腳本。

Chapter 4

呈現樹構建

在 DOM 樹構建的同時，瀏覽器還會構建另一個樹結構：呈現樹。這是由可視化元素按照其顯示順序而組成的樹，也是文檔的可視化表示。它的作用是讓您按照正確的順序繪製內容。

Firefox 將呈現樹中的元素稱為“框架”。Webkit 使用的術語是呈現器或呈現對象。 
呈現器知道如何布局並將自身及其子元素繪製出來。 
Webkits RenderObject 類是所有呈現器的基類，其定義如下：

class RenderObject{
  virtual void layout();
  virtual void paint(PaintInfo);
  virtual void rect repaintRect();
  Node* node;  //the DOM node
  RenderStyle* style;  // the computed style
  RenderLayer* containgLayer; //the containing z-index layer
}

每一個呈現器都代表了一個矩形的區域，通常對應於相關節點的 CSS 框，這一點在 CSS2 規範中有所描述。它包含諸如寬度、高度和位置等幾何信息。 
框的類型會受到與節點相關的“display”樣式屬性的影響（請參閱樣式計算章節）。下麵這段 Webkit 代碼描述了根據 display 屬性的不同，針對同一個 DOM 節點應創建什麼類型的呈現器。

RenderObject* RenderObject::createObject(Node* node, RenderStyle* style)
{
    Document* doc = node->document();
    RenderArena* arena = doc->renderArena();
    ...
    RenderObject* o = 0;

    switch (style->display()) {
        case NONE:
            break;
        case INLINE:
            o = new (arena) RenderInline(node);
            break;
        case BLOCK:
            o = new (arena) RenderBlock(node);
            break;
        case INLINE_BLOCK:
            o = new (arena) RenderBlock(node);
            break;
        case LIST_ITEM:
            o = new (arena) RenderListItem(node);
            break;
       ...
    }

    return o;
}

元素類型也是考慮因素之一，例如表單控件和表格都對應特殊的框架。 
在 Webkit 中，如果一個元素需要創建特殊的呈現器，就會替換 createRenderer 方法。呈現器所指向的樣式對象中包含了一些和幾何無關的信息。

4.1呈現樹和 DOM 樹的關係

呈現器是和 DOM 元素相對應的，但並非一一對應。非可視化的 DOM 元素不會插入呈現樹中，例如“head”元素。如果元素的 display 屬性值為“none”，那麼也不會顯示在呈現樹中（但是 visibility 屬性值為“hidden”的元素仍會顯示）。

有一些 DOM 元素對應多個可視化對象。它們往往是具有複雜結構的元素，無法用單一的矩形來描述。例如，“select”元素有 3 個呈現器：一個用於顯示區域，一個用於下拉列表框，還有一個用於按鈕。如果由於寬度不夠，文本無法在一行中顯示而分為多行，那麼新的行也會作為新的呈現器而添加。 
另一個關於多呈現器的例子是格式無效的 HTML。根據 CSS 規範，inline 元素隻能包含 block 元素或 inline 元素中的一種。如果出現了混合內容，則應創建匿名的 block 呈現器，以包裹 inline 元素。

有一些呈現對象對應於 DOM 節點，但在樹中所在的位置與 DOM 節點不同。浮動定位和絕對定位的元素就是這樣，它們處於正常的流程之外，放置在樹中的其他地方，並映射到真正的框架，而放在原位的是占位框架。

圖：呈現樹及其對應的 DOM 樹 (3.1)。初始容器 block 為“viewport”，而在 Webkit 中則為“RenderView”對象。

4.2構建呈現樹的流程

在 Firefox 中，係統會針對 DOM 更新注冊展示層，作為偵聽器。展示層將框架創建工作委托給FrameConstructor，由該構造器解析樣式（請參閱樣式計算）並創建框架。

在 Webkit 中，解析樣式和創建呈現器的過程稱為“附加”。每個 DOM 節點都有一個“attach”方法。附加是同步進行的，將節點插入 DOM 樹需要調用新的節點“attach”方法。

處理 html 和 body 標記就會構建呈現樹根節點。這個根節點呈現對象對應於 CSS 規範中所說的容器 block，這是最上層的 block，包含了其他所有 block。它的尺寸就是視口，即瀏覽器窗口顯示區域的尺寸。Firefox 稱之為 ViewPortFrame，而 Webkit 稱之為 RenderView。這就是文檔所指向的呈現對象。呈現樹的其餘部分以 DOM 樹節點插入的形式來構建。

請參閱關於處理模型的 CSS2 規範。

4.3樣式計算

構建呈現樹時，需要計算每一個呈現對象的可視化屬性。這是通過計算每個元素的樣式屬性來完成的。

樣式包括來自各種來源的樣式表、inline 樣式元素和 HTML 中的可視化屬性（例如“bgcolor”屬性）。其中後者將經過轉化以匹配 CSS 樣式屬性。

樣式表的來源包括瀏覽器的默認樣式表、由網頁作者提供的樣式表以及由瀏覽器用戶提供的用戶樣式表（瀏覽器允許您定義自己喜歡的樣式。以 Firefox 為例，用戶可以將自己喜歡的樣式表放在“Firefox Profile”文件夾下）。

樣式計算存在以下難點：

1. 樣式數據是一個超大的結構，存儲了無數的樣式屬性，這可能造成內存問題。

2. 如果不進行優化，為每一個元素查找匹配的規則會造成性能問題。要為每一個元素遍曆整個規則列表來尋找匹配規則，這是一項浩大的工程。選擇器會具有很複雜的結構，這就會導致某個匹配過程一開始看起來很可能是正確的，但最終發現其實是徒勞的，必須嚐試其他匹配路徑。

   例如下麵這個組合選擇器：

   div div div div{
     ...
   }
   

   這意味著規則適用於作為 3 個 div 元素的子代的 <div>。如果您要檢查規則是否適用於某個指定的<div> 元素，應選擇樹上的一條向上路徑進行檢查。您可能需要向上遍曆節點樹，結果發現隻有兩個 div，而且規則並不適用。然後，您必須嚐試樹中的其他路徑。
3. 應用規則涉及到相當複雜的層疊規則（用於定義這些規則的層次）。

讓我們來看看瀏覽器是如何處理這些問題的：

4.3.1共享樣式數據

Webkit 節點會引用樣式對象 (RenderStyle)。這些對象在某些情況下可以由不同節點共享。這些節點是同級關係，並且：

1. 這些元素必須處於相同的鼠標狀態（例如，不允許其中一個是“:hover”狀態，而另一個不是）
2. 任何元素都沒有 ID
3. 標記名稱應匹配
4. 類屬性應匹配
5. 映射屬性的集合必須是完全相同的
6. 鏈接狀態必須匹配
7. 焦點狀態必須匹配
8. 任何元素都不應受屬性選擇器的影響，這裏所說的“影響”是指在選擇器中的任何位置有任何使用了屬性選擇器的選擇器匹配
9. 元素中不能有任何 inline 樣式屬性
10. 不能使用任何同級選擇器。WebCore 在遇到任何同級選擇器時，隻會引發一個全局開關，並停用整個文檔的樣式共享（如果存在）。這包括 + 選擇器以及 :first-child 和 :last-child 等選擇器。

4.3.2Firefox 規則樹

為了簡化樣式計算，Firefox 還采用了另外兩種樹：規則樹和樣式上下文樹。Webkit 也有樣式對象，但它們不是保存在類似樣式上下文樹這樣的樹結構中，隻是由 DOM 節點指向此類對象的相關樣式。

圖：Firefox 樣式上下文樹 (2.2)

樣式上下文包含端值。要計算出這些值，應按照正確順序應用所有的匹配規則，並將其從邏輯值轉化為具體的值。例如，如果邏輯值是屏幕大小的百分比，則需要換算成絕對的單位。規則樹的點子真的很巧妙，它使得節點之間可以共享這些值，以避免重複計算，還可以節約空間。

所有匹配的規則都存儲在樹中。路徑中的底層節點擁有較高的優先級。規則樹包含了所有已知規則匹配的路徑。規則的存儲是延遲進行的。規則樹不會在開始的時候就為所有的節點進行計算，而是隻有當某個節點樣式需要進行計算時，才會向規則樹添加計算的路徑。

這個想法相當於將規則樹路徑視為詞典中的單詞。如果我們已經計算出如下的規則樹：

假設我們需要為內容樹中的另一個元素匹配規則，並且找到匹配路徑是 B - E - I（按照此順序）。由於我們在樹中已經計算出了路徑 A - B - E - I - L，因此就已經有了此路徑，這就減少了現在所需的工作量。

讓我們看看規則樹如何幫助我們減少工作。

結構劃分

樣式上下文可分割成多個結構。這些結構體包含了特定類別（如 border 或 color）的樣式信息。結構中的屬性都是繼承的或非繼承的。繼承屬性如果未由元素定義，則繼承自其父代。非繼承屬性（也稱為“重置”屬性）如果未進行定義，則使用默認值。

規則樹通過緩存整個結構（包含計算出的端值）為我們提供幫助。這一想法假定底層節點沒有提供結構的定義，則可使用上層節點中的緩存結構。

使用規則樹計算樣式上下文

在計算某個特定元素的樣式上下文時，我們首先計算規則樹中的對應路徑，或者使用現有的路徑。然後我們沿此路徑應用規則，在新的樣式上下文中填充結構。我們從路徑中擁有最高優先級的底層節點（通常也是最特殊的選擇器）開始，並向上遍曆規則樹，直到結構填充完畢。如果該規則節點對於此結構沒有任何規範，那麼我們可以實現更好的優化：尋找路徑更上層的節點，找到後指定完整的規範並指向相關節點即可。這是最好的優化方法，因為整個結構都能共享。這可以減少端值的計算量並節約內存。 
如果我們找到了部分定義，就會向上遍曆規則樹，直到結構填充完畢。

如果我們找不到結構的任何定義，那麼假如該結構是“繼承”類型，我們會在上下文樹中指向父代的結構，這樣也可以共享結構。如果是 reset 類型的結構，則會使用默認值。

如果最特殊的節點確實添加了值，那麼我們需要另外進行一些計算，以便將這些值轉化成實際值。然後我們將結果緩存在樹節點中，供子代使用。

如果某個元素與其同級元素都指向同一個樹節點，那麼它們就可以共享整個樣式上下文。

讓我們來看一個例子，假設我們有如下 HTML 代碼：

<html>
  <body>
    <div  >
      <p>
        this is a <span > big error </span>
        this is also a
        <span > very  big  error</span> error
      </p>
    </div>
    <div  >another error</div>
  </body>
</html>

還有如下規則：

div {margin:5px;color:black}
.err {color:red}
.big {margin-top:3px}
div span {margin-bottom:4px}
#div1 {color:blue}
#div2 {color:green}

為了簡便起見，我們隻需要填充兩個結構：color 結構和 margin 結構。color 結構隻包含一個成員（即“color”），而 margin 結構包含四條邊。 
形成的規則樹如下圖所示（節點的標記方式為“節點名 : 指向的規則序號”）：

圖：規則樹
上下文樹如下圖所示（節點名 : 指向的規則節點）：

圖：上下文樹

假設我們解析 HTML 時遇到了第二個 <div> 標記，我們需要為此節點創建樣式上下文，並填充其樣式結構。 
經過規則匹配，我們發現該 <div> 的匹配規則是第 1、2 和 6 條。這意味著規則樹中已有一條路徑可供我們的元素使用，我們隻需要再為其添加一個節點以匹配第 6 條規則（規則樹中的 F 節點）。 
我們將創建樣式上下文並將其放入上下文樹中。新的樣式上下文將指向規則樹中的 F 節點。

現在我們需要填充樣式結構。首先要填充的是 margin 結構。由於最後的規則節點 (F) 並沒有添加到 margin 結構，我們需要上溯規則樹，直至找到在先前節點插入中計算過的緩存結構，然後使用該結構。我們會在指定 margin 規則的最上層節點（即 B 節點）上找到該結構。

我們已經有了 color 結構的定義，因此不能使用緩存的結構。由於 color 有一個屬性，我們無需上溯規則樹以填充其他屬性。我們將計算端值（將字符串轉化為 RGB 等）並在此節點上緩存經過計算的結構。

第二個 <span> 元素處理起來更加簡單。我們將匹配規則，最終發現它和之前的 span 一樣指向規則 G。由於我們找到了指向同一節點的同級，就可以共享整個樣式上下文了，隻需指向之前 span 的上下文即可。

對於包含了繼承自父代的規則的結構，緩存是在上下文樹中進行的（事實上 color 屬性是繼承的，但是 Firefox 將其視為 reset 屬性，並緩存到規則樹上）。 
例如，如果我們在某個段落中添加 font 規則：

p {font-family:Verdana;font size:10px;font-weight:bold}

那麼，該段落元素作為上下文樹中的 div 的子代，就會共享與其父代相同的 font 結構（前提是該段落沒有指定 font 規則）。

在 Webkit 中沒有規則樹，因此會對匹配的聲明遍曆 4 次。首先應用非重要高優先級的屬性（由於作為其他屬性的依據而應首先應用的屬性，例如 display），接著是高優先級重要規則，然後是普通優先級非重要規則，最後是普通優先級重要規則。這意味著多次出現的屬性會根據正確的層疊順序進行解析。最後出現的最終生效。 

因此概括來說，共享樣式對象（整個對象或者對象中的部分結構）可以解決問題 1 和問題 3。Firefox 規則樹還有助於按照正確的順序應用屬性。

4.3.3對規則進行處理以簡化匹配

樣式規則有一些來源：

• 外部樣式表或樣式元素中的 CSS 規則

  p {color:blue}
  

• inline 樣式屬性及類似內容

  <p  />
  

• HTML 可視化屬性（映射到相關的樣式規則）

  <p bgcolor="blue" />
  

後兩種很容易和元素進行匹配，因為元素擁有樣式屬性，而且 HTML 屬性可以使用元素作為鍵值進行映射。

我們之前在第 2 個問題中提到過，CSS 規則匹配可能比較棘手。為了解決這一難題，可以對 CSS 規則進行一些處理，以便訪問。

樣式表解析完畢後，係統會根據選擇器將 CSS 規則添加到某個哈希表中。這些哈希表的選擇器各不相同，包括 ID、類名稱、標記名稱等，還有一種通用哈希表，適合不屬於上述類別的規則。如果選擇器是 ID，規則就會添加到 ID 表中；如果選擇器是類，規則就會添加到類表中，依此類推。 
這種處理可以大大簡化規則匹配。我們無需查看每一條聲明，隻要從哈希表中提取元素的相關規則即可。這種優化方法可排除掉 95% 以上規則，因此在匹配過程中根本就不用考慮這些規則了 (4.1)。

我們以如下的樣式規則為例：

p.error {color:red}
#messageDiv {height:50px}
div {margin:5px}

第一條規則將插入類表，第二條將插入 ID 表，而第三條將插入標記表。 
對於下麵的 HTML 代碼段：

<p >an error occurred </p>
<div >this is a message</div>

我們首先會為 p 元素尋找匹配的規則。類表中有一個“error”鍵，在下麵可以找到“p.error”的規則。div 元素在 ID 表（鍵為 ID）和標記表中有相關的規則。剩下的工作就是找出哪些根據鍵提取的規則是真正匹配的了。 
例如，如果 div 的對應規則如下：

table div {margin:5px}

這條規則仍然會從標記表中提取出來，因為鍵是最右邊的選擇器，但這條規則並不匹配我們的 div 元素，因為 div 沒有 table 祖先。

Webkit 和 Firefox 都進行了這一處理。

4.3.4以正確的層疊順序應用規則

樣式對象具有每個可視化屬性一一對應的屬性（均為 CSS 屬性但更為通用）。如果某個屬性未由任何匹配規則所定義，那麼部分屬性就可由父代元素樣式對象繼承。其他屬性具有默認值。

如果定義不止一個，就會出現問題，需要通過層疊順序來解決。

樣式表層疊順序

某個樣式屬性的聲明可能會出現在多個樣式表中，也可能在同一個樣式表中出現多次。這意味著應用規則的順序極為重要。這稱為“層疊”順序。根據 CSS2 規範，層疊的順序為（優先級從低到高）：

1. 瀏覽器聲明
2. 用戶普通聲明
3. 作者普通聲明
4. 作者重要聲明
5. 用戶重要聲明

瀏覽器聲明是重要程度最低的，而用戶隻有將該聲明標記為“重要”才可以替換網頁作者的聲明。同樣順序的聲明會根據特異性進行排序，然後再是其指定順序。HTML 可視化屬性會轉換成匹配的 CSS 聲明。它們被視為低優先級的網頁作者規則。

特異性

選擇器的特異性由 CSS2 規範定義如下：

• 如果聲明來自於“style”屬性，而不是帶有選擇器的規則，則記為 1，否則記為 0 (= a)
• 記為選擇器中 ID 屬性的個數 (= b)
• 記為選擇器中其他屬性和偽類的個數 (= c)
• 記為選擇器中元素名稱和偽元素的個數 (= d)

將四個數字按 a-b-c-d 這樣連接起來（位於大數進製的數字係統中），構成特異性。

您使用的進製取決於上述類別中的最高計數。 
例如，如果 a=14，您可以使用十六進製。如果 a=17，那麼您需要使用十七進製；當然不太可能出現這種情況，除非是存在如下的選擇器：html body div div p ...（在選擇器中出現了 17 個標記，這樣的可能性極低）。

一些示例：

 *             {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */
 li            {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */
 li:first-line {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul li         {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul ol+li      {}  /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */
 h1 + *[rel=up]{}  /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */
 ul ol li.red  {}  /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */
 li.red.level  {}  /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */
 #x34y         {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */
           /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

規則排序

找到匹配的規則之後，應根據級聯順序將其排序。Webkit 對於較小的列表會使用冒泡排序，而對較大的列表則使用歸並排序。對於以下規則，Webkit 通過替換“>”運算符來實現排序：

static bool operator >(CSSRuleData& r1, CSSRuleData& r2)
{
    int spec1 = r1.selector()->specificity();
    int spec2 = r2.selector()->specificity();
    return (spec1 == spec2) : r1.position() > r2.position() : spec1 > spec2;
}

4.4漸進式處理

Webkit 使用一個標記來表示是否所有的頂級樣式表（包括 @imports）均已加載完畢。如果在附加過程中尚未完全加載樣式，則使用占位符，並在文檔中進行標注，等樣式表加載完畢後再重新計算。

Chapter 5

布局

呈現器在創建完成並添加到呈現樹時，並不包含位置和大小信息。計算這些值的過程稱為布局或重排。

HTML 采用基於流的布局模型，這意味著大多數情況下隻要一次遍曆就能計算出幾何信息。處於流中靠後位置元素通常不會影響靠前位置元素的幾何特征，因此布局可以按從左至右、從上至下的順序遍曆文檔。但是也有例外情況，比如 HTML 表格的計算就需要不止一次的遍曆 (3.5)。

坐標係是相對於根框架而建立的，使用的是上坐標和左坐標。

布局是一個遞歸的過程。它從根呈現器（對應於 HTML 文檔的 <html> 元素）開始，然後遞歸遍曆部分或所有的框架層次結構，為每一個需要計算的呈現器計算幾何信息。

根呈現器的位置左邊是 0,0，其尺寸為視口（也就是瀏覽器窗口的可見區域）。

所有的呈現器都有一個“laybout”或者“reflow”方法，每一個呈現器都會調用其需要進行布局的子代的 layout 方法。

5.1Dirty 位係統

為避免對所有細小更改都進行整體布局，瀏覽器采用了一種“dirty 位”係統。如果某個呈現器發生了更改，或者將自身及其子代標注為“dirty”，則需要進行布局。

有兩種標記：“dirty”和“children are dirty”。“children are dirty”表示盡管呈現器自身沒有變化，但它至少有一個子代需要布局。

5.2全局布局和增量布局

全局布局是指觸發了整個呈現樹範圍的布局，觸發原因可能包括：

1. 影響所有呈現器的全局樣式更改，例如字體大小更改。
2. 屏幕大小調整。

布局可以采用增量方式，也就是隻對 dirty 呈現器進行布局（這樣可能存在需要進行額外布局的弊端）。 
當呈現器為 dirty 時，會異步觸發增量布局。例如，當來自網絡的額外內容添加到 DOM 樹之後，新的呈現器附加到了呈現樹中。

圖：增量布局 - 隻有 dirty 呈現器及其子代進行布局 (3.6)。

5.3異步布局和同步布局

增量布局是異步執行的。Firefox 將增量布局的“reflow 命令”加入隊列，而調度程序會觸發這些命令的批量執行。Webkit 也有用於執行增量布局的計時器：對呈現樹進行遍曆，並對 dirty 呈現器進行布局。 
請求樣式信息（例如“offsetHeight”）的腳本可同步觸發增量布局。 
全局布局往往是同步觸發的。 
有時，當初始布局完成之後，如果一些屬性（如滾動位置）發生變化，布局就會作為回調而觸發。

5.4優化

如果布局是由“大小調整”或呈現器的位置（而非大小）改變而觸發的，那麼可以從緩存中獲取呈現器的大小，而無需重新計算。 
在某些情況下，隻有一個子樹進行了修改，因此無需從根節點開始布局。這適用於在本地進行更改而不影響周圍元素的情況，例如在文本字段中插入文本（否則每次鍵盤輸入都將觸發從根節點開始的布局）。

5.5布局處理

布局通常具有以下模式：

1. 父呈現器確定自己的寬度。
2. 父呈現器依次處理子呈現器，並且：
   1. 放置子呈現器（設置 x,y 坐標）。
   2. 如果有必要，調用子呈現器的布局（如果子呈現器是 dirty 的，或者這是全

      最後更新：2017-04-03 18:52:05

        上一篇： 通信原理--曹麗娜

        下一篇： How browsers work

      ---

      相關內容

      ---

      •   JUnit源碼分析(四)——從Decorator模式說起
      •   Facebook發布新工具：防止用戶被前任用豔照報複
      •  Spring 設計理念探討係列一
      •  ASP.NET程序中常用編程代碼
      •   多種tabs切換的應用
      •   縈繞於指尖的節奏：今天，我們來聊聊機械鍵盤
      •   OGRE學習筆記之一
      •   阿裏雲前端周刊 - 第 14 期
      •   日誌易：金融之支付行業日誌大數據分析案例解讀
      •  OSS圖片處理服務上線

      熱門內容

      ---

      •  PostgreSQL 路徑規劃插件 pgruoting 介紹
      •  人生不過如此
      •   《STM32庫開發實戰指南：基於STM32F4》----導讀
      •   解密區塊鏈：從基礎概念到技術實現的進階攻略
      •  ZED Board從入門到精通（三）：從傳統ARM開發到PS開發的轉變
      •  [圖文]曆屆奧斯卡影帝(上)
      •   紮克伯格發6千字長文,談Facebook未來願景和世界該有的樣子
      •  VS 添加jQuery智能提示
      •  python3學習
      •   突破吞吐限製，多NAS性能聚合方案，數據上傳及讀寫

      最新內容

      ---

      •   駐雲Gartner聯合發布人工智能時代的MSP白皮書
      •   雲端安全之三：最佳實踐
      •   突破吞吐限製，多NAS性能聚合方案，數據上傳及讀寫
      •   如何同步TableStore數據到OSS
      •   百億級全網輿情分析係統存儲設計
      •   在ECS中訪問各類阿裏雲雲資源的正確姿勢
      •   不外傳的seo計劃教程方案
      •   網站有收錄沒排名的原因與解決辦法
      •   燃！阿裏的技術小哥們又又又拿冠軍了！
      •   如何將個性化需求變成大數據解決方案

      ---