瀏覽器渲染原理及解剖瀏覽器內部工作原理
1、簡單地說，頁面渲染就是瀏覽器將html程式碼根據CSS定義的規則顯示在瀏覽器視窗中的這個過程。先來大致瞭解一下瀏覽器都是怎麼工作的：
1. 使用者輸入網址（假設是個html頁面，並且是第一次訪問），瀏覽器向伺服器發出請求，伺服器返回html檔案；
2. 瀏覽器開始載入html程式碼，發現<head>標籤內有一個<link>標籤引用外部CSS檔案；
3. 瀏覽器又發出CSS檔案的請求，伺服器返回這個CSS檔案；
4. 瀏覽器繼續載入html中<body>部分的程式碼，並且CSS檔案已經拿到手了，可以開始渲染頁面了；
5. 瀏覽器在程式碼中發現一個<img>標籤引用了一張圖片，向伺服器發出請求。
6. 伺服器返回圖片檔案，由於圖片佔用了一定面積，影響了後面段落的排布，因此瀏覽器需要回過頭來重新渲染這部分程式碼；
7. 瀏覽器發現了一個包含一行Javascript程式碼的<script>標籤，趕快執行它；
8. Javascript指令碼執行了這條語句，它命令瀏覽器隱藏掉程式碼中的某個<div> （style.display=”none”）。杯具啊，突然就少了這麼一個元素，瀏覽器不得不重新渲染這部分程式碼；
9. 終於等到了</html>的到來，瀏覽器淚流滿面……
10. 等等，還沒完，使用者點了一下介面中的“換膚”按鈕，Javascript讓瀏覽器換了一下<link>標籤的CSS路徑；
11. 瀏覽器召集了在座的各位<div><span><ul><li>們，“大夥兒收拾收拾行李，咱得重新來過……”，瀏覽器向伺服器請
求了新的CSS檔案，重新渲染頁面。
瀏覽器每天就這麼來來回回跑著，要知道不同的人寫出來的html和css程式碼質量參差不齊，說不定哪天跑著跑著就掛掉了。好在這個世界還有這麼一群人——頁面重構工程師，平時挺不起眼，也就幫視覺設計師們切切圖啊改改字，其實背地裡還是幹了不少實事的。
說到頁面為什麼會慢？那是因為瀏覽器要花時間、花精力去渲染，尤其是當它發現某個部分發生了點變化影響了佈局，需要倒回去重新渲染，內行稱這個回退的過程叫reflow。
reflow幾乎是無法避免的。現在介面上流行的一些效果，比如樹狀目錄的摺疊、展開（實質上是元素的顯示與隱藏）等，都將引起瀏覽器的 reflow。滑鼠滑過、點選……只要這些行為引起了頁面上某些元素的佔位面積、定位方式、邊距等屬性的變化，都會引起它內部、周圍甚至整個頁面的重新渲染。通常我們都無法預估瀏覽器到底會reflow哪一部分的程式碼，它們都彼此相互影響著。
reflow問題是可以優化的，我們可以儘量減少不必要的reflow。比如開頭的例子中的<img>圖片載入問題，這其實就是一個可以避免的reflow——給圖片設定寬度和高度就可以了。這樣瀏覽器就知道了圖片的佔位面積，在載入圖片前就預留好了位置。
另外，有個和reflow看上去差不多的術語：repaint，中文叫重繪。如果只是改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部佈局的屬性，將只會引起瀏覽器repaint。repaint的速度明顯快於 reflow（在IE下需要換一下說法，reflow要比repaint 更緩慢）。下次將通過一系列的實驗說明在Firefox、IE等瀏覽器下reflow的優化。
2、瀏覽器內部工作原理
一、介紹
瀏覽器可以被認為是使用最廣泛的軟體，本文將介紹瀏覽器的工作原理，我們將看到，從你在位址列輸入google.com到你看到google主頁過程中都發生了什麼。
將討論的瀏覽器
今天，有五種主流瀏覽器——IE、Firefox、Safari、Chrome及Opera。
本文將基於一些開源瀏覽器的例子——Firefox、Chrome及Safari，Safari是部分開源的。
根據W3C（World Wide Web Consortium全球資訊網聯盟）的瀏覽器統計資料，當前（2011年5月），Firefox、Safari及Chrome的市場佔有率綜合已接近60％。（原文為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）
瀏覽器的主要元件包括：
1. 使用者介面 － 包括位址列、後退/前進按鈕、書籤目錄等，也就是你所看到的除了用來顯示你所請求頁面的主視窗之外的其他部分。
2. 瀏覽器引擎 － 用來查詢及操作渲染引擎的介面。
3. 渲染引擎 － 用來顯示請求的內容，例如，如果請求內容為html，它負責解析html及css，並將解析後的結果顯示出來。
4. 網路 － 用來完成網路呼叫，例如http請求，它具有平臺無關的介面，可以在不同平臺上工作。
5. UI後端 － 用來繪製類似組合選擇框及對話方塊等基本元件，具有不特定於某個平臺的通用介面，底層使用作業系統的使用者介面。
6. JS直譯器 － 用來解釋執行JS程式碼。
7. 資料儲存 － 屬於持久層，瀏覽器需要在硬碟中儲存類似cookie的各種資料，HTML5定義了web database技術，這是一種輕量級完整的客戶端儲存技術
圖1：瀏覽器主要元件
需要注意的是，不同於大部分瀏覽器，Chrome為每個Tab分配了各自的渲染引擎例項，每個Tab就是一個獨立的程序。
對於構成瀏覽器的這些元件，後面會逐一詳細討論。
二、渲染引擎（The rendering engine）
渲染引擎的職責就是渲染，即在瀏覽器視窗中顯示所請求的內容。
預設情況下，渲染引擎可以顯示html、xml文件及圖片，它也可以藉助外掛（一種瀏覽器擴充套件）顯示其他型別資料，例如使用PDF閱讀器外掛，可以顯示PDF格式，將由專門一章講解外掛及擴充套件，這裡只討論渲染引擎最主要的用途——顯示應用了CSS之後的html及圖片。
渲染引擎簡介
本文所討論的瀏覽器——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元素的工廠。下面將討論流程中的各個階段。
三、解析與DOM樹構建（Parsing and DOM tree construction）
解析（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++”將不會匹配任何規則，因此是一個無效輸入。
詞彙表及語法的定義
詞彙表通常利用正則表示式來定義。
例如上面的語言可以定義為：
INTEGER：0｜［1－9］［0－9］＊
PLUS：+
MINUS：－
正如看到的，這裡用正則表示式定義整數。
語法通常用BNF格式定義，我們的語言可以定義為：
expression :＝ term operation term
operation := PLUS | MINUS
term := INTEGER | expression
解析器型別（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 parsers automatically）
解析器生成器這個工具可以自動生成解析器，只需要指定語言的文法——詞彙表及語法規則，它就可以生成一個解析器。建立一個解析器需要對解析有深入的理解，而且手動的建立一個由較好效能的解析器並不容易，所以解析生成器很有用。Webkit使用兩個知名的解析生成器——用於建立語法分析器的Flex及建立解析器的Bison（你可能接觸過Lex和Yacc）。Flex的輸入是一個包含了符號定義的正則表示式，Bison的輸入是用BNF格式表示的語法規則。
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和標籤基本是一一對應的關係，例如，如下的標籤：
<html>
<body>
<p>
Hello DOM
</p>
<div><img src=”example.png” /></div>
</body>
</html>
將會被轉換為下面的DOM樹：
圖8：示例標籤對應的DOM樹
這裡所謂的樹包含了DOM節點是說樹是由實現了DOM介面的元素構建而成的，瀏覽器使用已被瀏覽器內部使用的其他屬性的具體實現。
解析演算法（The parsing algorithm）
正如前面章節中討論的，hmtl不能被一般的自頂向下或自底向上的解析器所解析。
原因是：
1. 這門語言本身的寬容特性
2. 瀏覽器對一些常見的非法html有容錯機制
3. 解析過程是往復的，通常原始碼不會在解析過程中發生改變，但在html中，指令碼標籤包含的“document.write”可能新增標籤，這說明在解析過程中實際上修改了輸入。
不能使用正則解析技術，瀏覽器為html定製了專屬的解析器。
Html5規範中描述了這個解析演算法，演算法包括兩個階段——符號化及構建樹。
符號化是詞法分析的過程，將輸入解析為符號，html的符號包括開始標籤、結束標籤、屬性名及屬性值。
符號識別器識別出符號後，將其傳遞給樹構建器，並讀取下一個字元，以識別下一個符號，這樣直到處理完所有輸入。
圖9：HTML解析流程
符號識別演算法（The tokenization algorithm）
演算法輸出html符號，該演算法用狀態機表示。每次讀取輸入流中的一個或多個字元，並根據這些字元轉移到下一個狀態，當前的符號狀態及構建樹狀態共同影響結果，這意味著，讀取同樣的字元，可能因為當前狀態的不同，得到不同的結果以進入下一個正確的狀態。
這個演算法很複雜，這裡用一個簡單的例子來解釋這個原理。
基本示例——符號化下面的html：
<html>
<body>
Hello world
</body>
</html相關推薦
瀏覽器渲染原理及解剖瀏覽器內部工作原理
1、簡單地說，頁面渲染就是瀏覽器將html程式碼根據CSS定義的規則顯示在瀏覽器視窗中的這個過程。先來大致瞭解一下瀏覽器都是怎麼工作的： 1. 使用者輸入網址（假設是個html頁面，並且是第一次訪問），瀏覽器向伺服器發出請求，伺服器返回html檔案； 2.
hibernate工作原理及作用 JAVA Hibernate工作原理及為什麼要用
轉載自 http://www.cnblogs.com/dashi/p/3597969.html#commentform JAVA Hibernate工作原理及為什麼要用 hibernate 簡介：hibernate是一個開源框架，它是物件關聯關係對映的框架，它對JDBC做了輕量級的封裝，而我們j
瀏覽器內部工作原理
目錄 一、介紹 二、渲染引擎 三、解析與DOM樹構建 四、渲染樹構建 五、佈局 六、繪製 七、動態變化 八、渲染引擎的執行緒 九、CSS2可視模型 一、介紹 瀏覽器可以被認為是使用最廣泛的軟體，本文將介紹瀏覽器的工作原理，我們將看到，從你在位址列輸入goog
前端必讀：瀏覽器內部工作原理
目錄 一、介紹 二、渲染引擎 三、解析與DOM樹構建 四、渲染樹構建 五、佈局 六、繪製 七、動態變化 八、渲染引擎的執行緒 九、CSS2可視模型 一、介紹 瀏覽器可以被認為是使用最廣
chrome瀏覽器渲染引擎及JS引擎
策略 In 快的 解析html 發現 引擎 可能 位置 同時 渲染引擎的作用包含解析html生成dom，生成render樹，dom改變及樣式改變下的重排（對布局位置重新計算），重繪（繪制在屏幕上） 渲染引擎與JS引擎為互斥關系，但根據timeline發現，JS執行時重排和解
Tomcat性能優化及JVM內存工作原理
web linux 了解 stat compact src 返回 共享 disable Java性能優化原則：代碼運算性能、內存回收、應用配置（影響Java程序主要原因是垃圾回收，下面會重點介紹這方面） 代碼層優化：避免過多循環嵌套、調用和復雜邏輯。 Tomcat調優主
8. 理解ZooKeeper的內部工作原理
zab 階段 身份驗證 過多 管理系統 多個 基礎 des jpg 到目前為止，我們已經討論了ZooKeeper服務的基礎知識，並詳細了解了數據模型及其屬性。 我們也熟悉了ZooKeeper 監視（watch）的概念，監視就是在ZooKeeper命名空間中的znode發生任
[轉] JavaScript控制瀏覽器全屏及各種瀏覽器全屏模式的方法、屬性和事件
script ati 保持 num adding html5 美國 bre art [From] http://www.jb51.net/article/76695.htm HTML 5中的full screen，目前可以在除IE和opera外的瀏覽器中使用 ，有的時候
《Python學習之路 -- Python基礎之叠代器及for循環工作原理》
pre 循環 next 是我 我們 png 捕獲 模擬 檢查 提到叠代器不得不說叠代器協議，叠代器協議是指：對象必須提供一個__next__()方法，執行該方法要麽返回叠代中的下一項，要麽就拋出一個StopIteration異常（相當於報錯的意思）以終止叠代。然而遵循這
Docker（二）：理解容器編排工具Kubernetes內部工作原理
一、Kubernetes是什麼 要說到Docker就不得不說說Kubernetes。當Docker容器在微服務的環境下數量一多，那麼統一的，自動化的管理自然少不了。而Kubernetes就是一個這樣的工具，它不僅僅提供了健康檢查和自修復，還有自動擴容縮容，以及服務發現和負載均衡等等功能。總的來說它使我們對
購物車的原理及實現.(仿京東實現原理)
2017年7月14日更新: 有很多小夥伴想要專案資料和原始碼, 我重新整理了一份傳了上來: 這次更新的為專案全套視訊及所有原始碼資料： 連結: https://pan.baidu.com/s/1hseNP9U 密碼: ugey 今天來開始寫一下關於購物車的東西,
Hadoop 原理學習——HDFS 架構與工作原理
一、目標HDFS 全稱 hadoop 分散式檔案系統，其最主要的作用是作為 Hadoop 生態中各系統的儲存服務。面對大規模的資料，HDFS 在設計上滿足了以下目標：高度容錯性：HDFS 可能由成百上千的伺服器構成，任何一個元件都可能失效，因此錯誤檢測和快速、自動的恢復時 H
瀏覽器工作原理（二）：瀏覽器渲染過程概述
sync 結構 dom end 繪制 fault 異步加載 步驟 targe 參考：https://segmentfault.com/a/1190000012925872#articleHeader4 瀏覽器器內核拿到內容後，渲染大概可以劃分成以下幾個步驟： 解析html
根據瀏覽器渲染引擎工作原理(reflow/repaint)，來優化DOM的操作
工作原理 scroll 標簽 發現 較高的 所有 hid 問題 移動端 1.瀏覽器的渲染引擎工作原理： （1）解析HTML，生成DOM樹。解析HTML文檔，轉換樹中的html標簽或js生成的標簽到DOM節點，它被稱為 -- 內容樹。 （2）構建渲染樹，解析Style
瀏覽器渲染原理及web前端分析，從瀏覽器渲染原理談頁面優化
瀏覽器渲染原理及web前端分析 瀏覽器的主要功能 使用者介面：包括位址列、後退/前進按鈕、書籤目錄等，也就是除了用來顯示你所請求頁面的主視窗之外的其他部分。 瀏覽器引擎：用來查詢及操作渲染引擎的介面。另外還用來操作瀏覽器的資料儲存。 渲染引擎：用來顯示請求的內容，例如，如果請求內容為html
瀏覽器渲染原理及流程
我們可能都知道瀏覽器含有一個渲染引擎，用來渲染視窗所展示的內容。預設情況下，渲染引擎可以顯示html、xml文件及圖片，它也可以藉助外掛（一種瀏覽器擴充套件）顯示其他型別資料，例如使用PDF閱讀器外掛，用於顯示PDF格式。但是其具體的渲染原理和流程估計也有很多人都不知道或者不
網址的含義及瀏覽器的基本工作原理
下標 步驟 -o 有一個 orm 這樣的 就是 快速定位 class 網址結構 從上圖我們可以看出這段網址由6部分組成分別是協議 域名 路徑 查詢參數 錨點 端口。一般我們只在瀏覽器上面輸入域名即可，其他瀏覽器會自
深入解析瀏覽器的幕後工作原理(三) 呈現樹和 DOM 樹的關系
文本 一行 出現 src 格式 關於 放置 顯示 關系 呈現樹和 DOM 樹的關系 呈現器是和 DOM 元素相對應的，但並非一一對應。非可視化的 DOM 元素不會插入呈現樹中，例如“head”元素。如果元素的 display 屬性值為“none”，那麽也不會顯示在呈現
深入解析瀏覽器的幕後工作原理(二) 呈現引擎
div 分享 image ima 好的 clas logs 指令 開放源代碼 呈現引擎 本文所討論的瀏覽器（Firefox、Chrome 瀏覽器和 Safari）是基於兩種呈現引擎構建的。Firefox 使用的是 Gecko，這是 Mozilla 公司“自制”的呈現
【瀏覽器渲染原理】 渲染樹和頁面渲染
display 順序 情況下 有一個 所有 覆蓋 isp ID span 來自：https://blog.csdn.net/qq243541844/article/details/51922947 【瀏覽器渲染原理】 渲染樹和頁面渲染 我們主要討論以下列出的幾個問題： 什