筆記-瀏覽器框架及工做原理

1. 瀏覽器功能及組成結構

1.1. 功能

略javascript

1.2. 瀏覽器組成結構

瀏覽器的主要組件包括：css

用戶界面 - 包括地址欄、前進/後退按鈕、書籤菜單等。除了瀏覽器主窗口顯示的你請求的頁面外，其餘顯示的各個部分都屬於用戶界面。
瀏覽器引擎 - 在用戶界面和渲染引擎之間傳送指令。
渲染引擎 - 負責顯示請求的內容。若是請求的內容是 HTML，它就負責解析 HTML 和 CSS 內容，並將解析後的內容顯示在屏幕上。
網絡 - 用於網絡調用，好比 HTTP 請求。其接口與平臺無關，併爲全部平臺提供底層實現。
用戶界面後端 - 用於繪製基本的窗口小部件，好比組合框和窗口。其公開了與平臺無關的通用接口，而在底層使用操做系統的用戶界面方法。
JavaScript 解釋器。用於解析和執行 JavaScript 代碼，好比chrome的javascript解釋器是V8。
數據存儲。這是持久層。瀏覽器須要在硬盤上保存各類數據，例如 Cookie。新的 HTML 規範 (HTML5)定義了「網絡數據庫」，這是一個完整（可是輕便）的瀏覽器內數據庫。

瀏覽器組織結構圖(High Level Structure)html

1.3. 瀏覽器打開網頁的具體實現過程描述

1. 用戶輸入網址（假設是個html頁面，而且是第一次訪問），瀏覽器向服務器發出請求，服務器返回html文件；前端

2. 瀏覽器開始載入html代碼，發現<head>標籤內有一個<link>標籤引用外部CSS文件；html5

3. 瀏覽器又發出CSS文件的請求，服務器返回這個CSS文件；java

4. 瀏覽器繼續載入html中<body>部分的代碼，而且CSS文件已經拿到手了，能夠開始渲染頁面了；程序員

5. 瀏覽器在代碼中發現一個<img>標籤引用了一張圖片，向服務器發出請求。此時瀏覽器不會等到圖片下載完，而是繼續渲染後面的代碼；web

6. 服務器返回圖片文件，因爲圖片佔用了必定面積，影響了後面段落的排布，所以瀏覽器須要回過頭來從新渲染這部分代碼；chrome

7. 瀏覽器發現了一個包含一行Javascript代碼的<script>標籤，趕快運行它；數據庫

8. Javascript腳本執行了這條語句，它命令瀏覽器隱藏掉代碼中的某個（style.display=」none」）。杯具啊，忽然就少了這麼一個元素，瀏覽器不得不從新渲染這部分代碼；

9. 終於等到了</html>的到來，瀏覽器淚流滿面……

10. 等等，還沒完，用戶點了一下界面中的「換膚」按鈕，Javascript讓瀏覽器換了一下<link>標籤的CSS路徑；

11. 瀏覽器召集了在座的各位

<span><ul><li>們，「大夥兒收拾收拾行李，咱得從新來過……」，瀏覽器向服務器請

求了新的CSS文件，從新渲染頁面。

1.4. 瀏覽器內核

瀏覽器內核又叫渲染引擎，主要負責 HTML、CSS 的解析，頁面佈局、渲染與複合層合成。瀏覽器內核的不一樣帶來的主要問題是對 CSS 的支持度與屬性表現差別。

如今主流的內核有：Blink、Webkit、Gecko、Trident：

通常瀏覽器採用的都是單內核，而隨着瀏覽器的發展示在也出現了雙內核，像360瀏覽器、QQ瀏覽器都是採用雙內核。

Trident

元老級內核之一，由微軟開發，並於1997年10月首次在ie 4.0中使用，憑藉其windows壟斷優點，Trident市場佔有率一直很高。然而壟斷並不是，沒有競爭就沒有進步，長期以往，Trident內核一度停滯不前，更新緩慢，甚至一度與W3C標準脫節。2011年，從ie 9開始，Trident開始支持HTML5和CSS 3，所以咱們也常常會看到有些網站在瀏覽時會提示用戶（在Internet Explorer 9.0+以上瀏覽效果最佳）。前端程序員作瀏覽器兼容通常也再也不會考慮ie 8以前的瀏覽器了。

因爲該內核由微軟開發出來供ie使用，所以這款內核通常也被稱爲「ie內核」。ie內核提供了開放的接口，能夠供其餘瀏覽器去包裝該內核開發出本身的一套瀏覽器，如同包裝Android原生系統開發出MIUI。國內不少瀏覽器廠商期初就是包裝ie內核，如360安全瀏覽器，360極速瀏覽器，百度瀏覽器，獵豹瀏覽器等，後面通過不斷地發展有的內核發生了變化，這個後面會提到。

Gecko

元老級內核之一，由Netscape公司Mozilla組織開發。1998年，Netscape在於IE瀏覽器競爭失利以後，成立了非正式組織Mozilla，由其開發新一代內核，後命名爲「Gecko」。FireFox也是這班人開發出來了，所以這也就是FireFox一直使用的內核。

Gecko的特色是代碼徹底公開，所以其開發程度很高，全世界的程序員均可覺得其編寫代碼，增長功能。

WebKit

這是蘋果公司開發的內核，也是其旗下產品Ssfari瀏覽器使用的內核。Webkit引擎包含了WebCode排版引擎和JavaScriptCode解析引擎，分別是從KDE的KHTML和KJS衍生而來，它們都是自由軟件，在GPL條約下受權，同時支持BSD系統開發。

Chrome、360極速瀏覽器以及搜狗高速瀏覽器也使用Webkit做爲內核（在腳本理解方面，Chorome使用本身研發的V8引擎）。

Blink

這是由Google和Opera Software開發的瀏覽器排版引擎，Google計算將這個渲染引擎做爲Chromium計劃的一部分，而且在2013年4月公佈了這一消息。這一渲染引擎是開源引擎Webkit中WebCore組件的一個分支，而且在Chrome（28及日後版本）、Opera（15及日後版本）和Yandex瀏覽器中使用。

1.5. 經常使用瀏覽器及其內核

一、IE瀏覽器內核：Trident內核，也是俗稱的IE內核；

二、Chrome瀏覽器內核：統稱爲Chromium內核或Chrome內核，之前是Webkit內核，如今是Blink內核；

三、Firefox瀏覽器內核：Gecko內核，俗稱Firefox內核；

四、Safari瀏覽器內核：Webkit內核；

五、Opera瀏覽器內核：最初是本身的Presto內核，後來加入谷歌大軍，從Webkit又到了Blink內核；

六、360瀏覽器、獵豹瀏覽器內核：IE+Chrome雙內核；

七、搜狗、遨遊、QQ瀏覽器內核：Trident（兼容模式）+Webkit（高速模式）；

八、百度瀏覽器、世界之窗內核：IE內核；

九、2345瀏覽器內核：好像之前是IE內核，如今也是IE+Chrome雙內核了；

十、UC瀏覽器內核：這個衆口不一，UC說是他們本身研發的U3內核，但好像仍是基於Webkit和Trident，還有說是基於火狐內核。

2. 瀏覽器渲染工做原理

2.1. 主流程描述

瀏覽器首先經過網絡得到所請求文檔的內容，而後進行下面的步驟:

即：解析文檔構建DOM樹 ==> 構建render樹 ==> 繪製render樹

引擎將解析 HTML 文檔，並將各標記逐個轉化成「DOM TREE」上的 DOM 節點。同時也會解析外部 CSS 文件以及樣式元素中的樣式數據生成css rule tree。二者結合生成rendering tree,也能夠叫呈現樹。

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

呈現樹構建完畢以後，進入「佈局」處理階段，也就是爲每一個節點分配一個應出如今屏幕上的確切座標。下一個階段是繪製 - 呈現引擎會遍歷呈現樹，由用戶界面後端層將每一個節點繪製出來。

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

其它事項：

瀏覽器刷新的頻率大概是60次/秒，也就是說刷新一次大概時間爲16ms

若是瀏覽器對每一幀的渲染工做超過了這個時間，頁面的渲染就會出現卡頓的現象。

以上過程是漸進的，並不必定嚴格按照順序執行的，爲了更快將內容呈如今不屏幕中，不會等到HTML所有解析完成以後纔開始構建渲染樹和layout，它會在不斷接收和處理其餘網絡資源的同時，就開始部份內容的解析和渲染

渲染完成以後會觸發 ready事件

webkit主流程示例：

Gecko呈現引擎主流程

2.2. 其它技術名詞

2.2.1. repaint/reflow

這兩個概念使用在paint過程當中，頁面爲何會慢？那是由於瀏覽器要花時間、花精力去渲染，尤爲是當它發現某個部分發生了點變化影響了佈局，須要倒回去從新渲染，這個回退的過程叫reflow。

reflow幾乎是沒法避免的。如今界面上流行的一些效果，好比樹狀目錄的摺疊、展開（實質上是元素的顯示與隱藏）等，都將引發瀏覽器的 reflow。鼠標滑過、點擊……只要這些行爲引發了頁面上某些元素的佔位面積、定位方式、邊距等屬性的變化，都會引發它內部、周圍甚至整個頁面的從新渲染。一般咱們都沒法預估瀏覽器到底會reflow哪一部分的代碼，它們都彼此相互影響着。

reflow問題是能夠優化的，咱們能夠儘可能減小沒必要要的reflow。好比<img>圖片載入問題，這其實就是一個能夠避免的reflow——給圖片設置寬度和高度就能夠了。這樣瀏覽器就知道了圖片的佔位面積，在載入圖片前就預留好了位置。

另外，有個和reflow看上去差很少的術語：repaint，中文叫重繪。若是隻是改變某個元素的背景色、文字顏色、邊框顏色等等不影響它周圍或內部佈局的屬性，將只會引發瀏覽器repaint。repaint的速度明顯快於 reflow（在IE下須要換一下說法，reflow要比repaint 更緩慢）。

Reflow的成本比Repaint的成本高得多的多。DOM Tree裏的每一個結點都會有reflow方法，一個結點的reflow頗有可能致使子結點，甚至父點以及同級結點的reflow。在一些高性能的電腦上也許還沒什麼，可是若是reflow發生在手機上，那麼這個過程是很是痛苦和耗電的。

因此，下面這些動做有很大可能會是成本比較高的。

增長、刪除、修改DOM結點時，會致使Reflow或Repaint

移動DOM的位置，或是搞個動畫的時候。

修改CSS樣式的時候。

Resize窗口的時候（移動端沒有這個問題），或是滾動的時候。

修改網頁的默認字體時。

3. 總結

瀏覽器顯示網頁的過程能夠作以下描述：

請求獲得html文檔，根據文檔請求更多的img,css及其它資源文件；
解析文檔獲得兩個東西，dom tree and cssom tree；
依據上面兩個tree生成render tree；
根據render tree進行佈局並在其中繪製相關元素。

4. reference

https://www.html5rocks.com/zh/tutorials/internals/howbrowserswork/#Rendering_engines
http://www.javashuo.com/article/p-ospylmyk-bu.html
https://blog.csdn.net/proswpualan/article/details/81813329