簡單介紹瀏覽器渲染引擎情況

? ?很多人就只會用瀏覽器，不知道瀏覽器的工作原理或者說瀏覽器最核心的東西，瀏覽器的內核是最核
心的東西，也叫做渲染引擎，那這個東西到底是干嘛的呢，下面本教程就為大家好好介紹一下：

　l 主流瀏覽器內核介紹

　　主流瀏覽器內核分類：瀏覽器內核種類繁多，商用的加上非商業的免費內核，大約有10款以上甚至
更多，不過通常比較常見的大約只有以下4種，下面就簡單介紹一下。

　　(1)Trident

　　Trident(又稱為MSHTML)，是微軟的Windows搭載的網頁瀏覽器——Internet?
Explorer瀏覽器使用的內核(俗稱IE內核)，該內核程序在1997年的IE?
4中首次被采用，之后不斷地加入新的技術并隨著新版本的IE發布。Trident實際上是一款開放的內核，

Trident引擎被設計成一個軟件組件(模塊)，使得其他軟件開發人員很容易將網頁瀏覽功能加到他們自行

開發的應用程序里，其接口內核設計相當成熟，因此才涌現出許多采用IE內核而非IE的瀏覽器(如

Maxthon、軟媒的閃游瀏覽器、騰訊的TT、GreenBrowser等)，但是Trident只能用于Windows平臺。

　　由于IE本身的“壟斷性”而使得Trident內核在很長時間內都是一家獨大，微軟也在相當長一段時間

內都沒有更新Trident內核，這就導致了兩個后果——一是Trident內核曾經幾乎與W3C標準脫節;二是

Trident內核的大量Bug等安全性問題沒有得到及時解決。目前，微軟對Trident排版引擎做了重大變動，

除了加入新的技術之外，還增加了對網頁標準的支持。盡管這些變動已經在相當大的程度上落后了其他

的排版引擎，如Gecko、WebCore、KHTML及Presto。

　　(2)Gecko

　　Gecko是開放源代碼、以C++編寫的網頁排版引擎，目前被Mozilla家族網頁瀏覽器以及Netscape?
6以后版本瀏覽器所使用。這款軟件原本是由網景通訊公司開發的，現在則由Mozilla基金會維護。由于

Gecko的特點是代碼完全公開，因此，其可開發程度很高，全世界的程序員都可以為其編寫代碼，增加功

能。因為這是個開源內核，因此受到許多人的青睞，采用Gecko內核的瀏覽器也很多，這也是Gecko內核

雖然年輕但市場占有率能夠迅速提高的重要原因。

　　Gecko排版引擎提供了一個豐富的程序界面以供與互聯網相關的應用程序使用，例如網頁瀏覽器、

HTML編輯器、客戶端/服務器等。雖然最初的主要對象是Mozilla的衍生產品，如Netscape和Mozilla?
Firefox，但是現在已有很多其他軟件利用這個排版引擎。此外Gecko也是一個跨平臺內核，可以在

Windows、BSD、Linux和Mac OS X中使用。 ?
========

瀏覽器是怎樣工作的：渲染引擎，HTML解析（連載二）

渲染引擎
渲染引擎的職責是……渲染，也就是把請求的內容顯示到瀏覽器屏幕上。

默認情況下渲染引擎可以顯示HTML，XML文檔以及圖片。 通過插件（瀏覽器擴展）它可以顯示其它類型

文檔。比如使用PDF viewer插件顯示PDF文件。我們會在一個專門的章節討論插件與擴展。在這一節我們

將專注渲染引擎的主要用途——顯示用CSS格式化的HTML與圖片。

各種渲染引擎
我們提到的Firefox, Safari兩種瀏覽器構建于兩種渲染引擎之上：Firefox使用Gecko —— Mozilla自

家的渲染引擎；Safari 和 Chrome 都使用 Webkit。

Webkit 是一個開源的渲染引擎，它源自Linux平臺上的一個引擎，經過Apple公司的修改可以支持Mac與

Windows平臺。更多信息可以參考： http://webkit.org/ 。

主要流程
渲染引擎開始于從網絡層獲取請求內容，一般是不超過8Ｋ的數據塊。接下來就是渲染引擎的基本工作流

程：



圖 2：渲染引擎的基本工作流程（解析ＨＴＭＬ構建ＤＯＭ樹，渲染樹構建，渲染樹布局，繪制渲染樹

）。
渲染引擎會解析ＨＴＭＬ文檔并把標簽轉換成內容樹中的ＤＯＭ節點。它會解析style元素和外部文件中

的樣式數據。樣式數據和ＨＴＭＬ中的顯示控制將共同用來創建另一棵樹——渲染樹。

渲染樹包含帶有顏色，尺寸等顯示屬性的矩形。這些矩形的順序與顯示順序一致。

渲染樹構建完成后就是”布局“處理，也就是確定每個節點在屏幕上的確切顯示位置。 下一個步驟是?

繪制 —— 遍歷渲染樹并用ＵＩ后端層將每一個節點繪制出來。

一定要理解這是一個緩慢的過程，為了更好的用戶體驗，渲染引擎會嘗試盡快的把內容顯示出來。它不

會等到所有ＨＴＭＬ都被解析完才創建并布局渲染樹。它會 在處理后續內容的同時把處理過的局部內容

先展示出來。

主要流程示例

圖 3：Webkit主要流程

圖 4：Mozilla的Gecko渲染引擎主要流程(3.6)
從圖3和圖4中可以看出，盡管Webkit與Gecko使用略微不同的術語，這個過程還是基本相同的。
Gecko 里把格式化好的可視元素稱做“幀樹”（Frame tree）。每個元素就是一個幀（frame）。?

Webkit 則使用”渲染樹”這個術語，渲染樹由”渲染對象”組成。Webkit 里使用”layout”表示元素

的布局，Gecko則稱為”Reflow”。Webkit使用”Attachment”來連接DOM節點與可視化信息以構建渲染

樹。一個非語義上的小差別是Gecko在ＨＴＭＬ與ＤＯＭ樹之間有一個附加的層 ，稱作”content sink

”，是創建ＤＯＭ對象的工廠。我們會討論流程中的每一部分。

解析
因為解析是渲染引擎中一個很重要的處理，我們會講的略深入一些。讓我們從一個小的解析介紹開始。

解析一個文檔意味著把它翻譯成有意義的結構以供代碼使用。解析的結果通常是一個表征文檔的由節點

組成的樹，稱為解析樹或句法樹。

示例——解析表達式”2 + 3 – 1″可以返回下面的樹：


圖 5：數學表達式樹節點
語法

解析是基于文檔所遵循的語法規則——書寫所用的語言或格式——來進行的。每一種可以解析的格式必

須由確定的語法與詞匯組成。這被稱之為上下文無關語法。 人類語言并非此種語言，所以不能用常規的

解析技術來解析。

解析器——詞法分析器組合

解析器有兩個處理過程——詞法分析與句法分析。

詞法分析負責把輸入切分成符號序列，符號是語言的詞匯——由該語言所有合法的單詞組成。

句法分析是對該語言句法法則的應用。

解析器通常把工作分給兩個組件——分詞程序負責把輸入切分成合法符號序列，解析程序負責按照句法

規則分析文檔結構和構建句法樹。詞法分析器知道如何過濾像空格，換行之類的無關字符。


圖 6：從源文檔到解析樹（文檔，詞法分析，句法分析，解析樹）。
解析過程是交互式的。解析器通常會從詞法分析器獲取新符號并嘗試匹配句法規則。如果匹配成功，就

在句法樹上創建相應的節點，并繼續從詞法分析器獲取下一個符號。如果沒有匹配的規則，解析器會內

部保存這個符號，并繼續從詞法分析器獲取符號，直到內部保存的所有符號能夠成功匹配一個規則。如

果最終無法匹配，解析器會拋出異常。這意味著文檔無效，含有句法錯誤。

轉換

多數情況下解析樹并非最終結果。解析經常是為了從輸入文檔轉換成另外一種格式。比如編譯器要把源

碼編譯成機器碼，會首先解析成解析樹，再把解析樹轉換成機器碼。

圖 7：編譯過程（源碼，解析，解析樹，轉換，機器碼）。
解析示例

在圖5中我們構建了一個數學表達式解析樹。讓我們來試著定義一個簡單的數學語言并看看解析是如何進

行的。

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

句法：

句法塊由表達式，術語及操作符組成。
我們的語言可以包含任意數量表達式。
表達式定義為術語緊跟著操作符，再跟另外一個術語。
操作符是加號或減號。
術語可以是整數或表達式。
讓我們分析輸入”2 + 3 – 1″。

第一個符合規則的子字符串是”2″，根據規則#5它是一個術語。第二個匹配是”2 + 3″，符合第二條

規則——一個術語緊跟一個操作符再跟另外一個術語。下一個匹配出現在輸入結束時。”2 + 3 – 1″

是一個表達式，因為我們已知“2+3”是一個術語，所以符合第二條規則。 “2 + + “不會匹配任何規

則，所以是無效的輸入。

詞法與句法的合法性定義

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

比如我們的語言可以定義為:

INTEGER :0|[1-9][0-9]*
PLUS : +
MINUS: -
如你所見，整型是由正則表達式定義的。

句法常用BNF格式定義，我們的語言被定義為：

expression := ?term ?operation ?term
operation := ?PLUS | MINUS
term := INTEGER | expression
我們說過常規解析器只能解析上下文無關語法的語言。這種語言的一個直覺的定義是它的句法可以用BNF

完整的表達。其規范定義請參考 http://en.wikipedia.org/wiki/Context-free_grammar

解析器的類型

解析器有兩種基本類型——自上而下解析器和自下而上解析器。主觀上可以認為自上而下的解析器從上

層句法結構開始嘗試匹配句法；自下而上的則從輸入開始，慢慢轉換成句法規則，從底層規則開始，直

到上層規則全部匹配。

讓我們看看這兩種解析器將怎樣解析我們的例子：

自上而下解析器從上層規則開始，它會把”2 + 3″定義為表達式，然后定義”2 + 3 – 1″為表達式(

定義表達式的過程中也會匹配其它規則，但起點是最高級別規則)。

自下而上的解析器會掃描輸入，直到有匹配的規則，它會把輸入替換成規則。這樣一直到輸入結束。部

分匹配的規則會放入解析堆棧。

Stack Input
2 + 3 – 1
term + 3 – 1
term operation 3 – 1
expression – 1
expression operation 1
expression
這種自下而上的解析器叫作移位歸約解析器，因為輸入被向右移動(想象一下一個指針從指向輸入開始逐


漸向右移動) 并逐漸歸約到句法樹。


自動創建解析器


有一些工具可以為你創建解析器，它們通常稱為解析器生成器。你只需要提供語法——詞匯與句法規則


——它就能生成一個可以工作的解析器。創建解析器需要對解析器有深入的了解，并且手動創建一個優


化的解析器并不容易，所以解析器生成工具很有用。


Webkit使用兩款知名的解析器生成工具：Flex用于創建詞法分析器，Bison用于創建解析器 (你也許會看

到它們以Lex和Yacc的名字存在)。Flex的輸入文件是符號的正則表達式定義，Bison的輸入文件是ＢＮＦ

格式的句法定義。

HTML解析器
ＨＴＭＬ解析器的工作是解析ＨＴＭＬ標記到解析樹。

HTML語法定義

ＨＴＭＬ的詞匯與句法定義在w3c組織創建的規范中。當前版本是HTML4，HTML5的工作正在進行中。


不是上下文無關語法


在對解析器的介紹中看到，語法可以用類似ＢＮＦ的格式規范地定義。不幸的是所有常規解析器的討論


都不適用于ＨＴＭＬ（我提及它們并不是為了娛樂，它們可以用于解析CSS和JavaScript）。HTML無法用


解析器所需的上下文無關的語法來定義。過去HTML格式規范由DTD (Document Type Definition)來定義


，但它不是一個上下文無關語法。


HTML與XML相當接近。XML有許多可用的解析器。HTML還有一個XML變種叫XHTML，那么它們主要區別在哪


里呢？區別在于HTML應用更加”寬容”，它容許你漏掉一些開始或結束標簽等。它整個是一個“軟”句


法，不像XML那樣嚴格死板。 總的來說這一看似細微的差別造成了兩個不同的世界。一方面這使得HTML


很流行，因為它包容你的錯誤，使網頁作者的生活變得輕松。另一方面，它使編寫語法格式變得困難。


所以綜合來說，ＨＴＭＬ解析并不簡單，現成的上下文相關解析器搞不定，ＸＭＬ解析器也不行。

HTML DTD

HTML的定義使用DTD文件。這種格式用來定義SGML族語言，它包含對所有允許的元素的定義，包括它們的

屬性和層級關系。如我們前面所說，HTML DTD構不成上下文無關語法。

DTD有幾種不同類型。嚴格模式完全尊守規范，但其它模式為了向前兼容可能包含對早期瀏覽器所用標簽

的支持。當前的嚴格模式ＤＴＤ：http://www.w3.org/TR/html4/strict.dtd

DOM

解析器輸出的樹是由ＤＯＭ元素和屬性節點組成的。DOM的全稱為：Document Object Model。它是ＨＴ

ＭＬ文檔的對象化描述，也是ＨＴＭＬ元素與外界（如Javascript）的接口。

ＤＯＭ與標簽幾乎有著一一對應的關系，如下面的標簽

<html>
<body>
<p>
Hello World
</p>
<div> <img src="example.png"/></div>
</body>
</html>
會被轉換成如的ＤＯＭ樹：


Figure 8: DOM tree of the example markup
?


與HTML一樣，DOM規范也由w3c組織制訂。參考：http://www.w3.org/DOM/DOMTR. 這是一個操作文檔的通


用規范。有一個專門的模塊定義HTML特有元素: http://www.w3.org/TR/2003/REC-DOM-Level-2-HTML-


20030109/idl-definitions.html.


當我們說樹中包含ＤＯＭ節點時，意思就是這個樹是由實現了ＤＯＭ接口的元素組成。這些實現包含了


其它一些瀏覽器內部所需的屬性。


解析算法

如我們前面看到的，HTML無法使用自上而下或自下而上的解析器來解析。


理由如下：


語言的寬容特點
瀏覽器需要對無效HTML提供容錯性的事實。
解析過程的反復。通常解析過程中源碼不會變化。但在HTML中，script標簽包含”document.write”時


可以添加內容，即解析過程實際上還會改變源碼。
瀏覽器創建了自己的解析器來解析HTML文檔。


HTML5規范里對解析算法有具體的說明，解析由兩部分組成：分詞與構建樹。


分詞屬于詞法分析部分，它把輸入解析成符號序列。在HTML中符號就是開始標簽，結束標簽，屬性名稱


和屬生值。


分詞器識別這些符號并將其送入樹構建者，然后繼續分析處理下一個符號，直到輸入結束。


圖 6: HTML解析流程 (源自HTML5規范)
?
分詞算法

算法的輸出是HTML符號。算法可以用狀態機來描述。 每一個狀態從輸入流中消費一個或多個字符，并根

據它們更新下一狀態。決策受當前符號狀態和樹的構建狀態影響。這意味著同樣的字符可能會產生不同

的結果，取決于當前的狀態。算法太復雜，我們用一個例子來看看它的原理。

基礎示例，分析下面的標簽:

<html>
<body>
Hello world
</body>
</html>
初始狀態是”Data state”，當遇到”<“時狀態改為“Tag open state”。吃掉”a-z”字符組成的符

號后產生了”Start tag token”，狀態變更為“Tag name state”。我們一直保持此狀態，直到遇到”


>”。每個字符都被追加到新的符號名上。在我們的例子中，解出的符號就是”html”。


當碰到”>”時，當前符號完成，狀態改回“Data state”?！?lt;body>”標簽將會以同樣的方式處理。現


在”html”與”body”標簽都完成了，我們回到“Data state”狀態。吃掉”H”（”Hello world”第

一個字母）時會產生一個字符符號，直到碰到”</body>”的”<“符號，我們就完成了一個字符符


號”Hello world”。

現在我們回到“Tag open state”狀態。吃掉下一個輸入”/”時會產生一個”end tag token”并變更

為“Tag name state”狀態。同樣，此狀態保持到我們碰到”>”時。這時新標簽符號完成，我們又回到


“Data state”。同樣”</html>”也會被這樣處理。




圖 9: 示例輸入源的分詞處理
?


樹的構建算法


當解析器被創建時，文檔對象也被創建了。在樹的構建過程中DOM樹的根節點（Documen）將被修改，元


素被添加到上面去。每個分詞器完成的節點都會被樹構建器處理。規范中定義了每一個符號與哪個DOM對


象相關。除了把元素添加到DOM樹外，它還會被添加到一個開放元素堆棧。這個堆棧用于糾正嵌套錯誤和


標簽未關閉錯誤。這個算法也用狀態機描述，它的狀態叫做”insertion modes”。


讓我們看看下面輸入的樹構建過程：

<html>
<body>
Hello world
</body>
</html>
樹的構建過程中，輸入就是分詞過程中得到的符號序列。第一個模式叫“initial mode”。接收 html?


符號后會變成“before html”模式并重新處理此模式中的符號。這會創建一個HTMLHtmlElement元素并

追加到根文檔節點。


然后狀態改變為“before head”。我們收到”body”時，會隱式創建一個HTMLHeadElement，盡管我們


沒有這個標簽，它也會被創建并添加到樹中。


現在我們進入“in head”模式，然后是“after head”，Body會被重新處理，創建HTMLBodyElement元


素并插入，然后進入“in body”模式。


字符符號”Hello world”收到后會創建一個”Text”節點，所有字符都被一一追加到上面。


收到body結束標簽后進入 “after body” 模式，收到html結束標簽后進入“after after body”模式


。所有符號處理完后將終止解析。


圖 10: 示例HTML樹的構建
解析結束后的動作

在這一階段瀏覽器會把文檔標記為交互模式，并開始解析deferred模式的script?！眃eferred”意味著


腳本應該在文檔解析完成后執行。腳本處理完成后將進入”complete”狀態，”load”事件發生。


HTML5規范中包含了完整的算法： http://www.w3.org/TR/html5/syntax.html#html-parser


瀏覽器的容錯


你永遠不會看到HTML頁面語法錯誤。瀏覽器會修正錯誤并繼續?？纯聪旅娴睦?#xff1a;


<html>
? <mytag>
? </mytag>
? <div>
? <p>
? </div>
? Really lousy HTML
? </p>
</html>
我一定違背了幾百萬條規則（”my tag”是非法標簽，”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);
}
過深的元素層級

注釋不言自喻：

www.liceo.edu.mx是一個層級過深的典型，它用大量的<b>嵌套到1500個標簽的深度。我們只允許同一標

簽連續出現20次，超過的話，所有此標簽都會被忽略。
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
我們永遠不關閉tag，因為有些愚蠢的網頁在文檔真正結束之前就關閉了它。
讓我們用end()來關閉標簽。
if (t->tagName == htmlTag || t->tagName == bodyTag )
? ? ? ? return;
所以網頁作者們小心了，除非你想寫一個Webkit容錯的示例代碼，否則請按正確格式書寫HTML。
========

了解瀏覽器如何工作—渲染引擎

從基礎架構上我們也可以看到瀏覽器的重頭戲其實在于渲染引擎(又稱排版引擎)，很多頁面兼容性問題


的根源可以說也皆來源于此。好了，那我們深入到渲染引擎內部仔細看一下吧。


從基礎架構上我們也可以看到瀏覽器的重頭戲其實在于渲染引擎(又稱排版引擎)，很多頁面兼容性問題


的根源可以說也皆來源于此。360瀏覽器HTML5跑分再高（http://html5test.com/），UI與交互再怎么不


一樣，內核還是一樣的。好了，那我們深入到渲染引擎內部仔細看一下吧。
渲染引擎（the rendering engine）簡述
渲染引擎的職責，正如字面上的意思就是負責從服務器端返回的HTML，XML，或者IMAGES等資源的渲染工


作并顯示給最終用戶。通過瀏覽器 插件（plug-in or browser extension）技術，它也能顯示一些其他


文檔格式的資源，如PDF，后期的文章會針對這種技術進行一下說明，本章重點描述渲染引擎的首要功能


，即通 過渲染引擎顯示出經過CSS樣式化的HTML和圖片結果。
前面已經介紹過，firefox,chrome,safari 包括了兩種渲染引擎，火狐瀏覽器使用gecko，safari跟


chrome（后來opera跟進）使用webkit. Webkit是一個開源的渲染引擎，起初只能用于linux平臺，后來


蘋果公司apple對其源代碼進行了擴展改造，使其能運行與mac跟windows 平臺，后起之秀chrome對其有


進行了一些列擴充與推廣，使其越來越成為標準流行的渲染網頁引擎，webkit詳細介紹可參見?


http://webkit.org/。
基本渲染過程
用戶請求的資源通過瀏覽器的網絡層到達渲染引擎后，渲染工作開始。每次渲染文檔通常不會超過8K的


數據塊，其中基礎的渲染過程如下圖所示: ? ? ?


渲染引擎首先解析HTML文檔，轉換為一棵DOM樹，此為第一步。接下來不管是內聯式，外聯式還是嵌入式


引入的CSS樣式也會被解析，渲染出另 外一棵用于渲染DOM樹的樹-渲染樹(render tree) ，渲染樹包含


帶有顏色，尺寸等顯示屬性的矩形，這些矩形的順序與顯示順序一致。然后就是對渲染樹的每個節點進


行布局處理，確定其在屏幕上的顯示位置。最后 就是遍歷渲染樹并用上一章提到的ＵＩ后端層將每一個


節點繪制出來。
以上步驟是一個漸進的過程，為了提高用戶體驗，渲染引擎試圖盡可能快的把結果顯示給最終用戶。它


不會等到所有ＨＴＭＬ都被解析完才創建并布局渲染樹。它會在從網絡層獲取文檔內容的同時把已經接

收到的局部內容先展示出來。
不同渲染引擎具體不同的渲染流程
上面只是介紹了渲染引擎一般的處理流程，針對不同的渲染引擎具體步驟可能有所不同，就拿常見的

webkit跟gecko來說吧。
首先是webkit的詳細渲染流程:

火狐等瀏覽器的gecko渲染流程:

從上面兩幅圖可以看出，盡管兩者使用了不同的“專業術語”，但是從圖上可以看出，兩者的渲染過程

可謂大同小異，正是于此，我們可以再把具體的過程統一分離出來，接下來的四章會根據四個主要渲染

過程進行一下較為細致的說明。
原文鏈接：http://www.cnblogs.com/luluping/archive/2013/04/05/3000461.html
========

各種瀏覽器的頁面渲染引擎簡介

Trident頁面渲染引擎
Trident（又稱為MSHTML），是微軟的視窗操作系統（Windows）搭載的網頁瀏覽器—Internet Explorer

的頁面渲染引擎的名稱，
它的第一個版本誕生于1997年10月Internet Explorer第四版中，IE7做了的重大的變動，除了加入新的

技術之外，
并增加對網頁標準的支持，目前是互聯網上最流行的排版引擎。
使用Trident頁面渲染引擎的瀏覽器有
· Internet Explorer（IE）
· 傲游
· 世界之窗瀏覽器
· Avant
· 騰訊TT
· Netscape 8
· NetCaptor
· Sleipnir
· GOSURF
· GreenBrowser
· KKman

Gecko頁面渲染引擎
Gecko是套開放源代碼的、以C++編寫的頁面渲染引擎。Gecko是跨平臺的，
能在Microsoft Windows、Linux和Mac OS X等主要操作系統上運行。
它是最流行的頁面渲染引擎之一，其流行程度僅次于Trident。
使用Gecko頁面渲染引擎的瀏覽器有
· Fennec
· Firefox
· 網景（6至9）
· SeaMonkey
· Camino
· Flock
· Galeon
· K-Meleon
· Minimo
· Mozilla
· Sleipnir
· Songbird
· XeroBank


KHTML頁面渲染引擎或WebKit框架
KHTML，是HTML頁面渲染引擎之一，由KDE所開發。KHTML擁有速度快捷的優點，
但對錯誤語法的容忍度則比Mozilla產品所使用的Gecko引擎小。蘋果電腦于2002年采納了KHTML，
作為開發Safari瀏覽器之用。WebCore及WebKit引擎均是KHTML的衍生產品；
WebKit是 Mac OS X v10.3及以上版本所包含的軟件框架，WebKit是Mac OS X的Safari網頁瀏覽器的基礎


。
使用KHTML頁面渲染引擎的瀏覽器有
· Safari
· Konqueror
· Epiphany
· Google Chrome
· iCab
· OmniWeb
· Midori
· Shiira

Presto頁面渲染引擎
Presto是一個由Opera Software開發的瀏覽器頁面渲染引擎，應用于Opera 7.0~9.60版，
它取代了舊版Opera中所使用的Elektra頁面渲染引擎，包括加入動態功能，
例如網頁或其部分可隨著DOM及Script語法的事件而重新排版。
使用Presto頁面渲染引擎的瀏覽器有
· Opera
· 任天堂DS瀏覽器

Java軟件平臺
Java，是一種可以撰寫跨平臺應用軟件的面向對象的程序設計語言，
Java 編程語言的風格十分接近C++語言。微軟推出的.NET平臺以及模仿Java的C#語言正是與之競爭下的

產物。
使用Java平臺的瀏覽器有
· HotJava
· Opera Mini
· UCWEB

Tasman頁面渲染引擎
Tasman，是微軟的Internet Explorer for Mac瀏覽器所使用的頁面渲染引擎，
也是為嘗試支援W3C所制定的網頁標準而設計的。在Mac版的Microsoft Office 2004中，
電子郵件客戶端Microsoft Entourage使用的就是Tasman頁面渲染引擎。
使用Tasman頁面渲染引擎的瀏覽器有
· Internet Explorer for Mac
· MSN for Mac OS X

文本界面
就是一些純文字式的網頁瀏覽器，在LINUX系統中比較常見。
使用文本界面的瀏覽器有
· Lynx
· Links
· w3m

手持設備或嵌入式系統
· Internet Explorer Mobile
· Minimo
· Opera Mobile
· PSP瀏覽器

其它頁面渲染引擎
· Amaya
· Dillo
· Mosaic
========

總結

以上是生活随笔為你收集整理的浏览器渲染引擎学习总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。