首頁 > 開發者 > JavaScript
瀏覽器工作原理——頁面載入，工作原理頁面載入
瀏覽器工作大流程
來看個圖：
從上面這個圖中，我們可以看到那麼幾個事：
1）瀏覽器會解析三個東西：
2）解析完成後，瀏覽器引擎會通過DOM Tree 和 CSS Rule Tree 來構造 Rendering Tree。注意：
3）最後通過叫用作業系統Native GUI的API繪製。
DOM解析HTML的DOM Tree解析如下
| 123456789101112 | <html><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文檔：
| 123456789 | <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文檔是這樣的：
| 1234 | /* rule 1 */ doc { display: block; text-indent: 1em; }/* rule 2 */ title { display: block; font-size: 3em; }/* rule 3 */ para { display: block; }/* rule 4 */ [class="emph"] { 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。這兩個不是一回事。
Reflow的成本比Repaint的成本高得多的多。DOM Tree裡的每個結點都會有reflow方法，一個結點的reflow很有可能導致子結點，甚至父點以及同級結點的reflow。在一些高效能的電腦上也許還沒什麼，但是如果reflow發生在手機上，那麼這個過程是非常痛苦和耗電的。
所以，下面這些動作有很大可能會是成本比較高的。
註：display:none會觸發reflow，而visibility:hidden只會觸發repaint，因為沒有發現位置變化。
多說兩句關於滾屏的事，通常來說，如果在滾屏的時候，我們的頁面上的所有的像素都會跟著滾動，那麼效能上沒什麼問題，因為我們的顯卡對於這種把全屏像素往上往下移的演算法是很快。但是如果你有一個fixed的背景圖，或是有些Element不跟著滾動，有些Elment是動畫，那麼這個滾動的動作對於瀏覽器來說會是相當相當痛苦的一個過程。你可以看到很多這樣的網頁在滾動的時候效能有多差。因為滾屏也有可能會造成reflow。
基本上來說，reflow有如下的幾個原因：
好了，我們來看一個樣本吧：
| 123456789101112 | var bstyle = document.body.style; // cache bstyle.padding = "20px"; // reflow, repaintbstyle.border = "10px solid red"; // 再一次的 reflow 和 repaint bstyle.color = "blue"; // repaintbstyle.backgroundColor = "#fad"; // repaint bstyle.fontSize = "2em"; // reflow, repaint // new DOM element - reflow, repaintdocument.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。
| 1234567891011 | // badvar left = 10,top = 10;el.style.left = left + "px";el.style.top = top + "px"; // Goodel.className += " theclassname"; // Goodel.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的重新布局。
PS：原文
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
