[置頂]       現代瀏覽器的工作原理

簡介

瀏覽器可以被認為是使用最廣泛的軟件，本文將介紹瀏覽器的工 作原理，我們將看到，從你在地址欄輸入google.com到你看到google主頁過程中都發生了什么。

將討論的瀏覽器

今天，有五種主流瀏覽器——IE、Firefox、Safari、Chrome及Opera。本文將基于一些開源瀏覽器的例子——Firefox、 Chrome及Safari，Safari是部分開源的。

根據W3C（World Wide Web Consortium 萬維網聯盟）的瀏覽器統計數據，當前（2011年9月），Firefox、Safari及Chrome的市場占有率綜合已快接近50％。（原文為2009年10月，數據沒有太大變化）因此，可以說開源瀏覽器將近占據了瀏覽器市場的半壁江山。

瀏覽器的主要功能

瀏覽器的主要功能是將用戶選擇得web資源呈現出來，它需要從服務器請求資源，并將其顯示在瀏覽器窗口中，資源的格式通常是HTML，也包括PDF、image及其他格式。用戶用URI（Uniform Resource Identifier 統一資源標識符）來指定所請求資源的位置，在網絡一章有更多討論。

HTML和CSS規范中規定了瀏覽器解釋html文檔的方式，由 W3C組織對這些規范進行維護，W3C是負責制定web標準的組織。

HTML規范的最新版本是HTML4(http://www.w3.org/TR/html401/)，HTML5還在制定中（譯注：兩年前），最新的CSS規范版本是2（http://www.w3.org/TR/CSS2），CSS3也還正在制定中（譯注：同樣兩年前）。

這些年來，瀏覽器廠商紛紛開發自己的擴展，對規范的遵循并不完善，這為web開發者帶來了嚴重的兼容性問題。

但是，瀏覽器的用戶界面則差不多，常見的用戶界面元素包括：

▲用來輸入URI的地址欄

▲前進、后退按鈕

▲書簽選項

▲用于刷新及暫停當前加載文檔的刷新、暫停按鈕

▲用于到達主頁的主頁按鈕

奇怪的是，并沒有哪個正式公布的規范對用戶界面做出規定，這些是多年來各瀏覽器廠商之間相互模仿和不斷改進得結果。

HTML5并沒有規定瀏覽器必須具有的UI元素，但列出了一些常用元素，包括地址欄、狀態欄及工具欄。還有一些瀏覽器有自己專有得功能，比如Firefox得下載管理。更多相關內容將在后面討論用戶界面時介紹。

瀏覽器的主要構成High Level Structure

瀏覽器的主要組件包括：

▲用戶界面－ 包括地址欄、后退/前進按鈕、書簽目錄等，也就是你所看到的除了用來顯示你所請求頁面的主窗口之外的其他部分

▲瀏覽器引擎－ 用來查詢及操作渲染引擎的接口

▲渲染引擎－ 用來顯示請求的內容，例如，如果請求內容為html，它負責解析html及css，并將解析后的結果顯示出來

▲網絡－ 用來完成網絡調用，例如http請求，它具有平臺無關的接口，可以在不同平臺上工作
UI 后端－ 用來繪制類似組合選擇框及對話框等基本組件，具有不特定于某個平臺的通用接口，底層使用操作系統的用戶接口

▲JS解釋器－ 用來解釋執行JS代碼

▲數據存儲－ 屬于持久層，瀏覽器需要在硬盤中保存類似cookie的各種數據，HTML5定義了web database技術，這是一種輕量級完整的客戶端存儲技術

圖1：瀏覽器主要組件

需要注意的是，不同于大部分瀏覽器，Chrome為每個Tab分配了各自的渲染引擎實例，每個Tab就是一個獨立的進程。

對于構成瀏覽器的這些組件，后面會逐一詳細討論。

組件間的通信 Communication between the components

Firefox和Chrome都開發了一個特殊的通信結構，后面將有專門的一章進行討論。

渲染引擎 The rendering engine

渲染引擎的職責就是渲染，即在瀏覽器窗口中顯示所請求的內容。

默認情況下，渲染引擎可以顯示html、xml文檔及圖片，它也可以借助插件（一種瀏覽器擴展）顯示其他類型數據，例如使用PDF閱讀器插件，可以顯示PDF格式，將由專門一章講解插件及擴展，這里只討論渲染引擎最主要的用途——顯示應用了CSS之后的html及圖片。

渲染引擎 Rendering engines

本文所討論得瀏覽器——Firefox、Chrome和Safari是基于兩種渲染引擎構建的，Firefox使用Geoko——Mozilla自主研發的渲染引擎，Safari和Chrome都使用webkit。

Webkit是一款開源渲染引擎，它本來是為linux平臺研發的，后來由Apple移植到Mac及Windows上，相關內容請參考http://webkit.org。

主流程 The main flow

渲染引擎首先通過網絡獲得所請求文檔的內容，通常以8K分塊的方式完成。

下面是渲染引擎在取得內容之后的基本流程：

解析html以構建dom樹->構建render樹->布局render樹->繪制render樹

圖2：渲染引擎基本流程

渲染引擎開始解析html，并將標簽轉化為內容樹中的dom節點。接著，它解析外部CSS文件及style標簽中的樣式信息。這些樣式信息以及html中的可見性指令將被用來構建另一棵樹——render樹。

Render樹由一些包含有顏色和大小等屬性的矩形組成，它們將被按照正確的順序顯示到屏幕上。

Render樹構建好了之后，將會執行布局過程，它將確定每個節點在屏幕上的確切坐標。再下一步就是繪制，即遍歷render樹，并使用UI后端層繪制每個節點。

值得注意的是，這個過程是逐步完成的，為了更好的用戶體驗，渲染引擎將會盡可能早的將內容呈現到屏幕上，并不會等到所有的html都解析完成之后再去構建和布局render樹。它是解析完一部分內容就顯示一部分內容，同時，可能還在通過網絡下載其余內容。

 

圖3：webkit主流程

 

圖4：Mozilla的Geoko 渲染引擎主流程

從圖3和4中可以看出，盡管webkit和Gecko使用的術語稍有不同，他們的主要流程基本相同。Gecko稱可見的格式化元素組成的樹為frame樹，每個元素都是一個frame，webkit則使用render樹這個名詞來命名由渲染對象組成的樹。Webkit中元素的定位稱為布局，而Gecko中稱為回流。Webkit稱利用dom節點及樣式信息去構建render樹的過程為attachment，Gecko在html和dom樹之間附加了一層，這層稱為內容接收器，相當制造dom元素的工廠。下面將討論流程中的各個階段。

解析 Parsing－general

既然解析是渲染引擎中一個非常重要的過程，我們將稍微深入的研究它。首先簡要介紹一下解析。

解析一個文檔即將其轉換為具有一定意義的結構——編碼可以理解和使用的東西。解析的結果通常是表達文檔結構的節點樹，稱為解析樹或語法樹。

例如，解析“2＋3－1”這個表達式，可能返回這樣一棵樹。

圖5：數學表達式樹節點

文法 Grammars

解析基于文檔依據的語法規則——文檔的語言或格式。每種可被解析的格式必須具有由詞匯及語法規則組成的特定的文法，稱為上下文無關文法。人類語言不具有這一特性，因此不能被一般的解析技術所解析。

解析器－詞法分析器 Parser－Lexer combination

解析可以分為兩個子過程——語法分析及詞法分析

詞法分析就是將輸入分解為符號，符號是語言的詞匯表——基本有效單元的集合。對于人類語言來說，它相當于我們字典中出現的所有單詞。

語法分析指對語言應用語法規則。

解析器一般將工作分配給兩個組件——詞法分析器（有時也叫分詞器）負責將輸入分解為合法的符號，解析器則根據語言的語法規則分析文檔結構，從而構建解析樹，詞法分析器知道怎么跳過空白和換行之類的無關字符。

圖6：從源文檔到解析樹

解析過程是迭代的，解析器從詞法分析器處取道一個新的符號，并試著用這個符號匹配一條語法規則， 如果匹配了一條規則，這個符號對應的節點將被添加到解析樹上，然后解析器請求另一個符號。如果沒有匹配到規則，解析器將在內部保存該符號，并從詞法分析器 取下一個符號，直到所有內部保存的符號能夠匹配一項語法規則。如果最終沒有找到匹配的規則，解析器將拋出一個異常，這意味著文檔無效或是包含語法錯誤。

轉換 Translation

很多時候，解析樹并不是最終結果。解析一般在轉換中使用——將輸入文檔轉換為另一種格式。編譯就是個例子，編譯器在將一段源碼編譯為機器碼的時候，先將源碼解析為解析樹，然后將該樹轉換為一個機器碼文檔。

圖7：編譯流程

解析實例 Parsing example

圖5中，我們從一個數學表達式構建了一個解析樹，這里定義一個簡單的數學語言來看下解析過程。

詞匯表：我們的語言包括整數、加號及減號。

語法：

1. 該語言的語法基本單元包括表達式、term及操作符

2. 該語言可以包括多個表達式

3. 一個表達式定義為兩個term通過一個操作符連接

4. 操作符可以是加號或減號

5. term可以是一個整數或一個表達式

現在來分析一下“2＋3－1”這個輸入

第一個匹配規則的子字符串是“2”，根據規則5，它是一個term，第二個匹配的是“2＋3”，它符合第2條規則——一個操作符連接兩個term，下一次匹配發生在輸入的結束處。“2＋3－1”是一個表達式，因為我們已經知道“2＋3”是一個term，所以我們有了一個term緊跟著一個操作符及另一個term。“2＋＋”將不會匹配任何規則，因此是一個無效輸入。

詞匯表及語法的定義

詞匯表通常利用正則表達式來定義。

例如上面的語言可以定義為：

 

 

正如看到的，這里用正則表達式定義整數。

語法通常用BNF格式定義，我們的語言可以定義為：

 

 

如果一個語言的文法是上下文無關的，則它可以用正則解析器來解析。對上下文無關文法的一個直觀的定義是，該文法可以用BNF來完整的表達。可查看http://en.wikipedia.org/wiki/Context-free_grammar。

解析器類型 Types of parsers

有兩種基本的解析器——自頂向下解析及自底向上解析。比較直觀的解釋是，自頂向下解析，查看語法的最高層結構并試著匹配其中一個；自底向上解析則從輸入開始，逐步將其轉換為語法規則，從底層規則開始直到匹配高層規則。

來看一下這兩種解析器如何解析上面的例子：

自頂向下解析器從最高層規則開始——它先識別出“2＋3“，將其視為一個表達式，然后識別出”2＋3－1“為一個表達式（識別表達式的過程中匹配了其他規則，但出發點是最高層規則）。

自底向上解析會掃描輸入直到匹配了一條規則，然后用該規則取代匹配的輸入，直到解析完所有輸入。部分匹配的表達式被放置在解析堆棧中。

 

Stack	Input
	2 + 3 – 1
term	+ 3 – 1
term operation	3 – 1
expression	- 1
expression operation	1
expression

自底向上解析器稱為shift reduce 解析器，因為輸入向右移動（想象一個指針首先指向輸入開始處，并向右移動），并逐漸簡化為語法規則。

自動化解析 Generating parse

解析器生成器這個工具可以自動生成解析器，只需要指定語言的文法——詞匯表及語法規則，它就可以生成一個解析器。創建一個解析器需要對解析有深入的理解，而且手動的創建一個由較好性能的解析器并不容易，所以解析生成器很有用。Webkit使用兩個知名的解析生成器——用于創建語法分析器的Flex及創建解析器的Bison（你可能接觸過Lex和Yacc）。Flex的輸入是一個包含了符號定義的正則表達式，Bison的輸入是用BNF格式表示的語法規則。rs automatically

HTML解析器 HTML Parser

HTML解析器的工作是將html標識解析為解析樹。

HTML文法定義 The HTML grammar definition

W3C組織制定規范定義了HTML的詞匯表和語法。

非上下文無關文法 Not a context free grammar

正如在解析簡介中提到的，上下文無關文法的語法可以用類似BNF的格式來定義。

不幸的是，所有的傳統解析方式都不適用于html（當然我提出它們并不只是因為好玩，它們將用來解析css和js），html不能簡單的用解析所需的上下文無關文法來定義。

Html 有一個正式的格式定義——DTD（Document Type Definition 文檔類型定義）——但它并不是上下文無關文法，html更接近于xml，現在有很多可用的xml解析器，html有個xml的變體——xhtml，它們間的不同在于，html更寬容，它允許忽略一些特定標簽，有時可以省略開始或結束標簽。總的來說，它是一種soft語法，不像xml呆板、固執。

顯然，這個看起來很小的差異卻帶來了很大的不同。一方面，這是html流行的原因——它的寬容使web開發人員的工作更加輕松，但另一方面，這也使很難去寫一個格式化的文法。所以，html的解析并不簡單，它既不能用傳統的解析器解析，也不能用xml解析器解析。

HTML DTD

Html適用DTD格式進行定義，這一格式是用于定義SGML家族的語言，包括了對所有允許元素及它們的屬性和層次關系的定義。正如前面提到的，html DTD并沒有生成一種上下文無關文法。

DTD有一些變種，標準模式只遵守規范，而其他模式則包含了對瀏覽器過去所使用標簽的支持，這么做是為了兼容以前內容。最新的標準DTD在http://www.w3.org/TR/html4/strict.dtd

DOM

輸出的樹，也就是解析樹，是由DOM元素及屬性節點組成的。DOM是文檔對象模型的縮寫，它是html文檔的對象表示，作為html元素的外部接口供js等調用。

樹的根是“document”對象。

DOM和標簽基本是一一對應的關系，例如，如下的標簽：

 

 

將會被轉換為下面的DOM樹：

圖8：示例標簽對應的DOM樹

和html一樣，DOM的規范也是由W3C組織制定的。訪問http://www.w3.org/DOM/DOMTR，這是使用文檔的一般規范。一個模型描述一種特定的html元素，可以在http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-20030109/idl-definitions.htm 查看html定義。

這里所謂的樹包含了DOM節點是說樹是由實現了DOM接口的元素構建而成的，瀏覽器使用已被瀏覽器內部使用的其他屬性的具體實現。

解析算法 The parsing algorithm

正如前面章節中討論的，hmtl不能被一般的自頂向下或自底向上的解析器所解析。

原因是：

1. 這門語言本身的寬容特性

2. 瀏覽器對一些常見的非法html有容錯機制

3. 解析過程是往復的，通常源碼不會在解析過程中發生改變，但在html中，腳本標簽包含的“document.write ”可能添加標簽，這說明在解析過程中實際上修改了輸入

不能使用正則解析技術，瀏覽器為html定制了專屬的解析器。

Html5規范中描述了這個解析算法，算法包括兩個階段——符號化及構建樹。

符號化是詞法分析的過程，將輸入解析為符號，html的符號包括開始標簽、結束標簽、屬性名及屬性值。

符號識別器識別出符號后，將其傳遞給樹構建器，并讀取下一個字符，以識別下一個符號，這樣直到處理完所有輸入。

圖9：HTML解析流程

符號識別算法 The tokenization algorithm

算法輸出html符號，該算法用狀態機表示。每次讀取輸入流中的一個或多個字符，并根據這些字符轉移到下一個狀態，當前的符號狀態及構建樹狀態共同影響結果，這意味著，讀取同樣的字符，可能因為當前狀態的不同，得到不同的結果以進入下一個正確的狀態。

這個算法很復雜，這里用一個簡單的例子來解釋這個原理。

基本示例——符號化下面的html：

 

 

初始狀態為“Data State”，當遇到“<”字符，狀態變為“Tag open state”，讀取一個a－z的字符將產生一個開始標簽符號，狀態相應變為“Tag name state”，一直保持這個狀態直到讀取到“>”，每個字符都附加到這個符號名上，例子中創建的是一個html符號。

當讀取到“>”，當前的符號就完成了，此時，狀態回到“Data state”，“<body>”重復這一處理過程。到這里，html和body標簽都識別出來了。現在，回到“Data state”，讀取“Hello world”中的字符“H”將創建并識別出一個字符符號，這里會為“Hello world”中的每個字符生成一個字符符號。

這樣直到遇到“</body>”中的“<”。現在，又回到了“Tag open state”，讀取下一個字符“/”將創建一個閉合標簽符號，并且狀態轉移到“Tag name state”，還是保持這一狀態，直到遇到“>”。然后，產生一個新的標簽符號并回到“Data state”。后面的“</html>”將和“</body>”一樣處理。

圖10：符號化示例輸入

樹的構建算法 Tree construction algorithm

在樹的構建階段，將修改以Document為根的DOM樹，將元素附加到樹上。每個由符號識別器識別生成的節點將會被樹構造器進行處理，規范中定義了每個符號相對應的Dom元素，對應的Dom元素將會被創建。這些元素除了會被添加到Dom樹上，還將被添加到開放元素堆棧中。這個堆棧用來糾正嵌套的未匹配和未閉合標簽，這個算法也是用狀態機來描述，所有的狀態采用插入模式。

來看一下示例中樹的創建過程：

 

 

構建樹這一階段的輸入是符號識別階段生成的符號序列。

首先是“initial mode”，接收到html符號后將轉換為“before html”模式，在這個模式中對這個符號進行再處理。此時，創建了一個HTMLHtmlElement元素，并將其附加到根Document對象上。

狀態此時變為“before head”，接收到body符號時，即使這里沒有head符號，也將自動創建一個HTMLHeadElement元素并附加到樹上。

現在，轉到“in head”模式，然后是“after head”。到這里，body符號會被再次處理，將創建一個HTMLBodyElement并插入到樹中，同時，轉移到“in body”模式。

然后，接收到字符串“Hello world”的字符符號，第一個字符將導致創建并插入一個text節點，其他字符將附加到該節點。

接收到body結束符號時，轉移到“after body”模式，接著接收到html結束符號，這個符號意味著轉移到了“after after body”模式，當接收到文件結束符時，整個解析過程結束。

圖11：示例html樹的構建過程

解析結束時的處理 Action when the parsing is finished

在這個階段，瀏覽器將文檔標記為可交互的，并開始解析處于延時模式中的腳本——這些腳本在文檔解析后執行。

文檔狀態將被設置為完成，同時觸發一個load事件。

Html5規范中有符號化及構建樹的完整算法(http://www.w3.org/TR/html5/syntax.html#html-parser)。

瀏覽器容錯 Browsers error tolerance

你從來不會在一個html頁面上看到“無效語法”這樣的錯誤，瀏覽器修復了無效內容并繼續工作。

以下面這段html為例：

 

 

這段html違反了很多規則（mytag不是合法的標簽，p及div錯誤的嵌套等等），但是瀏覽器仍然可以沒有任何怨言的繼續顯示，它在解析的過程中修復了html作者的錯誤。

瀏覽器都具有錯誤處理的能力，但是，另人驚訝的是，這并不是html最新規范的內容，就像書簽及前進后退按鈕一樣，它只是瀏覽器長期發展的結果。一些比較知名的非法html結構，在許多站點中出現過，瀏覽器都試著以一種和其他瀏覽器一致的方式去修復。

Html5規范定義了這方面的需求，webkit在html解析類開始部分的注釋中做了很好的總結。

解析器將符號化的輸入解析為文檔并創建文檔，但不幸的是，我們必須處理很多沒有很好格式化的html文檔，至少要小心下面幾種錯誤情況。

1. 在未閉合的標簽中添加明確禁止的元素。這種情況下，應該先將前一標簽閉合

2. 不能直接添加元素。有些人在寫文檔的時候會忘了中間一些標簽（或者中間標簽是可選的），比如HTML HEAD BODY TR TD LI等

3. 想在一個行內元素中添加塊狀元素。關閉所有的行內元素，直到下一個更高的塊狀元素

4. 如果這些都不行，就閉合當前標簽直到可以添加該元素。

下面來看一些webkit容錯的例子：

一些網站使用</br>替代<br>，為了兼容IE和Firefox，webkit將其看作<br>。

代碼：

 

 

Note－這里的錯誤處理在內部進行，用戶看不到。

迷路的表格

這指一個表格嵌套在另一個表格中，但不在它的某個單元格內。

比如下面這個例子：

 

 

webkit將會將嵌套的表格變為兩個兄弟表格：

 

 

代碼：

 

 

webkit使用堆棧存放當前的元素內容，它將從外部表格的堆棧中彈出內部的表格，則它們變為了兄弟表格。

嵌套的表單元素

用戶將一個表單嵌套到另一個表單中，則第二個表單將被忽略。

代碼：

 

 

太深的標簽繼承

www.liceo.edu.mx是一個由嵌套層次的站點的例子，最多只允許20個相同類型的標簽嵌套，多出來的將被忽略。

代碼：

 

 

放錯了地方的html、body閉合標簽

又一次不言自明。

支持不完整的html。我們從來不閉合body，因為一些愚蠢的網頁總是在還未真正結束時就閉合它。我們依賴調用end方法去執行關閉的處理。

代碼：

 

 

所以，web開發者要小心了，除非你想成為webkit容錯代碼的范例，否則還是寫格式良好的html吧。

CSS解析 CSS parsing

還記得簡介中提到的解析的概念嗎，不同于html，css屬于上下文無關文法，可以用前面所描述的解析器來解析。Css規范定義了css的詞法及語法文法。

看一些例子：

每個符號都由正則表達式定義了詞法文法（詞匯表）：

 

 

“ident”是識別器的縮寫，相當于一個class名，“name”是一個元素id（用“＃”引用）。

語法用BNF進行描述：

 

 

說明：一個規則集合有這樣的結構

 

 

div.error和a.error時選擇器，大括號中的內容包含了這條規則集合中的規則，這個結構在下面的定義中正式的定義了：

 

 

這說明，一個規則集合具有一個或是可選個數的多個選擇器，這些選擇器以逗號和空格（S表示空格）進行分隔。每個規則集合包含大括號及大括號中的一條或多條以分號隔開的聲明。聲明和選擇器在后面進行定義。

Webkit CSS 解析器 Webkit CSS parser

Webkit使用Flex和Bison解析生成器從CSS語法文件中自動生成解析器。回憶一下解析器的介紹，Bison創建一個自底向上的解析器，Firefox使用自頂向下解析器。它們都是將每個css文件解析為樣式表對象，每個對象包含css規則，css規則對象包含選擇器和聲明對象，以及其他一些符合css語法的對象。

圖12：解析css

腳本解析 Parsing scripts

本章將介紹Javascript。

處理腳本及樣式表的順序 The order of processing scripts and style sheets

腳本

web的模式是同步的，開發者希望解析到一個script標簽時立即解析執行腳本，并阻塞文檔的解析直到腳本執行完。如果腳本是外引的，則網絡必須先請求到這個資源——這個過程也是同步的，會阻塞文檔的解析直到資源被請求到。這個模式保持了很多年，并且在html4及html5中都特別指定了。開發者可以將腳本標識為defer，以使其不阻塞文檔解析，并在文檔解析結束后執行。Html5增加了標記腳本為異步的選項，以使腳本的解析執行使用另一個線程。

預解析 Speculative parsing

Webkit和Firefox都做了這個優化，當執行腳本時，另一個線程解析剩下的文檔，并加載后面需要通過網絡加載的資源。這種方式可以使資源并行加載從而使整體速度更快。需要注意的是，預解析并不改變Dom樹，它將這個工作留給主解析過程，自己只解析外部資源的引用，比如外部腳本、樣式表及圖片。

樣式表 Style sheets

樣式表采用另一種不同的模式。理論上，既然樣式表不改變Dom樹，也就沒有必要停下文檔的解析等待它們，然而，存在一個問題，腳本可能在文檔的解析過程中請求樣式信息，如果樣式還沒有加載和解析，腳本將得到錯誤的值，顯然這將會導致很多問題，這看起來是個邊緣情況，但確實很常見。Firefox在存在樣式表還在加載和解析時阻塞所有的腳本，而chrome只在當腳本試圖訪問某些可能被未加載的樣式表所影響的特定的樣式屬性時才阻塞這些腳本。

渲染樹的構造 Render tree construction

當Dom樹構建完成時，瀏覽器開始構建另一棵樹——渲染樹。渲染樹由元素顯示序列中的可見元素組成，它是文檔的可視化表示，構建這棵樹是為了以正確的順序繪制文檔內容。

Firefox將渲染樹中的元素稱為frames，webkit則用renderer或渲染對象來描述這些元素。

一個渲染對象直到怎么布局及繪制自己及它的children。

RenderObject是Webkit的渲染對象基類，它的定義如下：

 

 

每個渲染對象用一個和該節點的css盒模型相對應的矩形區域來表示，正如css2所描述的那樣，它包含諸如寬、高和位置之類的幾何信息。盒模型的類型受該節點相關的display樣式屬性的影響（參考樣式計算章節）。下面的webkit代碼說明了如何根據display屬性決定某個節點創建何種類型的渲染對象。

 

 

元素的類型也需要考慮，例如，表單控件和表格帶有特殊的框架。

在webkit中，如果一個元素想創建一個特殊的渲染對象，它需要復寫“createRenderer”方法，使渲染對象指向不包含幾何信息的樣式對象。

渲染樹和Dom樹的關系 The render tree relation to the DOM tree

渲染對象和Dom元素相對應，但這種對應關系不是一對一的，不可見的Dom元素不會被插入渲染樹，例如head元素。另外，display屬性為none的元素也不會在渲染樹中出現（visibility屬性為hidden的元素將出現在渲染樹中）。

還有一些Dom元素對應幾個可見對象，它們一般是一些具有復雜結構的元素，無法用一個矩形來描述。例如，select元素有三個渲染對象——一個顯示區域、一個下拉列表及一個按鈕。同樣，當文本因為寬度不夠而折行時，新行將作為額外的渲染元素被添加。另一個多個渲染對象的例子是不規范的html，根據css規范，一個行內元素只能僅包含行內元素或僅包含塊狀元素，在存在混合內容時，將會創建匿名的塊狀渲染對象包裹住行內元素。

一些渲染對象和所對應的Dom節點不在樹上相同的位置，例如，浮動和絕對定位的元素在文本流之外，在兩棵樹上的位置不同，渲染樹上標識出真實的結構，并用一個占位結構標識出它們原來的位置。

 

圖12：渲染樹及對應的Dom樹

創建樹的流程 The flow of constructing the tree

Firefox中，表述為一個監聽Dom更新的監聽器，將frame的創建委派給Frame Constructor，這個構建器計算樣式（參看樣式計算）并創建一個frame。

Webkit中，計算樣式并生成渲染對象的過程稱為attachment，每個Dom節點有一個attach方法，attachment的過程是同步的，調用新節點的attach方法將節點插入到Dom樹中。

處理html和body標簽將構建渲染樹的根，這個根渲染對象對應被css規范稱為containing block的元素——包含了其他所有塊元素的頂級塊元素。它的大小就是viewport——瀏覽器窗口的顯示區域，Firefox稱它為viewPortFrame，webkit稱為RenderView，這個就是文檔所指向的渲染對象，樹中其他的部分都將作為一個插入的Dom節點被創建。

樣式計算 Style Computation

創建渲染樹需要計算出每個渲染對象的可視屬性，這可以通過計算每個元素的樣式屬性得到。

樣式包括各種來源的樣式表，行內樣式元素及html中的可視化屬性（例如bgcolor），可視化屬性轉化為css樣式屬性。

樣式表來源于瀏覽器默認樣式表，及頁面作者和用戶提供的樣式表——有些樣式是瀏覽器用戶提供的（瀏覽器允許用戶定義喜歡的樣式，例如，在Firefox中，可以通過在Firefox Profile目錄下放置樣式表實現）。

計算樣式的一些困難：

1. 樣式數據是非常大的結構，保存大量的樣式屬性會帶來內存問題

2. 如果不進行優化，找到每個元素匹配的規則會導致性能問題，為每個元素查找匹配的規則都需要遍歷整個規則表，這個過程有很大的工作量。選擇符可能有復雜的結構，匹配過程如果沿著一條開始看似正確，后來卻被證明是無用的路徑，則必須去嘗試另一條路徑。

例如，下面這個復雜選擇符

這意味著規則應用到三個div的后代div元素，選擇樹上一條特定的路徑去檢查，這可能需要遍歷節點樹，最后卻發現它只是兩個div的后代，并不使用該規則，然后則需要沿著另一條路徑去嘗試

3. 應用規則涉及非常復雜的級聯，它們定義了規則的層次

我們來看一下瀏覽器如何處理這些問題：

共享樣式數據

webkit節點引用樣式對象（渲染樣式），某些情況下，這些對象可以被節點間共享，這些節點需要是兄弟或是表兄弟節點，并且：

▲這些元素必須處于相同的鼠標狀態（比如不能一個處于hover，而另一個不是）

▲不能有元素具有id

▲標簽名必須匹配

▲class屬性必須匹配

▲對應的屬性必須相同

▲鏈接狀態必須匹配

▲焦點狀態必須匹配

▲不能有元素被屬性選擇器影響

▲元素不能有行內樣式屬性

▲不能有生效的兄弟選擇器，webcore在任何兄弟選擇器相遇時只是簡單的拋出一個全局轉換，并且在它們顯示時使整個文檔的樣式共享失效，這些包括＋選擇器和類似:first-child和:last-child這樣的選擇器。

Firefox規則樹 Firefox rule tree

Firefox用兩個樹用來簡化樣式計算－規則樹和樣式上下文樹，webkit也有樣式對象，但它們并沒有存儲在類似樣式上下文樹這樣的樹中，只是由Dom節點指向其相關的樣式。

圖14：Firefox樣式上下文樹

樣式上下文包含最終值，這些值是通過以正確順序應用所有匹配的規則，并將它們由邏輯值轉換為具體的值，例如，如果邏輯值為屏幕的百分比，則通過計算將其轉化為絕對單位。樣式樹的使用確實很巧妙，它使得在節點中共享的這些值不需要被多次計算，同時也節省了存儲空間。

所有匹配的規則都存儲在規則樹中，一條路徑中的底層節點擁有最高的優先級，這棵樹包含了所找到的 所有規則匹配的路徑（譯注：可以取巧理解為每條路徑對應一個節點，路徑上包含了該節點所匹配的所有規則）。規則樹并不是一開始就為所有節點進行計算，而是 在某個節點需要計算樣式時，才進行相應的計算并將計算后的路徑添加到樹中。

我們將樹上的路徑看成辭典中的單詞，假如已經計算出了如下的規則樹：

假如需要為內容樹中的另一個節點匹配規則，現在知道匹配的規則（以正確的順序）為B-E-I，因為我們已經計算出了路徑A-B-E-I-L，所以樹上已經存在了這條路徑，剩下的工作就很少了。

現在來看一下樹如何保存。

結構化

樣式上下文按結構劃分，這些結構包括類似border或color這樣的特定分類的樣式信息。一個結構中的所有特性不是繼承的就是非繼承的，對繼承的特性，除非元素自身有定義，否則就從它的parent繼承。非繼承的特性（稱為reset特性）如果沒有定義，則使用默認的值。

樣式上下文樹緩存完整的結構（包括計算后的值），這樣，如果底層節點沒有為一個結構提供定義，則使用上層節點緩存的結構。

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

當為一個特定的元素計算樣式時，首先計算出規則樹中的一條路徑，或是使用已經存在的一條，然后使 用路徑中的規則去填充新的樣式上下文，從樣式的底層節點開始，它具有最高優先級（通常是最特定的選擇器），遍歷規則樹，直到填滿結構。如果在那個規則節點 沒有定義所需的結構規則，則沿著路徑向上，直到找到該結構規則。

如果最終沒有找到該結構的任何規則定義，那么如果這個結構是繼承型的，則找到其在內容樹中的parent的結構，這種情況下，我們也成功的共享了結構；如果這個結構是reset型的，則使用默認的值。

如果特定的節點添加了值，那么需要做一些額外的計算以將其轉換為實際值，然后在樹上的節點緩存該值，使它的children可以使用。

當一個元素和它的一個兄弟元素指向同一個樹節點時，完整的樣式上下文可以被它們共享。

來看一個例子：假設有下面這段html

 

 

以及下面這些規則

 

 

簡化下問題，我們只填充兩個結構——color和margin，color結構只包含一個成員－顏色，margin結構包含四邊。

生成的規則樹如下（節點名：指向的規則）

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

假設我們解析html，遇到第二個div標簽，我們需要為這個節點創建樣式上下文，并填充它的樣式結構。

我們進行規則匹配，找到這個div匹配的規則為1、2、6，我們發現規則樹上已經存在了一條我們可以使用的路徑1、2，我們只需為規則6新增一個節點添加到下面（就是規則樹中的F）。

然后創建一個樣式上下文并將其放到上下文樹中，新的樣式上下文將指向規則樹中的節點F。

現在我們需要填充這個樣式上下文，先從填充margin結構開始，既然最后一個規則節點沒有添加margin結構，沿著路徑向上，直到找到緩存的前面插入節點計算出的結構，我們發現B是最近的指定margin值的節點。因為已經有了color結構的定義，所以不能使用緩存的結構，既然color只有一個屬性，也就不需要沿著路徑向上填充其他屬性。計算出最終值（將字符串轉換為RGB等），并緩存計算后的結構。

第二個span元素更簡單，進行規則匹配后發現它指向規則G，和前一個span一樣，既然有兄弟節點指向同一個節點，就可以共享完整的樣式上下文，只需指向前一個span的上下文。

因為結構中包含繼承自parent的規則，上下文樹做了緩存（color特性是繼承來的，但Firefox將其視為reset并在規則樹中緩存）。

例如，如果我們為一個paragraph的文字添加規則：

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

那么這個p在內容樹中的子節點div，會共享和它parent一樣的font結構，這種情況發生在沒有為這個div指定font規則時。

Webkit中，并沒有規則樹，匹配的聲明會被遍歷四次，先是應用非important的高優先級屬性（之所以先應用這些屬性，是因為其他的依賴于它們－比如display），其次是高優先級important的，接著是一般優先級非important的，最后是一般優先級important的規則。這樣，出現多次的屬性將被按照正確的級聯順序進行處理，最后一個生效。

總結一下，共享樣式對象（結構中完整或部分內容）解決了問題1和3，Firefox的規則樹幫助以正確的順序應用規則。

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

樣式規則有幾個來源：

· 外部樣式表或style標簽內的css規則

· 行內樣式屬性

· html可視化屬性（映射為相應的樣式規則）

后面兩個很容易匹配到元素，因為它們所擁有的樣式屬性和html屬性可以將元素作為key進行映射。

就像前面問題2所提到的，css的規則匹配可能很狡猾，為了解決這個問題，可以先對規則進行處理，以使其更容易被訪問。

解析完樣式表之后，規則會根據選擇符添加一些hash映射，映射可以是根據id、class、標簽名或是任何不屬于這些分類的綜合映射。如果選擇符為id，規則將被添加到id映射，如果是class，則被添加到class映射，等等。

這個處理是匹配規則更容易，不需要查看每個聲明，我們能從映射中找到一個元素的相關規則，這個優化使在進行規則匹配時減少了95＋％的工作量。

來看下面的樣式規則：

p.error {color:red}

#messageDiv {height:50px}

div {margin:5px}

第一條規則將被插入class映射，第二條插入id映射，第三條是標簽映射。

下面這個html片段：

<p class=”error”>an error occurred </p>

<div id=” messageDiv”>this is a message</div>

我們首先找到p元素對應的規則，class映射將包含一個“error”的key，找到p.error的規則，div在id映射和標簽映射中都有相關的規則，剩下的工作就是找出這些由key對應的規則中哪些確實是正確匹配的。

例如，如果div的規則是

table div {margin:5px}

這也是標簽映射產生的，因為key是最右邊的選擇符，但它并不匹配這里的div元素，因為這里的div沒有table祖先。

Webkit和Firefox都會做這個處理。

以正確的級聯順序應用規則

樣式對象擁有對應所有可見屬性的屬性，如果特性沒有被任何匹配的規則所定義，那么一些特性可以從parent的樣式對象中繼承，另外一些使用默認值。

這個問題的產生是因為存在不止一處的定義，這里用級聯順序解決這個問題。

樣式表的級聯順序

一個樣式屬性的聲明可能在幾個樣式表中出現，或是在一個樣式表中出現多次，因此，應用規則的順序至關重要，這個順序就是級聯順序。根據css2的規范，級聯順序為（從低到高）：

1. 瀏覽器聲明

2. 用戶聲明

3. 作者的一般聲明

4. 作者的important聲明

5. 用戶important聲明

瀏覽器聲明是最不重要的，用戶只有在聲明被標記為important時才會覆蓋作者的聲明。具有同等級別的聲明將根據specifity以及它們被定義時的順序進行排序。Html可視化屬性將被轉換為匹配的css聲明，它們被視為最低優先級的作者規則。

Specifity

Css2規范中定義的選擇符specifity如下：

· 如果聲明來自style屬性，而不是一個選擇器的規則，則計1，否則計0（＝a）

· 計算選擇器中id屬性的數量（＝b）

· 計算選擇器中class及偽類的數量（＝c）

· 計算選擇器中元素名及偽元素的數量（＝d）

連接a－b－c－d四個數量（用一個大基數的計算系統）將得到specifity。這里使用的基數由分類中最高的基數定義。例如，如果a為14，可以使用16進制。不同情況下，a為17時，則需要使用阿拉伯數字17作為基數，這種情況可能在這個選擇符時發生html body div div …（選擇符中有17個標簽，一般不太可能）。

一些例子：

 

 

規則排序

規則匹配后，需要根據級聯順序對規則進行排序，webkit先將小列表用冒泡排序，再將它們合并為一個大列表，webkit通過為規則復寫“>”操作來執行排序：

 

 

逐步處理 Gradual process

webkit使用一個標志位標識所有頂層樣式表都已加載，如果在attch時樣式沒有完全加載，則放置占位符，并在文檔中標記，一旦樣式表完成加載就重新進行計算。

布局 Layout

當渲染對象被創建并添加到樹中，它們并沒有位置和大小，計算這些值的過程稱為layout或reflow。

Html使用基于流的布局模型，意味著大部分時間，可以以單一的途徑進行幾何計算。流中靠后的元素并不會影響前面元素的幾何特性，所以布局可以在文檔中從右向左、自上而下的進行。也存在一些例外，比如html tables。

坐標系統相對于根frame，使用top和left坐標。

布局是一個遞歸的過程，由根渲染對象開始，它對應html文檔元素，布局繼續遞歸的通過一些或所有的frame層級，為每個需要幾何信息的渲染對象進行計算。

根渲染對象的位置是0,0，它的大小是viewport－瀏覽器窗口的可見部分。

所有的渲染對象都有一個layout或reflow方法，每個渲染對象調用需要布局的children的layout方法。

Dirty bit 系統

為了不因為每個小變化都全部重新布局，瀏覽器使用一個dirty bit系統，一個渲染對象發生了變化或是被添加了，就標記它及它的children為dirty－需要layout。存在兩個標識－dirty及children are dirty，children are dirty說明即使這個渲染對象可能沒問題，但它至少有一個child需要layout。

全局和增量 layout

當layout在整棵渲染樹觸發時，稱為全局layout，這可能在下面這些情況下發生：

1. 一個全局的樣式改變影響所有的渲染對象，比如字號的改變

2. 窗口resize

layout也可以是增量的，這樣只有標志為dirty的渲染對象會重新布局（也將導致一些額外的布局）。增量 layout會在渲染對象dirty時異步觸發，例如，當網絡接收到新的內容并添加到Dom樹后，新的渲染對象會添加到渲染樹中。

圖20：增量 layout

異步和同步layout

增量layout的過程是異步的，Firefox為增量layout生成了reflow隊列，以及一個調度執行這些批處理命令。Webkit也有一個計時器用來執行增量layout－遍歷樹，為dirty狀態的渲染對象重新布局。

另外，當腳本請求樣式信息時，例如“offsetHeight”，會同步的觸發增量布局。

全局的layout一般都是同步觸發。

有些時候，layout會被作為一個初始layout之后的回調，比如滑動條的滑動。

優化

當一個layout因為resize或是渲染位置改變（并不是大小改變）而觸發時，渲染對象的大小將會從緩存中讀取，而不會重新計算。

一般情況下，如果只有子樹發生改變，則layout并不從根開始。這種情況發生在，變化發生在元素自身并且不影響它周圍元素，例如，將文本插入文本域（否則，每次擊鍵都將觸發從根開始的重排）。

layout過程

layout一般有下面這幾個部分：

1. parent渲染對象決定它的寬度

2. parent渲染對象讀取chilidren，并：

1. 放置child渲染對象（設置它的x和y）

2. 在需要時（它們當前為dirty或是處于全局layout或者其他原因）調用child渲染對象的layout，這將計算child的高度

3. parent渲染對象使用child渲染對象的累積高度，以及margin和padding的高度來設置自己的高度－這將被parent渲染對象的parent使用

4. 將dirty標識設置為false

Firefox使用一個“state”對象（nsHTMLReflowState）做為參數去布局（firefox稱為reflow），state包含parent的寬度及其他內容。

Firefox布局的輸出是一個“metrics”對象（nsHTMLReflowMetrics）。它包括渲染對象計算出的高度。

寬度計算

渲染對象的寬度使用容器的寬度、渲染對象樣式中的寬度及margin、border進行計算。例如，下面這個div的寬度：

webkit中寬度的計算過程是（RenderBox類的calcWidth方法）：

· 容器的寬度是容器的可用寬度和0中的最大值，這里的可用寬度為：contentWidth=clientWidth()-paddingLeft()-paddingRight()，clientWidth和clientHeight代表一個對象內部的不包括border和滑動條的大小

· 元素的寬度指樣式屬性width的值，它可以通過計算容器的百分比得到一個絕對值

· 加上水平方向上的border和padding

到這里是最佳寬度的計算過程，現在計算寬度的最大值和最小值，如果最佳寬度大于最大寬度則使用最大寬度，如果小于最小寬度則使用最小寬度。最后緩存這個值，當需要layout但寬度未改變時使用。

Line breaking

當一個渲染對象在布局過程中需要折行時，則暫停并告訴它的parent它需要折行，parent將創建額外的渲染對象并調用它們的layout。

繪制 Painting

繪制階段，遍歷渲染樹并調用渲染對象的paint方法將它們的內容顯示在屏幕上，繪制使用UI基礎組件，這在UI的章節有更多的介紹。

全局和增量

和布局一樣，繪制也可以是全局的－繪制完整的樹－或增量的。在增量的繪制過程中，一些渲染對象以不影響整棵樹的方式改變，改變的渲染對象使其在屏幕上的矩形區域失效，這將導致操作系統將其看作dirty區域，并產生一個paint事件，操作系統很巧妙的處理這個過程，并將多個區域合并為一個。Chrome中，這個過程更復雜些，因為渲染對象在不同的進程中，而不是在主進程中。Chrome在一定程度上模擬操作系統的行為，表現為監聽事件并派發消息給渲染根，在樹中查找到相關的渲染對象，重繪這個對象（往往還包括它的children）。

繪制順序

css2定義了繪制過程的順序－http://www.w3.org/TR/CSS21/zindex.html。這個就是元素壓入堆棧的順序，這個順序影響著繪制，堆棧從后向前進行繪制。

一個塊渲染對象的堆棧順序是：

1. 背景色

2. 背景圖

3. border

4. children

5. outline

Firefox顯示列表

Firefox讀取渲染樹并為繪制的矩形創建一個顯示列表，該列表以正確的繪制順序包含這個矩形相關的渲染對象。

用這樣的方法，可以使重繪時只需查找一次樹，而不需要多次查找——繪制所有的背景、所有的圖片、所有的border等等。

Firefox優化了這個過程，它不添加會被隱藏的元素，比如元素完全在其他不透明元素下面。

Webkit矩形存儲

重繪前，webkit將舊的矩形保存為位圖，然后只繪制新舊矩形的差集。

動態變化

瀏覽器總是試著以最小的動作響應一個變化，所以一個元素顏色的變化將只導致該元素的重繪，元素位置的變化將大致元素的布局和重繪，添加一個Dom節點，也會大致這個元素的布局和重繪。一些主要的變化，比如增加html元素的字號，將會導致緩存失效，從而引起整數的布局和重繪。

渲染引擎的線程

渲染引擎是單線程的，除了網絡操作以外，幾乎所有的事情都在單一的線程中處理，在Firefox和Safari中，這是瀏覽器的主線程，Chrome中這是tab的主線程。

網絡操作由幾個并行線程執行，并行連接的個數是受限的（通常是2－6個）。

事件循環

瀏覽器主線程是一個事件循環，它被設計為無限循環以保持執行過程的可用，等待事件（例如layout和paint事件）并執行它們。下面是Firefox的主要事件循環代碼。

 

 

CSS2 可視模型 CSS2 visual module

畫布 The Canvas

根據CSS2規范，術語canvas用來描述格式化的結構所渲染的空間——瀏覽器繪制內容的地方。畫布對每個維度空間都是無限大的，但瀏覽器基于viewport的大小選擇了一個初始寬度。

根據http://www.w3.org/TR/CSS2/zindex.html的定義，畫布如果是包含在其他畫布內則是透明的，否則瀏覽器會指定一個顏色。

CSS盒模型

CSS盒模型描述了矩形盒，這些矩形盒是為文檔樹中的元素生成的，并根據可視的格式化模型進行布局。每個box包括內容區域（如圖片、文本等）及可選的四周padding、border和margin區域。

每個節點生成0－n個這樣的box。

所有的元素都有一個display屬性，用來決定它們生成box的類型，例如：

block－生成塊狀box

inline－生成一個或多個行內box

none－不生成box

默認的是inline，但瀏覽器樣式表設置了其他默認值，例如，div元素默認為block。可以訪問http://www.w3.org/TR/CSS2/sample.html查看更多的默認樣式表示例。

定位策略 Position scheme

這里有三種策略：

1. normal－對象根據它在文檔的中位置定位，這意味著它在渲染樹和在Dom樹中位置一致，并根據它的盒模型和大小進行布局

2. float－對象先像普通流一樣布局，然后盡可能的向左或是向右移動

3. absolute－對象在渲染樹中的位置和Dom樹中位置無關

static和relative是normal，absolute和fixed屬于absolute。

在static定位中，不定義位置而使用默認的位置。其他策略中，作者指定位置——top、bottom、left、right。

Box布局的方式由這幾項決定：box的類型、box的大小、定位策略及擴展信息（比如圖片大小和屏幕尺寸）。

Box類型

Block box：構成一個塊，即在瀏覽器窗口上有自己的矩形

Inline box：并沒有自己的塊狀區域，但包含在一個塊狀區域內

block一個挨著一個垂直格式化，inline則在水平方向上格式化。

Inline盒模型放置在行內或是line box中，每行至少和最高的box一樣高，當box以baseline對齊時——即一個元素的底部和另一個box上除底部以外的某點對齊，行高可以比最高的box高。當容器寬度不夠時，行內元素將被放到多行中，這在一個p元素中經常發生。

定位 Position

Relative

相對定位——先按照一般的定位，然后按所要求的差值移動。

Floats

一個浮動的box移動到一行的最左邊或是最右邊，其余的box圍繞在它周圍。下面這段html：

 

 

將顯示為：

Absolute和Fixed

這種情況下的布局完全不顧普通的文檔流，元素不屬于文檔流的一部分，大小取決于容器。Fixed時，容器為viewport（可視區域）。

圖17：fixed

注意－fixed即使在文檔流滾動時也不會移動。

Layered representation

這個由CSS屬性中的z-index指定，表示盒模型的第三個大小，即在z軸上的位置。Box分發到堆棧中（稱為堆棧上下文），每個堆棧中靠后的元素將被較早繪制，棧頂靠前的元素離用戶最近，當發生交疊時，將隱藏靠后的元素。堆棧根據z-index屬性排序，擁有z-index屬性的box形成了一個局部堆棧，viewport有外部堆棧，例如：

 

 

結果是：

雖然綠色div排在紅色div后面，可能在正常流中也已經被繪制在后面，但z-index有更高優先級，所以在根box的堆棧中更靠前。

國外也有網友根據瀏覽器的工作原理繪制了幾張工作流程圖，方便大家通過簡易的圖片來了解這個辛苦的過程：