看到這個標題你們必定會想到這篇神文《How Browsers Work》,這篇文章把瀏覽器的不少細節講得很細,並且也被翻譯成了中文。爲何我還想寫一篇呢?由於兩個緣由,php
1)這篇文章太長了,閱讀成本太大,不能一口氣讀完。css
2)花了大力氣讀了這篇文章後能夠了解不少,但彷佛對工做沒什麼幫助。html
因此,我準備寫下這篇文章來解決上述兩個問題。但願你能在上班途中,或是坐馬桶時就能讀完,並能從中學會一些能用在工做上的東西。web
瀏覽器工做大流程ajax
廢話少說,先來看個圖:算法
從上面這個圖中,咱們能夠看到那麼幾個事:瀏覽器
1)瀏覽器會解析三個東西:app
2)解析完成後,瀏覽器引擎會經過 DOM Tree 和 CSS Rule Tree 來構造 Rendering Tree。注意:異步
3)最後經過調用操做系統 Native GUI 的 API 繪製。ide
DOM 解析
HTML 的 DOM Tree 解析以下:
<html> <head> <title>Web page parsing</title> </head> <body> <div> <h1>Web page parsing</h1> <p>This is an example Web page.</p> </div> </body> </html>
上面這段 HTML 會解析成這樣:
下面是另外一個有 SVG 標籤的狀況。
CSS 解析
CSS 的解析大概是下面這個樣子(下面主要說的是 Gecko 也就是 Firefox 的玩法),假設咱們有下面的 HTML 文檔:
<doc> <title>A few quotes</title> <para> Franklin said that <quote>"A penny saved is a penny earned."</quote> </para> <para> FDR said <quote>"We have nothing to fear but <span>fear itself.</span>"</quote> </para> </doc>
因而 DOM Tree 是這個樣子:
而後咱們的 CSS 文檔是這樣的:
/* rule 1 */ doc { display: block; text-indent: 1em; } /* rule 2 */ title { display: block; font-size: 3em; } /* rule 3 */ para { display: block; } /* rule 4 */ [] { font-style: italic; }
因而咱們的 CSS Rule Tree 會是這個樣子:
注意,圖中的第 4 條規則出現了兩次,一次是獨立的,一次是在規則 3 的子結點。因此,咱們能夠知道,創建 CSS Rule Tree 是須要比照着 DOM Tree 來的。CSS 匹配 DOM Tree 主要是從右到左解析 CSS 的 Selector,好多人覺得這個事會比較快,其實並不必定。關鍵還看咱們的 CSS 的 Selector 怎麼寫了。
注意:CSS 匹配 HTML 元素是一個至關複雜和有性能問題的事情。因此,你就會在N多地方看到不少人都告訴你,DOM 樹要小,CSS 儘可能用 id 和 class,千萬不要過渡層疊下去,……
經過這兩個樹,咱們能夠獲得一個叫 Style Context Tree,也就是下面這樣(把 CSS Rule 結點 Attach 到 DOM Tree 上):
因此,Firefox 基本上來講是經過 CSS 解析生成 CSS Rule Tree,而後,經過比對 DOM 生成 Style Context Tree,而後 Firefox 經過把 Style Context Tree 和其 Render Tree(Frame Tree)關聯上,就完成了。注意:Render Tree 會把一些不可見的結點去除掉。而 Firefox 中所謂的 Frame 就是一個 DOM 結點,不要被其名字所迷惑了。
注:Webkit 不像 Firefox 要用兩個樹來幹這個,Webkit 也有 Style 對象,它直接把這個 Style 對象存在了相應的 DOM 結點上了。
渲染
渲染的流程基本上以下(黃色的四個步驟):
注意:上圖流程中有不少鏈接線,這表示了 Javascript 動態修改了 DOM 屬性或是 CSS 屬性會致使從新 Layout,有些改變不會,就是那些指到天上的箭頭,好比,修改後的 CSS rule 沒有被匹配到,等。
這裏重要要說兩個概念,一個是 Reflow,另外一個是 Repaint。這兩個不是一回事。
下面是一個打開 Wikipedia 時的 Layout/reflow 的視頻(注:HTML 在初始化的時候也會作一次 reflow,叫 intial reflow),你能夠感覺一下:
Reflow 的成本比 Repaint 的成本高得多的多。DOM Tree 裏的每一個結點都會有 reflow 方法,一個結點的 reflow 頗有可能致使子結點,甚至父點以及同級結點的 reflow。在一些高性能的電腦上也許還沒什麼,可是若是 reflow 發生在手機上,那麼這個過程是很是痛苦和耗電的。
因此,下面這些動做有很大可能會是成本比較高的。
注:display:none 會觸發 reflow,而 visibility:hidden 只會觸發 repaint,由於沒有發現位置變化。
多說兩句關於滾屏的事,一般來講,若是在滾屏的時候,咱們的頁面上的全部的像素都會跟着滾動,那麼性能上沒什麼問題,由於咱們的顯卡對於這種把全屏像素往上往下移的算法是很快。可是若是你有一個 fixed 的背景圖,或是有些 Element 不跟着滾動,有些 Elment 是動畫,那麼這個滾動的動做對於瀏覽器來講會是至關至關痛苦的一個過程。你能夠看到不少這樣的網頁在滾動的時候性能有多差。由於滾屏也有可能會形成 reflow。
基本上來講,reflow 有以下的幾個緣由:
好了,咱們來看一個示例吧:
var bstyle = document.body.style; // cache bstyle.padding = "20px"; // reflow, repaint bstyle.border = "10px solid red"; // 再一次的 reflow 和 repaint bstyle.color = "blue"; // repaint bstyle.backgroundColor = "#fad"; // repaint bstyle.fontSize = "2em"; // reflow, repaint // new DOM element - reflow, repaint document.body.appendChild (document.createTextNode ('dude!'));
固然,咱們的瀏覽器是聰明的,它不會像上面那樣,你每改一次樣式,它就 reflow 或 repaint 一次。通常來講,瀏覽器會把這樣的操做積攢一批,而後作一次 reflow,這又叫異步 reflow 或增量異步 reflow。可是有些狀況瀏覽器是不會這麼作的,好比:resize 窗口,改變了頁面默認的字體,等。對於這些操做,瀏覽器會立刻進行 reflow。
可是有些時候,咱們的腳本會阻止瀏覽器這麼幹,好比:若是咱們請求下面的一些 DOM 值:
由於,若是咱們的程序須要這些值,那麼瀏覽器須要返回最新的值,而這樣同樣會 flush 出去一些樣式的改變,從而形成頻繁的 reflow/repaint。
減小 reflow/repaint
下面是一些 Best Practices:
1)不要一條一條地修改 DOM 的樣式。與其這樣,還不如預先定義好 css 的 class,而後修改 DOM 的 className。
// bad var left = 10, top = 10; el.style.left = left + "px"; el.style.top = top + "px"; // Good el.className += " theclassname"; // Good el.style.cssText += "; left: " + left + "px; top: " + top + "px;";
2)把 DOM 離線後修改。如:
3)不要把 DOM 結點的屬性值放在一個循環裏當成循環裏的變量。否則這會致使大量地讀寫這個結點的屬性。
4)儘量的修改層級比較低的 DOM。固然,改變層級比較底的 DOM 有可能會形成大面積的 reflow,可是也可能影響範圍很小。
5)爲動畫的 HTML 元件使用 fixed 或 absoult 的 position,那麼修改他們的 CSS 是不會 reflow 的。
6)千萬不要使用 table 佈局。由於可能很小的一個小改動會形成整個 table 的從新佈局。
In this manner, the user agent can begin to lay out the table once the entire first row has been received. Cells in subsequent rows do not affect column widths. Any cell that has content that overflows uses the ‘overflow’ property to determine whether to clip the overflow content.
Fixed layout, CSS 2.1 Specification
This algorithm may be inefficient since it requires the user agent to have access to all the content in the table before determining the final layout and may demand more than one pass.
幾個工具和幾篇文章
有時候,你會也許會發如今 IE 下,你不知道你修改了什麼東西,結果 CPU 一會兒就上去了到 100%,而後過了好幾秒鐘 repaint/reflow 才完成,這種事情以 IE 的年代時常常發生。因此,咱們須要一些工具幫咱們看看咱們的代碼裏有沒有什麼不合適的東西。
最後,別忘了下面這幾篇提升瀏覽器性能的文章:
參考
全文引用自:
瀏覽器的渲染原理簡介: https://news.cnblogs.com/n/178402/