深入理解浏览器解析和执行过程
在我們公司的業(yè)務(wù)場(chǎng)景中，有很大一部分用戶是使用老款安卓機(jī)瀏覽頁(yè)面，這些老款安卓機(jī)性能較差，如果優(yōu)化不足，頁(yè)面的卡頓現(xiàn)象會(huì)更加明顯，此時(shí)頁(yè)面性能優(yōu)化的重要性就凸顯出現(xiàn)。優(yōu)化頁(yè)面的性能，需要對(duì)瀏覽器的渲染過(guò)程有深入的了解，針對(duì)瀏覽器的每一步環(huán)節(jié)進(jìn)行優(yōu)化。
頁(yè)面高性能的判斷標(biāo)準(zhǔn)是 60fps。這是因?yàn)槟壳按蠖鄶?shù)設(shè)備的屏幕刷新率為 60 次/秒，也就是 60fps , 如果刷新率降低，也就是說(shuō)出現(xiàn)了掉幀, 對(duì)于用戶來(lái)說(shuō)，就是出現(xiàn)了卡頓的現(xiàn)象。
這就要求，頁(yè)面每一幀的渲染時(shí)間僅為16毫秒 (1 秒/ 60 = 16.66 毫秒)。但實(shí)際上，瀏覽器有其他工作要做，因此這一幀所有工作需要在 10毫秒內(nèi)完成。如果工作沒(méi)有完成，幀率將下降，并且內(nèi)容會(huì)在屏幕上抖動(dòng)。 此現(xiàn)象通常稱為卡頓，會(huì)對(duì)用戶體驗(yàn)產(chǎn)生負(fù)面影響。
瀏覽器渲染流程
瀏覽器一開(kāi)始會(huì)從網(wǎng)絡(luò)層獲取請(qǐng)求文檔的內(nèi)容，請(qǐng)求過(guò)來(lái)的數(shù)據(jù)是 Bytes，然后瀏覽器將其編譯成HTML的代碼。
但是我們寫(xiě)出來(lái)的HTML代碼瀏覽器是看不懂的，所以需要進(jìn)行解析。
渲染引擎解析 HTML 文檔，將各個(gè)dom標(biāo)簽逐個(gè)轉(zhuǎn)化成“DOM tree”上的 DOM 節(jié)點(diǎn)。同時(shí)也會(huì)解析內(nèi)部和外部的css, 解析為CSSOM tree, css tree和dom tree結(jié)合在一起生成了render tree。
render tree構(gòu)建好之后，渲染引擎隨后會(huì)經(jīng)歷一個(gè)layout的階段: 計(jì)算出每一個(gè)節(jié)點(diǎn)應(yīng)該出現(xiàn)在屏幕上的確切坐標(biāo)。
之后的階段被稱為paiting階段，渲染引擎會(huì)遍歷render tree, 然后由用戶界面后端層將每一個(gè)節(jié)點(diǎn)繪制出來(lái)。
最后一個(gè)階段是 composite 階段，這個(gè)階段是合并圖層。
瀏覽器內(nèi)核
瀏覽器是一個(gè)極其復(fù)雜龐大的軟件。常見(jiàn)的瀏覽器有chrome, firefox。firefox是完全開(kāi)源，Chrome不開(kāi)源，但Chromium項(xiàng)目是部分開(kāi)源。
Chromium和Chrome之間的關(guān)系類似于嘗鮮版和正式版的關(guān)系，Chromium會(huì)有很多新的不穩(wěn)定的特性，待成熟穩(wěn)定后會(huì)應(yīng)用到Chrome。
瀏覽器功能有很多，包括網(wǎng)絡(luò)、資源管理、網(wǎng)頁(yè)瀏覽、多頁(yè)面管理、插件和擴(kuò)展、書(shū)簽管理、歷史記錄管理、設(shè)置管理、下載管理、賬戶和同步、安全機(jī)制、隱私管理、外觀主題、開(kāi)發(fā)者工具等。
因此瀏覽器內(nèi)部被劃分為不同的模塊。其中和頁(yè)面渲染相關(guān)的，是下圖中虛線框的部分渲染引擎。
渲染引擎的作用是將頁(yè)面轉(zhuǎn)變成可視化的圖像結(jié)果。
目前，主流的渲染引擎包括Trident、Gecko和WebKit，它們分別是IE、火狐和Chrome的內(nèi)核（2013年，Google宣布了Blink內(nèi)核，它其實(shí)是從WebKit復(fù)制出去的），其中占有率最高的是 WebKit。
WebKit
最早，蘋(píng)果公司和KDE開(kāi)源社區(qū)產(chǎn)生了分歧，復(fù)制出一個(gè)開(kāi)源的項(xiàng)目，就是WebKit。
WebKit被很多瀏覽器采用作為內(nèi)核，其中就包括goole的chrome。
后來(lái)google公司又和蘋(píng)果公司產(chǎn)生了分歧，google從webkit中復(fù)制出一個(gè)blink項(xiàng)目。
因此，blink內(nèi)核和webkit內(nèi)核沒(méi)有特別的不同，因此很多老外會(huì)借用 chromium的實(shí)現(xiàn)來(lái)理解webkit的技術(shù)內(nèi)幕，也是完全可以的。
瀏覽器源碼
瀏覽器的代碼非常的龐大，曾經(jīng)有人嘗試閱讀Chromium項(xiàng)目的源碼，git clone 到本地發(fā)現(xiàn)有10個(gè)G，光編譯時(shí)間就3個(gè)小時(shí)（據(jù)說(shuō)火狐瀏覽器編譯需要更多的時(shí)間，大約為6個(gè)小時(shí)）。因此關(guān)于瀏覽器內(nèi)部究竟是如何運(yùn)作的，大部分的分享是瀏覽器廠商參與研發(fā)的內(nèi)部員工。
國(guó)外有個(gè)非常有毅力的工程師Tali Garsiel 花費(fèi)了n年的時(shí)間探究了瀏覽器的內(nèi)幕，本文關(guān)于瀏覽器內(nèi)部工作原理的介紹，主要整理自她的博客how browser work , 和其他人的一些分享。
國(guó)內(nèi)關(guān)于瀏覽器技術(shù)內(nèi)幕主要有《WebKit技術(shù)內(nèi)幕》
下面，我們將針對(duì)瀏覽器渲染的環(huán)節(jié)，深入理解瀏覽器內(nèi)核做了哪些事情，逐一的介紹如何去進(jìn)行前端頁(yè)面的優(yōu)化。
瀏覽器渲染第一步：解析
解析是瀏覽器渲染引擎中第一個(gè)環(huán)節(jié)。我們先大致了解一下解析到底是怎么一回事。
什么是解析
通俗來(lái)講，解析文檔是指將文檔轉(zhuǎn)化成為有意義的結(jié)構(gòu)，好讓代碼去使用他們。
以上圖為例，右邊就是解析好的樹(shù)狀結(jié)構(gòu)，這個(gè)結(jié)構(gòu)就可以“喂“給其他的程序, 然后其他的程序就可以利用這個(gè)結(jié)構(gòu)，生成一些計(jì)算的結(jié)果。
解析的過(guò)程可以分成兩個(gè)子過(guò)程：lexical analysis(詞法分析)和syntax analysis(句法分析)。
lexical analysis(詞法分析)
lexical analysis 被稱為詞法分析的過(guò)程，有的文章也稱為 tokenization，其實(shí)就是把輸入的內(nèi)容分為不同的tokens(標(biāo)記)，tokens是最小的組成部分，tokens就像是人類語(yǔ)言中的一堆詞匯。比如說(shuō)，我們對(duì)一句英文進(jìn)行l(wèi)exical analysis——“The quick brown fox jumps”，我們可以拿到以下的token:
- “The”
- “quick”
- “brown”
- “fox”
- “jumps”
用來(lái)做lexical analysis的工具，被稱為**lexer**， 它負(fù)責(zé)把輸入的內(nèi)容拆分為不同的tokens。不同的瀏覽器內(nèi)核會(huì)選擇不同的lexer , 比如說(shuō)webkit 是使用Flex （Fast Lexer）作為lexer。
syntax analysis(句法分析)
syntax analysis是應(yīng)用語(yǔ)言句法中的規(guī)則， 簡(jiǎn)單來(lái)說(shuō)，就是判斷一串tokens組成的句子是不是正確的。
如果我說(shuō)：“我吃飯工作完了”， 這句話是不符合syntax analysis的，雖然里面的每一個(gè)token都是正確的，但是不符合語(yǔ)法規(guī)范。需要注意的是，符合語(yǔ)法正確 的句子不一定是符合語(yǔ)義正確的。比如說(shuō)，“一個(gè)綠色的夢(mèng)想沉沉的睡去了”，從語(yǔ)法的角度來(lái)講，形容詞 + 主語(yǔ) + 副詞 + 動(dòng)詞沒(méi)有問(wèn)題，但是語(yǔ)義上卻是什么鬼。
負(fù)責(zé)syntax analysis工作的是**parser**，解析是一個(gè)不斷往返的過(guò)程。
如下圖所示，parser向lexer要一個(gè)新的token，lexer會(huì)返回一個(gè)token, parser拿到token之后，會(huì)嘗試將這個(gè)token與某條語(yǔ)法規(guī)則進(jìn)行匹配。
如果該token匹配上了語(yǔ)法規(guī)則，parser會(huì)將一個(gè)對(duì)應(yīng)的節(jié)點(diǎn)添加到 parse tree （解析樹(shù)，如果是html就是dom tree，如果是css就是 cssom tree）中，然后繼續(xù)問(wèn)parser要下一個(gè)node。
當(dāng)然，也有可能該tokens沒(méi)有匹配上語(yǔ)法規(guī)則，parser會(huì)將tokens暫時(shí)保存，然后繼續(xù)問(wèn)lexer要tokens, 直至找到可與所有內(nèi)部存儲(chǔ)的標(biāo)記匹配的規(guī)則。如果找不到任何匹配規(guī)則，parser就會(huì)引發(fā)一個(gè)異常。這意味著文檔無(wú)效，包含語(yǔ)法錯(cuò)誤。
syntax analysis 的輸出結(jié)果是parse tree, parse tree 的結(jié)構(gòu)表示了句法結(jié)構(gòu)。比如說(shuō)我們輸入"John hit the ball"作為一句話，那么 syntax analysis 的結(jié)果就是：
一旦我們拿到了parse tree， 還有最后一步工作沒(méi)有做，那就是：translation，還有一些博客將這個(gè)過(guò)程成為 compilation / transpilation / interpretation
Lexicons 和 Syntaxes
上面提到了lexer 和 parser 這兩個(gè)用于解析工具，我們通常不會(huì)自己寫(xiě)，而是用現(xiàn)有的工具去生成。我們需要提供一個(gè)語(yǔ)言的 lexicon 和 syntaxes ，才可以生成相應(yīng)的 lexer 和 parser 。
webkit 使用的 lexer 和 parser 是 Flex 和 Bison 。
lexicons
lexicons 是通過(guò)正則表達(dá)式被定義的，比如說(shuō)，js中的保留字，就是lexicons 的一部分。
下面就是js中的保留字的正則表達(dá)式 的一部分。
/^(?!(?:do|if|in|for|let|new|try|var|case|else|enum|eval|false|null|this|true|void|with|break|catch|class|const|super|throw|while|yield|delete|export|import|public|return|static|switch|typeof|default|extends|finally|package|private|continue|debugger|function|arguments|interface|protected|implements|instanceof)$)*$/ 復(fù)制代碼syntaxes
syntaxes 通常是被一個(gè)叫無(wú)上下文語(yǔ)法所定義，關(guān)于無(wú)上下文語(yǔ)法可以點(diǎn)擊這個(gè)鏈接，反正只需要知道，無(wú)上下文語(yǔ)法要比常規(guī)的語(yǔ)法更復(fù)雜就好了。
BNF范式
非科班出身的前端可能不了解 BNF 范式（說(shuō)的就是我 --），它是一種形式化符號(hào)來(lái)描述給定語(yǔ)言的語(yǔ)法。
它的內(nèi)容大致為：
下面是用BNF來(lái)定義的Java語(yǔ)言中的For語(yǔ)句的實(shí)例。
FOR_STATEMENT ::= "for" "(" ( variable_declaration | ( expression ";" ) | ";" ) [ expression ] ";" [ expression ] ")" statement 復(fù)制代碼BNF 的誕生還是挺有意思的一件事情， 有了BNF才有了真正意義上的計(jì)算機(jī)語(yǔ)言。巴科斯范式直到今天，仍然是個(gè)迷，巴科斯是如何想到的
小結(jié)
我們現(xiàn)在對(duì)解析過(guò)程有了一個(gè)大致的了解，總結(jié)成一張圖就是這樣：
對(duì)解析（parse）有了初步的了解之后，我們看一下HTML的解析過(guò)程。
解析HTML
HTML是不規(guī)范的，我們?cè)趯?xiě)html的代碼時(shí)候，比如說(shuō)漏了一個(gè)閉合標(biāo)簽，瀏覽器也可以正常渲染沒(méi)有問(wèn)題的。這是一把雙刃劍，我們可以很容易的編寫(xiě)html, 但是卻給html的解析帶來(lái)不少的麻煩，更詳細(xì)的信息可以點(diǎn)擊：鏈接
HTML lexicon
Html 的 lexicon 主要包括6個(gè)部分：
- doctype
- start tag
- end tag
- comment
- character
- End-of-file
當(dāng)一個(gè)html文檔被lexer 處理的時(shí)候，lexer 從文檔中一個(gè)字符一個(gè)字符的讀出來(lái)，并且使用 finite-state machine 來(lái)判斷一個(gè)完整的token是否已經(jīng)被完整的收到了。
HTML syntax
這里就是html 解析的復(fù)雜所在了。html 標(biāo)簽的容錯(cuò)性很高，需要上下文敏感的語(yǔ)法。
比如說(shuō)對(duì)于下面兩段代碼：
<html lang="en-US"><head><title>Valid HTML</title></head><body><p>This is a paragraph. <span>This is a span.</span></p><div>This is a div.</div></body> </html> 復(fù)制代碼<html lAnG = EN-US> <p>This is a paragraph. <span>This is a span. <div>This is a div. 復(fù)制代碼第一段是規(guī)范的html代碼，第二段代碼有非常多的錯(cuò)誤，但是這兩段代碼在瀏覽器中都是大致相同的結(jié)構(gòu)：
上面兩處代碼渲染出來(lái)的唯一的不同就是，正確的html會(huì)在頭部有<!DOCTYPE html>, 這行代碼會(huì)觸發(fā)瀏覽器的標(biāo)準(zhǔn)模式。
所以你看，html 的容錯(cuò)性是非常高的，這樣是有代價(jià)的，這增加了解析的困難，讓詞法解析解析更加困難。
DOM Tree
HTML 解析出來(lái)的產(chǎn)物，經(jīng)過(guò)加工，就得到了DOM Tree。
對(duì)于下面這種html的結(jié)構(gòu)：
<html lang="en-US"><head><meta charset="UTF-8"><meta http-equiv="X-UA-Compatible" content="IE=Edge"><meta name="viewport"content="width=device-width, initial-scale=1, maximum-scale=1"></head><body><p>This is text in a paragraph.<img src="https://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Rubber_Duck_%288374802487%29.jpg/220px-Rubber_Duck_%288374802487%29.jpg"></p><div>This is text in a div.</div></body> </html> 復(fù)制代碼上面的html 的結(jié)構(gòu)解析出來(lái)應(yīng)該是：
說(shuō)完了html的解析，我們就該說(shuō)CSS的解析了。
解析CSS
和html 解析相比，css 的解析就簡(jiǎn)單很多了。
CSS lexicon
關(guān)于css的 lexicon，?the W3C’s CSS2 Level 2 specification 中已經(jīng)給出了。
CSS 中的 token 被列在了下面，下面的定義是采用了Lex風(fēng)格的正則表達(dá)式。
IDENT {ident} ATKEYWORD @{ident} STRING {string} BAD_STRING {badstring} BAD_URI {baduri} BAD_COMMENT {badcomment} HASH #{name} NUMBER {num} PERCENTAGE {num}% DIMENSION {num}{ident} URI url\({w}{string}{w}\) |url\({w}([!#$%&*-\[\]-~]|{nonascii}|{escape})*{w}\) UNICODE-RANGE u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})? CDO <!-- CDC --> : : ; ; { \{ } \} ( \( ) \) [ \[ ] \] S [ \t\r\n\f]+ COMMENT \/\*[^*]*\*+([^/*][^*]*\*+)*\/ FUNCTION {ident}\( INCLUDES ~= DASHMATCH |= DELIM any other character not matched by the above rules, and neither a single nor a double quote 復(fù)制代碼花括號(hào)里面的宏被定義成如下：
ident [-]?{nmstart}{nmchar}* name {nmchar}+ nmstart [_a-z]|{nonascii}|{escape} nonascii [^\0-\237] unicode \\[0-9a-f]{1,6}(\r\n|[ \n\r\t\f])? escape {unicode}|\\[^\n\r\f0-9a-f] nmchar [_a-z0-9-]|{nonascii}|{escape} num [0-9]+|[0-9]*\.[0-9]+ string {string1}|{string2} string1 \"([^\n\r\f\\"]|\\{nl}|{escape})*\" string2 \'([^\n\r\f\\']|\\{nl}|{escape})*\' badstring {badstring1}|{badstring2} badstring1 \"([^\n\r\f\\"]|\\{nl}|{escape})*\\? badstring2 \'([^\n\r\f\\']|\\{nl}|{escape})*\\? badcomment {badcomment1}|{badcomment2} badcomment1 \/\*[^*]*\*+([^/*][^*]*\*+)* badcomment2 \/\*[^*]*(\*+[^/*][^*]*)* baduri {baduri1}|{baduri2}|{baduri3} baduri1 url\({w}([!#$%&*-~]|{nonascii}|{escape})*{w} baduri2 url\({w}{string}{w} baduri3 url\({w}{badstring} nl \n|\r\n|\r|\f w [ \t\r\n\f]* 復(fù)制代碼CSS Syntax
下面是css的 syntax 定義：
stylesheet : [ CDO | CDC | S | statement ]*; statement : ruleset | at-rule; at-rule : ATKEYWORD S* any* [ block | ';' S* ]; block : '{' S* [ any | block | ATKEYWORD S* | ';' S* ]* '}' S*; ruleset : selector? '{' S* declaration? [ ';' S* declaration? ]* '}' S*; selector : any+; declaration : property S* ':' S* value; property : IDENT; value : [ any | block | ATKEYWORD S* ]+; any : [ IDENT | NUMBER | PERCENTAGE | DIMENSION | STRING| DELIM | URI | HASH | UNICODE-RANGE | INCLUDES| DASHMATCH | ':' | FUNCTION S* [any|unused]* ')'| '(' S* [any|unused]* ')' | '[' S* [any|unused]* ']'] S*; unused : block | ATKEYWORD S* | ';' S* | CDO S* | CDC S*; 復(fù)制代碼CSSOM Tree
CSS解析得到的parse tree 經(jīng)過(guò)加工之后，就得到了CSSOM Tree。 CSSOM 被稱為“css 對(duì)象模型”。
CSSOM Tree 對(duì)外定義接口，可以通過(guò)js去獲取和修改其中的內(nèi)容。開(kāi)發(fā)者可以通過(guò)document.styleSheets的接口獲取到當(dāng)前頁(yè)面中所有的css樣式表。
CSSOM
那么CSSOM 到底長(zhǎng)什么樣子呢，我們下面來(lái)看一下：
<!doctype html> <html lang="en"> <head><style>.test1 {color: red;}</style><style>.test2 {color: green;}</style><link rel="stylesheet" href="./test3.css"> </head> <body><div class="test1">TEST CSSOM1</div><div class="test2">TEST CSSOM2</div><div class="test3">TEST CSSOM3</div> </body> </html> 復(fù)制代碼上面的代碼在瀏覽器中打開(kāi)，然后在控制臺(tái)里面輸入document.styleSheets，就可以打印出來(lái)CSSOM，如下圖所示：
可以看到，CSSOM是一個(gè)對(duì)象，其中有三個(gè)屬性，均是 CSSStylelSheet 對(duì)象。CSSStylelSheet 對(duì)象用于表示每個(gè)樣式表。由于我們?cè)赿ocument里面引入了一個(gè)外部樣式表，和兩個(gè)內(nèi)聯(lián)樣式表，所以CSSOM對(duì)象中包含了3個(gè)CSSStylelSheet對(duì)象。
CSSStyleSheet
CSSStylelSheet對(duì)象又長(zhǎng)什么樣子呢？如下圖所示：
CSSStyleSheet 對(duì)象主要包括下面的屬性：
-
type
字符串 “text/css”
-
href
表示該樣式表的來(lái)源，如果是內(nèi)聯(lián)樣式，則href值為null
-
parentStyleSheet
父節(jié)點(diǎn)的styleSheet
-
ownerNode
該樣式表所匹配到的DOM節(jié)點(diǎn)，如果沒(méi)有則為空
-
ownerRule
父親節(jié)點(diǎn)的styleSheet中的樣式對(duì)本節(jié)點(diǎn)的合并
-
media
該樣式表中相關(guān)聯(lián)的 MediaList
-
title
style 標(biāo)簽的title屬性，不常見(jiàn)
<style title="papaya whip">body { background: #ffefd5; } </style> 復(fù)制代碼 -
disabled
是否禁用該樣式表，可通過(guò)js控制該屬性，從而控制頁(yè)面是否應(yīng)用該樣式表
樣式表的解析
瀏覽器的渲染引擎是從上往下進(jìn)行解析的。
當(dāng)渲染引擎遇到 <style> 節(jié)點(diǎn)的時(shí)候，會(huì)立馬暫停解析html, 轉(zhuǎn)而解析CSS規(guī)則，一旦CSS規(guī)則解析完成，渲染引擎會(huì)繼續(xù)解析html
當(dāng)渲染引擎遇到 <link>節(jié)點(diǎn)的時(shí)候，瀏覽器的網(wǎng)絡(luò)組件會(huì)發(fā)起對(duì) style 文件的請(qǐng)求，同時(shí)渲染引擎不會(huì)暫停，而是繼續(xù)往下解析。等到 style 文件從服務(wù)器傳輸?shù)綖g覽器的時(shí)候，渲染引擎立馬暫停解析html, 轉(zhuǎn)而解析CSS規(guī)則，一旦CSS規(guī)則解析完成，渲染引擎會(huì)繼續(xù)解析html。
可以聯(lián)想一下script的解析。
當(dāng)渲染引擎遇到 <script> 節(jié)點(diǎn)的時(shí)候，會(huì)立馬暫停解析html。
如果這個(gè) <script> 節(jié)點(diǎn)是內(nèi)聯(lián)，則 JS 引擎會(huì)馬上執(zhí)行js代碼，同時(shí)渲染引擎也暫停了工作。什么時(shí)候等 JS 代碼執(zhí)行完了，什么時(shí)候渲染引擎重新繼續(xù)工作。如果JS 代碼執(zhí)行不完，那渲染引擎就繼續(xù)等著吧。
如果這個(gè) <script> 節(jié)點(diǎn)是外鏈的，瀏覽器的網(wǎng)絡(luò)組件會(huì)發(fā)起對(duì) script 文件的請(qǐng)求，渲染引擎也暫停了執(zhí)行。什么時(shí)候等 JS 代碼下載完畢，并且執(zhí)行完了，什么時(shí)候渲染引擎重新繼續(xù)工作。
在2011年的時(shí)候，瀏覽器廠商推出了“推測(cè)性”解析的概念。
“推測(cè)性”解析就是，當(dāng)讓渲染引擎干等著js代碼下載和運(yùn)行的時(shí)候，會(huì)起一個(gè)第三個(gè)進(jìn)程，繼續(xù)解析剩下的html。當(dāng)js代碼下載好了，準(zhǔn)備開(kāi)始執(zhí)行js代碼的時(shí)候，第三個(gè)進(jìn)程就會(huì)馬上發(fā)起對(duì)剩下html所引用的資源——圖片，樣式表和js代碼的請(qǐng)求。
這樣就節(jié)省了之后加載和解析時(shí)間。
被稱為“推測(cè)性”解析是因?yàn)?#xff0c;前面的js代碼存在一定的概率修改DOM節(jié)點(diǎn)，有可能會(huì)讓后面的DOM節(jié)點(diǎn)消逝，那么我們的工作就白費(fèi)了。瀏覽器“推測(cè)”這樣的發(fā)生的概率比較小。
讓渲染引擎干等著不工作是非常低效率的，所以雅虎軍規(guī)會(huì)讓把 script 標(biāo)簽放在body的底部。
言歸正傳，樣式表放在head的前邊，有兩個(gè)原因：
Render Tree
當(dāng)瀏覽器忙著構(gòu)建DOM Tree和 CSSOM Tree的時(shí)候, 瀏覽器同時(shí)將兩者結(jié)合生成Render Tree。也就是說(shuō)，瀏覽器構(gòu)建DOM Tree和 CSSOM Tree ，和結(jié)合生成Render Tree，這兩個(gè)是同時(shí)進(jìn)行的。
Render Forest
Levi Weintraub（webkit 的作者之一）在一次分享（分享的視頻點(diǎn)這里，分享的ppt點(diǎn)這里）中開(kāi)玩笑說(shuō)，準(zhǔn)確的來(lái)說(shuō)，我們大家提的Render Tree應(yīng)該是Render Forest (森林)。因?yàn)槭聦?shí)上，存在多條Tree:
- render object tree ( 稍后會(huì)詳細(xì)講解)
- layer tree
- inline box tree
- style tee
這里做一點(diǎn)說(shuō)明。
有很多其他的文章中提到了 Render Tree，其中的每一個(gè)構(gòu)成的節(jié)點(diǎn)都是 Render Obejcts, 因此其他文章中的 Render Tree 概念，在本文中等同于 Render Object Tree （ Levi Weintraub 和 Webkit core 的叫法都是Render Object Tree, 其他文章中 Render Tree的本義也應(yīng)是 Render Object Tree）。
Render Object Tree 與 Dom Tree
DOM Tree 和 Render Object Tree 之間的關(guān)系是什么樣的？
Render Object Tree 并不嚴(yán)格等于Dom Tree，先看一張DOM Tree 和 Render Object Tree的直觀的對(duì)比圖：
上面左側(cè)DOM tree的節(jié)點(diǎn)對(duì)應(yīng)右側(cè)Render Object Tree上的節(jié)點(diǎn)。細(xì)心的你會(huì)注意到，上圖左側(cè)的DOM Tree中的HTMLDivElement 會(huì)變成RenderBlock, HTMLSpanElement 會(huì)變成RenderInline，也就是說(shuō)，DOM節(jié)點(diǎn)對(duì)應(yīng)的 render object 節(jié)點(diǎn)并不一樣。
DOM節(jié)點(diǎn)對(duì)應(yīng)的 render object 節(jié)點(diǎn)并不一樣分這幾種情況:
display : none 的DOM 節(jié)點(diǎn)沒(méi)有對(duì)應(yīng)的 Render Object Tree 的節(jié)點(diǎn)
這里的display:none 屬性，有可能是我們?cè)贑SS里面設(shè)置的，也有可能是瀏覽器默認(rèn)的添加的屬性。比如說(shuō)下面的元素就會(huì)有默認(rèn)的display:none的屬性。
- <head>
- <meta>
- <link>
- <script>
下面的各個(gè)DOM元素，會(huì)對(duì)應(yīng)多個(gè)Render Object Tree的節(jié)點(diǎn)
-
<input type="**color**">
-
<input type="**date**">
-
<input type="**file**">
-
<input type="**range**">
-
<input type="**radio**">
-
<input type="**checkbox**">
-
<select>
比如說(shuō)，<input type="range">?就會(huì)有兩個(gè)renderer：
脫離文檔流的情況，要么是float, 要么是position: absolute / fixed。
比如說(shuō)對(duì)于下面的結(jié)構(gòu)：
<body> <div><p>Lorem ipsum</p></div> </body> 復(fù)制代碼? 它的 DOM tree和 Render Tree 如下圖所示：
? 如果增加脫離文檔流的樣式，如下：
p {position: absolute; } 復(fù)制代碼? 情況就會(huì)變成下面這樣：
<p> 節(jié)點(diǎn)對(duì)應(yīng)的 Render Tree 的節(jié)點(diǎn)，從父節(jié)點(diǎn)脫離出來(lái)，掛到了頂部的RenderView 節(jié)點(diǎn)下面。
為什么脫離了文檔流的節(jié)點(diǎn)，在 Render Object Tree中的結(jié)構(gòu)不同？脫離了文檔流的節(jié)點(diǎn)在構(gòu)建Render Object Tree又是如何處理的？會(huì)在下面的內(nèi)容中介紹。
Render Object Tree 上的節(jié)點(diǎn)
render object tree 是由 render object 節(jié)點(diǎn)構(gòu)成的。render object 節(jié)點(diǎn)在不同的瀏覽器叫法不同，在webkit中被稱為 renderer, 或者 被稱為 render objects, 在firfox中，被稱為frames。
render object 的節(jié)點(diǎn)的類是 RenderObject，定義在源碼的目錄webkit/Source/WebCore/rendering/RenderObject.h中。
下面是RenderObject.h的簡(jiǎn)化版本：
// Credit to Tali Garsiel for this simplified version of WebCore's RenderObject.h class RenderObject {virtual void layout();virtual void paint(PaintInfo);virtual void rect repaintRect();Node* node; // 這個(gè)render tree的節(jié)點(diǎn)所指向的那個(gè)Dom節(jié)點(diǎn)RenderStyle* style; // 這個(gè)render tree節(jié)點(diǎn)的計(jì)算出來(lái)的樣式RenderLayer* containingLayer; // 包含這個(gè) render tree 的 z-index layer } 復(fù)制代碼RenderBox?是RenderObject的一個(gè)子類，它主要是負(fù)責(zé)DOM樹(shù)上的每一個(gè)節(jié)點(diǎn)的盒模型。
RenderBox?包括一些計(jì)算好尺寸的信息，比如說(shuō)：
- height
- width
- padding
- border
- margin
- clientLeft
- clientTop
- clientWidth
- clientHeight
- offsetLeft
- offsetTop
- offsetWidth
- offsetHeight
- scrollLeft
- scrollTop
- scrollWidth
- scrollHeight
render object 的節(jié)點(diǎn)的作用如下：
-
負(fù)責(zé) layout 和 paint
-
負(fù)責(zé)查詢DOM元素查詢尺寸API
比如說(shuō)獲取offsetHeight, offsetWidth的屬性
render object 節(jié)點(diǎn)的類型
我們?cè)贑SS中接觸過(guò)文檔流的概念，文檔流中的元素分為塊狀元素和行內(nèi)元素，比如說(shuō)div是塊狀元素，span是行內(nèi)元素。塊狀元素和行內(nèi)元素在文檔流中的表現(xiàn)不同，就是在這里決定的。
Render Object 的節(jié)點(diǎn)類型分為下面幾種：
RenderBlock
display: block 的DOM節(jié)點(diǎn)對(duì)應(yīng)的render object節(jié)點(diǎn)類型為RenderBlock
RenderInline
display:inline 的DOM節(jié)點(diǎn)對(duì)應(yīng)的render object節(jié)點(diǎn)類型為RenderInline
RenderReplaced
可能我們之前聽(tīng)說(shuō)過(guò)“替換元素” 的概念，比如說(shuō)常見(jiàn)的“替換元素”有下面：
- <iframe>
- <video>
- <embed>
- <img>
為啥被稱為“替換元素”，是因?yàn)樗麄兊膬?nèi)容會(huì)被一個(gè)獨(dú)立于HTML/CSS上下文的外部資源所替代。
“替代元素” 的DOM節(jié)點(diǎn)對(duì)應(yīng)的render object 節(jié)點(diǎn)類型為RenderReplaced
RenderTable
<table> 元素的DOM節(jié)點(diǎn)對(duì)應(yīng)的render object 節(jié)點(diǎn)類型為 RenderTable
RenderText
文本內(nèi)容的DOM節(jié)點(diǎn)對(duì)應(yīng)的render object 的節(jié)點(diǎn)類型為 RenderText
源碼大概長(zhǎng)這個(gè)樣子：
RenderObject* RenderObject::createObject(Node* node, RenderStyle* style) {Document* doc = node->document();RenderArena* arena = doc->renderArena();...RenderObject* o = 0;switch (style->display()) {case NONE:break;case INLINE:o = new (arena) RenderInline(node);break;case BLOCK:o = new (arena) RenderBlock(node);break;case INLINE_BLOCK:o = new (arena) RenderBlock(node);break;case LIST_ITEM:o = new (arena) RenderListItem(node);break;...}return o; } 復(fù)制代碼上面5中類型的Render Object 的節(jié)點(diǎn)之間的關(guān)系組合并不是沒(méi)有準(zhǔn)則的，在我們寫(xiě)出嵌套不規(guī)范的HTML時(shí)，渲染引擎幫我們做了很多事情。
Anonymous renderers
render object tree 遵守2個(gè)準(zhǔn)則：
- 在文檔流中的塊狀元素的子節(jié)點(diǎn)，要么都是塊狀元素，要么都是行內(nèi)元素。
- 在文檔流中的行內(nèi)元素的子節(jié)點(diǎn)，只能都是行內(nèi)元素。
anonymounse renderers（匿名的render object 節(jié)點(diǎn)）就是用于處理不遵守這兩種規(guī)則的代碼的，如果出現(xiàn)不符合這兩個(gè)準(zhǔn)則的情況，比如說(shuō)下面：
上面的代碼中，最外層的div節(jié)點(diǎn)有兩個(gè)子節(jié)點(diǎn)，第一個(gè)子節(jié)點(diǎn)是行內(nèi)元素，第二個(gè)子節(jié)點(diǎn)是塊狀元素。render object tree 中會(huì)構(gòu)建一個(gè)anonymounse renderer去包裹 text 節(jié)點(diǎn)，因此上面的代碼變成了下面的：
<div><anonymous block>Some text</anonymous block><div>Some more text</div> </div> 復(fù)制代碼上面的代碼中，render object tree需要做更多的事情去修復(fù)這種糟糕的DOM tree: 三個(gè)anonymounse renderers會(huì)被創(chuàng)建，上面的代碼會(huì)被分割成三段，被三個(gè)匿名的block 包裹。
<anonymous pre block><i>Italic only <b>italic and bold</b></i> </anonymous pre block><anonymous middle block><div>Wow, a block!</div><div>Wow, another block!</div> </anonymous middle block><anonymous post block><i><b>More italic and bold text</b> More italic text</i> </anonymous post block>復(fù)制代碼注意到，<i> 元素和 <b> 元素都被分割進(jìn)了<anonymous pre block> 和 <anonymous post block> 兩個(gè)類型為 RenderBlock 的節(jié)點(diǎn)中，他們通過(guò)一種叫*continuation chain（延續(xù)鏈）*的機(jī)制來(lái)鏈接。
負(fù)責(zé)上面遞歸拆分行內(nèi)元素的生產(chǎn)*continuation chain（延續(xù)鏈）*的方法被稱為 splitFlow。
因此，一旦你寫(xiě)出了不符合規(guī)范的html結(jié)構(gòu)， 在構(gòu)建render object tree時(shí)就需要更多的工作去糾正，從而造成頁(yè)面性能的下降。
構(gòu)建 Render Object Tree
Gecko 和 WebKit 采用了不同的方案來(lái)構(gòu)建 Render Tree。
Gecko 是把樣式計(jì)算和構(gòu)建Render Object Tree 的工作代理到 FrameConstructor 對(duì)象上。而 webkit 采用的方案是，每一個(gè)DOM節(jié)點(diǎn)自己計(jì)算自己的樣式，并且構(gòu)建自己 的Render object tree 對(duì)應(yīng)的節(jié)點(diǎn)。
Gecko 針對(duì)DOM的更新增加了一個(gè) listener，當(dāng)DOM 更新的時(shí)候，更新的DOM節(jié)點(diǎn)被傳到一個(gè)指定的對(duì)象FrameConstructor, 這個(gè)FrameConstructor 會(huì)為 DOM 節(jié)點(diǎn)計(jì)算樣式，同時(shí)為這個(gè)DOM節(jié)點(diǎn)創(chuàng)建一個(gè)合適的 Render Object Tree節(jié)點(diǎn)。
WebKit構(gòu)建 Render Object tree 的過(guò)程被稱為attachment, 每一個(gè)DOM節(jié)點(diǎn)被賦予一個(gè) attach() 方法，這是一個(gè)同步的方法，當(dāng)每一個(gè)DOM節(jié)點(diǎn)被插入DOM樹(shù)的時(shí)候， 該DOM節(jié)點(diǎn)的attach()方法就會(huì)被調(diào)用。
樣式計(jì)算
在構(gòu)建Render Object Tree的時(shí)候，需要進(jìn)行樣式計(jì)算，也就是Render Tree每一個(gè)節(jié)點(diǎn)都需要有一個(gè)visual information的信息，才可以被繪制在屏幕上，這就需要樣式計(jì)算這一過(guò)程。
而樣式計(jì)算需要兩部分“原材料”：
DOM Tree在HTML解析之后就可以拿到了，一堆樣式規(guī)則可以來(lái)自下面：
- 瀏覽器默認(rèn)的樣式
- 外鏈樣式
- 內(nèi)聯(lián)樣式
- DOM節(jié)點(diǎn)上的style屬性
那么樣式規(guī)則是如何構(gòu)成的呢？
- 樣式表是一堆 規(guī)則（rules）的集合；
- 當(dāng)然也不光都是 規(guī)則（rules）, 還會(huì)有一些奇怪的東西：@import, @media, @namespace 等等
- 一個(gè)**規(guī)則（rules）是由選擇器（selector）和聲明塊（declaration block）**構(gòu)成的
- **聲明塊（declaration block）由一堆聲明（declaration）**加中括號(hào)構(gòu)成
- **聲明（declaration ** 由 property 和 value 構(gòu)成。
樣式計(jì)算存在以下三個(gè)難點(diǎn)：
下面我們介紹這個(gè)三個(gè)難點(diǎn)是如何解決的。
樣式規(guī)則的應(yīng)用順序
某一個(gè)DOM節(jié)點(diǎn)上可能有多個(gè)規(guī)則，比如下下面：
div p {color: goldenrod; } p {color: red; }復(fù)制代碼那么這個(gè)DOM節(jié)點(diǎn)究竟用的是哪個(gè)規(guī)則？
規(guī)則的權(quán)重是：先看 order , 然后再算specificity, 最后再看哪個(gè)規(guī)則靠的更近。
order
order的權(quán)重從高到底：
Specificity
Specificity是一個(gè)相加起來(lái)的值
#foo .bar > [name="baz"]::first-line {} /* Specificity: 0 1 2 1 */復(fù)制代碼第一位的數(shù)值（a）
是否有DOM節(jié)點(diǎn)上style屬性的值，有則是1，否則是0
第二位的數(shù)值 (b)
id選擇器的數(shù)量之和
第三位的數(shù)值 (c)
class選擇器，屬性選擇器，偽類選擇器個(gè)數(shù)之和
第四位的數(shù)值 (d)
標(biāo)簽選擇器，偽元素選擇器個(gè)數(shù)之和
下面是例子：
* {} /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */li {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */li:first-line {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */ul li {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */ul ol+li {} /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */h1 + *[rel=up]{} /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */ul ol li.red {} /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */li.red.level {} /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */#x34y {} /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */style="" /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */復(fù)制代碼style數(shù)據(jù)太多，占用大量?jī)?nèi)存
這里的style數(shù)據(jù)太多，不是說(shuō)我們寫(xiě)的css樣式太多，而是Render Object Tree每一個(gè)節(jié)點(diǎn)上都需要存儲(chǔ)全部的CSS樣式，那些沒(méi)有被指定的樣式，其值為繼承父節(jié)點(diǎn)的樣式，或者是瀏覽器的默認(rèn)樣式，或者干脆是個(gè)空值。
webkit 和 gecko 采用了不同的解決方案。
webkit：共享樣式數(shù)據(jù)
WebKit 的解決方案是，節(jié)點(diǎn)們會(huì)引用RenderStyle對(duì)象。這些對(duì)象在以下情況下可以由不同的DOM節(jié)點(diǎn)共享，從而節(jié)省空間和提高性能。
- 這些節(jié)點(diǎn)是同級(jí)關(guān)系
- 這些節(jié)點(diǎn)有相同的偽類狀態(tài)：hover、：active、：focus
- 這些節(jié)點(diǎn)都沒(méi)有id
- 這些節(jié)點(diǎn)有相同的tag名稱
- 這些節(jié)點(diǎn)有相同的class
- 這些節(jié)點(diǎn)都沒(méi)有通過(guò)style屬性設(shè)置的樣式
- 這些節(jié)點(diǎn)沒(méi)有一個(gè)是使用 兄弟選擇器的，比如說(shuō)： div + p,?div ~ p,?:last-child,?:first-child,?:nth-child(),?:nth-of-type()
Gecko：style struct sharing
Gecko 采用了一種 style struct sharing 的機(jī)制。有一些css屬性可以聚合在一起，比如說(shuō)font-size, font-family, color 等等，瀏覽器就把這些可以被劃分為一組的屬性，單獨(dú)的保存到一個(gè)對(duì)象里面，這個(gè)對(duì)象被稱為 style struct。如下表所示：
上圖中的，computed style 里就不用存儲(chǔ)CSS全部的200多個(gè)屬性，而是保存著對(duì)這些 style struct對(duì)象的引用。
這樣一來(lái)，一些具有相同屬性的DOM 節(jié)點(diǎn)就可以引用相同的 style struct， 不僅如此，因?yàn)樽庸?jié)點(diǎn)有一些屬性會(huì)繼承父節(jié)點(diǎn)，那么保存這些屬性的 style struct 就會(huì)被父節(jié)點(diǎn)和子節(jié)點(diǎn)所共享。
匹配元素會(huì)影響性能
對(duì)于每一個(gè)DOM節(jié)點(diǎn)，css引擎需要去遍歷所有的css規(guī)則看是否匹配。對(duì)于大部分的DOM節(jié)點(diǎn)，css規(guī)則的匹配并不會(huì)發(fā)生改動(dòng)。
比如說(shuō)，用戶把鼠標(biāo)hover到一個(gè)父元素上面，這個(gè)父元素的css規(guī)則匹配是發(fā)生了變化，我們不僅僅要重新計(jì)算這個(gè)父元素的樣式，還需要重新計(jì)算這個(gè)父元素的子元素的樣式（因?yàn)橐幚砝^承的樣式），但是能匹配這些子元素的樣式規(guī)則，是不會(huì)變的。
如果我們能記下來(lái)，有哪些selector可以匹配到就好了。
為了優(yōu)化這一點(diǎn)，CSS 引擎在進(jìn)行 selector 匹配時(shí)，會(huì)根據(jù)權(quán)重的順序把他們排成一串，然后把這一串加到右邊的 CSS rule tree 上面。
CSS引擎希望右邊CSS rule tree 的分支數(shù)越少越好，因此會(huì)將新加入的一串盡量的合并到已有的分支，所以上面的過(guò)程會(huì)是下面這樣的：
然后遍歷每一個(gè)DOM節(jié)點(diǎn)去找能匹配到的CSS Rule Tree的分支，從CSS rule Tree的底部開(kāi)始，一路向上開(kāi)始匹配，直到找到對(duì)應(yīng)的那一條 style rule Tree分支。這就是人們口中常說(shuō)的，css選擇器是從右邊匹配的。
當(dāng)瀏覽器因?yàn)槟撤N原因（用戶交互，js修改DOM）進(jìn)行重新渲染的時(shí)候，CSS引擎會(huì)快速檢查一下，對(duì)父節(jié)點(diǎn)的改動(dòng)是否會(huì)影響到子節(jié)點(diǎn)的 selector 匹配，如果不影響，CSS引擎就直接拿到每一個(gè)子節(jié)點(diǎn)對(duì)CSS rule Tree 對(duì)應(yīng)那個(gè)分支的指針，節(jié)省掉匹配選擇器的時(shí)間。
盡管如此，我們還是需要在第一次遍歷每一個(gè)DOM節(jié)點(diǎn)去找到對(duì)應(yīng)的CSS Rule Tree的分支。如果我們有10000個(gè)相同的節(jié)點(diǎn)，就需要遍歷10000次。
Gecko 和 Webkit 都對(duì)此進(jìn)行了優(yōu)化，在遍歷完一個(gè)節(jié)點(diǎn)之后，會(huì)把計(jì)算好的樣式放到緩存中，在遍歷下一個(gè)節(jié)點(diǎn)之前，會(huì)做一個(gè)判斷，看是否可以復(fù)用緩存中的樣式。
這個(gè)判斷包括一下幾點(diǎn)：
兩個(gè)節(jié)點(diǎn)是否有相同的id, class
兩個(gè)節(jié)點(diǎn)是否有相同的style 屬性
兩個(gè)節(jié)點(diǎn)對(duì)應(yīng)的父親節(jié)點(diǎn)是否共享一份計(jì)算好的樣式，那該兩個(gè)節(jié)點(diǎn)繼承的樣式也是相同的。
解析階段如何優(yōu)化
更加符合規(guī)范的html結(jié)構(gòu)
上面在構(gòu)建render object tree 的過(guò)程中，會(huì)額外做很多工作處理我們不符合規(guī)范的DOM 結(jié)構(gòu)，比如說(shuō)，調(diào)用splitflow 方法分割代碼，用 anonymous renderBlock 包裹不符合規(guī)范的節(jié)點(diǎn)。
之前我們都聽(tīng)過(guò)建議：“要編寫(xiě)更有語(yǔ)義，更符合規(guī)范的html結(jié)構(gòu)“，原因就在于此，可以讓渲染引擎做更少的事情。
下面是模擬一種不不符合規(guī)范的情況:
<i v-for="n in 1000">Italic only<b>italic and bold<div>Wow, a block!</div><div>Wow, another block!<b>More italic and bold text</b><div>More italic and bold text<p>More italic and bold text</p></div></div>More italic and bold textMore italic and bold text</b> More italic text</i>復(fù)制代碼在控制臺(tái)里面，設(shè)置cpu 為6x slowdown，然后記錄渲染數(shù)據(jù)如下：
其中花費(fèi)了 12888ms 進(jìn)行了rendering 過(guò)程。
如果我們對(duì)html代碼僅僅做幾處修改，在不考慮css優(yōu)化、樣式優(yōu)化的前提下：
<div v-for="n in nums"><p>Italic only</p><div>italic and bold<div>Wow, a block!</div><div>Wow, another block!<b>More italic and bold text</b><div>More italic and bold text<p>More italic and bold text</p></div></div>More italic and bold textMore italic and bold text</div></div>復(fù)制代碼在控制臺(tái)里面，設(shè)置cpu 為6x slowdown，然后記錄渲染數(shù)據(jù)如下：
可以發(fā)現(xiàn)，render 階段的渲染時(shí)間為11506ms，rendering 階段渲染的時(shí)間相比于12888ms減少了1382ms，時(shí)間縮短了12%
一次測(cè)量可能有誤差，但無(wú)論進(jìn)行多次測(cè)量，都會(huì)發(fā)現(xiàn)第二種的代碼的渲染時(shí)間要小于第一種代碼的渲染時(shí)間。
選擇器的優(yōu)化
不同的選擇器，匹配的效率會(huì)有差距，但是差距不大。
我們用一個(gè)有1000個(gè)DOM節(jié)點(diǎn)的頁(yè)面來(lái)測(cè)試，分別在5個(gè)瀏覽器中嘗試以下20種匹配器：
1. Data Attribute (unqualified)*/[data-select] {color: red;}/*2. Data Attribute (qualified)a[data-select] {color: red;}*//*3. Data Attribute (unqualified with value)[data-select="link"] {color: red;}*//*4. Data Attribute (qualified with value)a[data-select="link"] {color: red;}*//*5. Multiple Data Attributes (qualified with values)div[data-div="layer1"] a[data-select="link"] {color: red;}*//*6. Solo Pseudo selectora:after {content: "after";color: red;}*//*7. Combined classes.tagA.link {color: red;}*//*8. Multiple classes .tagUl .link {color: red;}*//*9. Multiple classes (using child selector).tagB > .tagA {color: red;}*//*10. Partial attribute matching[class^="wrap"] {color: red;} *//*11. Nth-child selector.div:nth-of-type(1) a {color: red;}*//*12. Nth-child selector followed by nth-child selector.div:nth-of-type(1) .div:nth-of-type(1) a {color: red;}*//*13. Insanity selection (unlucky for some)div.wrapper > div.tagDiv > div.tagDiv.layer2 > ul.tagUL > li.tagLi > b.tagB > a.TagA.link {color: red;}*//*14. Slight insanity.tagLi .tagB a.TagA.link {color: red;}*//*15. Universal* {color: red;}*//*16. Element singlea {color: red;}*//*17. Element doublediv a {color: red;}*//*18. Element treblediv ul a {color: red;}*//*19. Element treble pseudodiv ul a:after; {content: "after";color: red;}*//*20. Single class.link {color: red;} 復(fù)制代碼測(cè)試的結(jié)果如下：
| 1 | 56.8 | 125.4 | 63.6 | 152.6 | 1455.2 |
| 2 | 55.4 | 128.4 | 61.4 | 141 | 1404.6 |
| 3 | 55 | 125.6 | 61.8 | 152.4 | 1363.4 |
| 4 | 54.8 | 129 | 63.2 | 147.4 | 1421.2 |
| 5 | 55.4 | 124.4 | 63.2 | 147.4 | 1411.2 |
| 6 | 60.6 | 138 | 58.4 | 162 | 1500.4 |
| 7 | 51.2 | 126.6 | 56.8 | 147.8 | 1453.8 |
| 8 | 48.8 | 127.4 | 56.2 | 150.2 | 1398.8 |
| 9 | 48.8 | 127.4 | 55.8 | 154.6 | 1348.4 |
| 10 | 52.2 | 129.4 | 58 | 172 | 1420.2 |
| 11 | 49 | 127.4 | 56.6 | 148.4 | 1352 |
| 12 | 50.6 | 127.2 | 58.4 | 146.2 | 1377.6 |
| 13 | 64.6 | 129.2 | 72.4 | 152.8 | 1461.2 |
| 14 | 50.2 | 129.8 | 54.8 | 154.6 | 1381.2 |
| 15 | 50 | 126.2 | 56.8 | 154.8 | 1351.6 |
| 16 | 49.2 | 127.6 | 56 | 149.2 | 1379.2 |
| 17 | 50.4 | 132.4 | 55 | 157.6 | 1386 |
| 18 | 49.2 | 128.8 | 58.6 | 154.2 | 1380.6 |
| 19 | 48.6 | 132.4 | 54.8 | 148.4 | 1349.6 |
| 20 | 50.4 | 128 | 55 | 149.8 | 1393.8 |
| Biggest Diff. | 16 | 13.6 | 17.6 | 31 | 152 |
| Slowest | 13 | 6 | 13 | 10 | 6 |
解釋
在瀏覽器的引擎內(nèi)部，這些選擇器會(huì)被重新的拆分，組合，優(yōu)化，編譯。而不同的瀏覽器內(nèi)核采用不同的方案，所以幾乎沒(méi)有辦法預(yù)測(cè)，選擇器的優(yōu)化究竟能帶來(lái)多少收益。
結(jié)論：
合理的使用選擇器，比如說(shuō)層級(jí)更少的class，的確會(huì)提高匹配的速度，但是速度的提高是有限的 。
如果你通過(guò)dev tool 發(fā)現(xiàn)匹配選擇器的確是瓶頸，那么就選擇優(yōu)化它。
精簡(jiǎn)沒(méi)有用的樣式代碼
大量無(wú)用代碼會(huì)拖慢瀏覽器的解析速度。
用一個(gè)3000行的無(wú)用css樣式表和1500行的無(wú)用樣式表，進(jìn)行測(cè)試：
| 3000 | 64.4 | 237.6 | 74.2 | 436.8 | 1714.6 |
| 1500 | 51.6 | 142.8 | 65.4 | 358.6 | 1412.4 |
對(duì)于火狐來(lái)說(shuō)，在其他環(huán)節(jié)一致的情況下，頁(yè)面渲染的速度幾乎提升了一倍
盡管現(xiàn)在的慣例是把css 打包成一個(gè)巨大單一的css文件。這樣做的確是有好處的，減少http請(qǐng)求的數(shù)量。但是拆分css文件可以讓加載速度更快，瀏覽器的解析速度更快。
這一項(xiàng)的優(yōu)化是非常顯著的，通?？梢允∠聛?lái) 2ms ~ 300ms的時(shí)間。
精簡(jiǎn)的過(guò)程可以使用uncss 工具來(lái)自動(dòng)化的完成。
瀏覽器渲染第二步：layout
在上一節(jié)我們提到了 render object tree， render object 的節(jié)點(diǎn)第一次被創(chuàng)建然后添加到 render object tree時(shí)，它身上沒(méi)有關(guān)于位置和尺寸的信息。接下來(lái)，確定每一個(gè)render object的位置和尺寸的過(guò)程被稱為layout。
我們能在不同的文章中看到不同的名詞： 布局 ，layout , 回流 ， reflow , 這些名詞說(shuō)的都是一回事，不同瀏覽器的叫法不同。
每一個(gè)renderer節(jié)點(diǎn) 都有l(wèi)ayout 方法。 在構(gòu)建renderer節(jié)點(diǎn)的時(shí)候就聲明了這個(gè)方法：
class RenderObject {virtual void layout();virtual void paint(PaintInfo);virtual void rect repaintRect();Node* node; // 這個(gè)render tree的節(jié)點(diǎn)所指向的那個(gè)Dom節(jié)點(diǎn)RenderStyle* style; // 這個(gè)render tree節(jié)點(diǎn)的計(jì)算出來(lái)的樣式RenderLayer* containingLayer; // 包含這個(gè) render tree 的 z-index layer } 復(fù)制代碼layout （）是一個(gè)遞歸的過(guò)程。layout 過(guò)程究竟是誰(shuí)來(lái)負(fù)責(zé)的呢？ 一個(gè)名為 FrameView 的 class。
FrameView 可以運(yùn)行下面兩種類型的 layout :
全局layout
render tree 的根節(jié)點(diǎn)自身的layout方法被調(diào)用，然后整個(gè)render tree 被更新。
局部layout
只是區(qū)域性的更新，只適用于某個(gè)分支的改動(dòng)不會(huì)影響到周圍的分支。
目前局部layout只會(huì)在 text 更新的時(shí)候使用
Dirty Bits
在layout 階段，采用一種稱為 Dirty Bits 的機(jī)制去判斷一個(gè)節(jié)點(diǎn)是否需要layout。當(dāng)一個(gè)新的節(jié)點(diǎn)被插到tree中時(shí)，它不僅僅“弄臟“了它自身，還“弄臟“了相關(guān)的父節(jié)點(diǎn)（the relevant ancestor chain，下面會(huì)介紹）。有沒(méi)有被“弄臟”是通過(guò)設(shè)置bits （set bits）來(lái)標(biāo)識(shí)的。
bool needsLayout() const { return m_needsLayout || m_normalChildNeedsLayout || m_posChildNeedsLayout; } 復(fù)制代碼上面 needsLayout 為 true 有三種情況：
selfNeedsLayout
Rederer 自身是 “臟”的。當(dāng)一個(gè) rederer 自身被設(shè)置為“臟”的，它相關(guān)的父親節(jié)點(diǎn)也會(huì)被設(shè)置一個(gè)標(biāo)識(shí)來(lái)指出它們有一個(gè)“臟”的子節(jié)點(diǎn)
posChildNeedsLayout
設(shè)置了postion不為static的子節(jié)點(diǎn)被弄臟了
normalChildNeedsLayout
在文檔流中的子節(jié)點(diǎn)被弄臟了
上面之所以要區(qū)分子節(jié)點(diǎn)是否在文檔流中，是為了layout過(guò)程的優(yōu)化。
Containing Block （包含塊）
上面提到了相關(guān)父節(jié)點(diǎn)（the relevant ancestor chain），那么究竟是如何判斷哪個(gè)節(jié)點(diǎn)是 **相關(guān)父節(jié)點(diǎn) **？
答案就是通過(guò) containing block.
Container Block(包含塊) 身份有兩個(gè)
子節(jié)點(diǎn)的相關(guān)的父節(jié)點(diǎn)
子節(jié)點(diǎn)的相對(duì)坐標(biāo)系
子節(jié)點(diǎn)都有 XPos 和 YPos 的坐標(biāo)，這些坐標(biāo)都是相對(duì)于他們的Containing Block （包含塊）而言的。
下面介紹Container Block(包含塊) 概念。
包含塊的定義
通俗來(lái)講，Container Block 是決定子節(jié)點(diǎn)位置的父節(jié)點(diǎn)。每個(gè)子節(jié)點(diǎn)的位置都是相對(duì)于其container block來(lái)計(jì)算的。更詳細(xì)的信息可以點(diǎn)這個(gè) css2.1 官方的解釋點(diǎn)這里
有一種特殊的containing block —— initial containing block (最初的container block)。
當(dāng)Docuement 節(jié)點(diǎn)上的 renderer() 方法被調(diào)用時(shí)，會(huì)返回一個(gè)節(jié)點(diǎn)對(duì)象為render tree 的根節(jié)點(diǎn)，被稱作 RenderView, RenderView 對(duì)應(yīng)的containing bock 就是 initial containing block。
initial containing block 的尺寸永遠(yuǎn)是viewport的尺寸，且永遠(yuǎn)是相對(duì)于整個(gè)文檔的 position(0,0) 的位置。下面是圖示：
黑色的框代表的是 initial containing block (最初的container block) , 灰色的框表示整個(gè) document。當(dāng)document往下滾動(dòng)的時(shí)候， initial containing block (最初的container block) 就會(huì)被移出了屏幕。 initial containing block (最初的container block) 始終在document 的頂部，并且大小始終是 viewport 的尺寸。
那么render Tree上的節(jié)點(diǎn)，它們各自的 containing block 是什么？
-
根節(jié)點(diǎn)的 containing block 始終是 RenderView
-
如果一個(gè)renderer節(jié)點(diǎn)的css postion 的值為 relative 或 static，則其 containing block 為最近的父節(jié)點(diǎn)
-
如果一個(gè)renderer節(jié)點(diǎn)的css postion 的值為 absolute, 則其containing block 為最近的 css postion 的值不為static 的父節(jié)點(diǎn)。如果這樣的父節(jié)點(diǎn)不存在，則為 RenderView，也就是根節(jié)點(diǎn)的containing block
-
如果一個(gè)renderer節(jié)點(diǎn)的css postion 的值為 fixed。這個(gè)情況有一些特殊，因?yàn)?W3C 標(biāo)準(zhǔn)和 webkit core 介紹的不一樣。W3C 最新的標(biāo)準(zhǔn)認(rèn)為css postion 的值為 fixed的renderer節(jié)點(diǎn)的containing block是viewport ，原文如下：
而webkit core 認(rèn)為css postion 的值為 fixed的renderer節(jié)點(diǎn)的containing block是RenderView。RenderView并不會(huì)表現(xiàn)的和viewport一樣，但是RenderView會(huì)根據(jù)頁(yè)面滾動(dòng)的距離算出css postion 的值為 fixed的renderer節(jié)點(diǎn)的位置。這是因?yàn)閱为?dú)為viewport 生成一個(gè)renderer 節(jié)點(diǎn)并不簡(jiǎn)單。原文如下：
render tree 有兩個(gè)方法用來(lái)判斷 renderer 的position:
bool isPositioned() const; // absolute or fixed positioning bool isRelPositioned() const; // relative positioning復(fù)制代碼render tree 有一個(gè)方法用來(lái)獲取某一個(gè)塊狀 rederer 的containing block（相對(duì)父節(jié)點(diǎn)）
RenderBlock* containingBlock() const復(fù)制代碼render tree 還有一個(gè)方法是兼容了行內(nèi)元素獲取相對(duì)父節(jié)點(diǎn)的方法，用來(lái)代替containingBlock (因?yàn)閏ontainingBlock只適用于塊狀元素)
RenderObject* container() const復(fù)制代碼當(dāng)一個(gè) renderer 被標(biāo)記為需要 layout的時(shí)候，就會(huì)通過(guò)container()找到相對(duì)父節(jié)點(diǎn)，把isPositioned 的狀態(tài)傳遞給相對(duì)父節(jié)點(diǎn)。如果 renderer 的position是absolute 或 fixed ，則相對(duì)父節(jié)點(diǎn)的posChildNeedsLayout為true，如果 renderer的position 是 static 或 relative , 則相對(duì)父節(jié)點(diǎn)的 normalChildNeedsLayout 為 true。
會(huì)觸發(fā)layout 的屬性
盒子模型相關(guān)的屬性
-
width
-
height
-
padding
-
margin
-
border
-
display
-
……
定位屬性和浮動(dòng)
- top
- bottom
- left
- right
- position
- float
- clear
節(jié)點(diǎn)內(nèi)部的文字結(jié)構(gòu)
- text - aligh
- overflow
- font-weight
- font- family
- font-size
- line-height
上面只是一部分，更全部的可以點(diǎn)擊 csstriggers 來(lái)查閱；
csstrigger 里面需要注意的有幾點(diǎn)。
opacity的改動(dòng)，在blink內(nèi)核和Gecko內(nèi)核上不會(huì)觸發(fā)layout 和 repaint
transform的改動(dòng)，在blink內(nèi)核和Gecko內(nèi)核上不會(huì)觸發(fā)layout 和 repaint
visibility 的改動(dòng)，在Gecko 內(nèi)核上不會(huì)觸發(fā) layout repaint, 和 composite
會(huì)觸發(fā)layout 的方法
幾乎任何測(cè)量元素的寬度，高度，和位置的方法都會(huì)不可避免的觸發(fā)reflow, 包括但是不限于：
- elem.getBoundingClientRect()
- window.getComputedStyle()
- window.scrollY
- and a lot more…
如何避免重復(fù)Layout
不要頻繁的增刪改查DOM
不要頻繁的修改默認(rèn)根字體大小
不要一條條去修改DOM樣式，而是通過(guò)切換className
雖然切換className 也會(huì)造成性能上的影響，但是次數(shù)上減少了。
“離線”修改DOM
比如說(shuō)一定要修改這個(gè)dom節(jié)點(diǎn)100次，那么先把dom的display設(shè)置為 none ( 僅僅會(huì)觸發(fā)一次回流 )
使用flexbox
老的布局模型以相對(duì)/絕對(duì)/浮動(dòng)的方式將元素定位到屏幕上 Floxbox布局模型用流式布局的方式將元素定位到屏幕上，flex性能更好。
不要使用table
使用table布局哪怕一個(gè)很小的改動(dòng)都會(huì)造成重新布局
避免強(qiáng)制性的同步layout
layout根據(jù)區(qū)域來(lái)劃分的，分為全局性layout, 和局部的layout。比如說(shuō)修改根字體的大小，會(huì)觸發(fā)全局性layout。
全局性layout是同步的，會(huì)立刻馬上被執(zhí)行，而局部性的layout是異步的，分批次的。瀏覽器會(huì)嘗試合并多次局部性的layout為一次，然后異步的執(zhí)行一次，從而提高效率。
但是js一些操作會(huì)觸發(fā)強(qiáng)制性的同步布局，從而影響頁(yè)面性能，比如說(shuō)讀取 offsetHeight、offsetWidth 值的時(shí)候。
瀏覽器渲染第三步：paint
第三個(gè)階段是paint 階段
會(huì)觸發(fā)paint 的屬性
- color
- border - style
- border - radius
- visibility
- Text -decoration
- background
- background
- Background - image
- background - size
- Background - repeat
- background - position
- outline - color
- outline
- outline - style
- outline - width
- box - shadow
如何優(yōu)化
使用transform代替top, left 的變化
使用transform不會(huì)觸發(fā)layout , 只會(huì)觸發(fā)paint。
如果你想頁(yè)面中做一些比較炫酷的效果，相信我，transform可以滿足你的需求。
// 位置的變換 transform: translate(1px,2px)// 大小的變換 transform: scale(1.2)復(fù)制代碼使用opacity 來(lái)代替 visibility
因?yàn)?visibility屬性會(huì)觸發(fā)重繪，而opacity 則不會(huì)觸發(fā)重繪
避免使用耗性能的屬性
可以點(diǎn)擊這個(gè)鏈接進(jìn)行測(cè)試測(cè)試連接
.link {background-color: red;border-radius: 5px;padding: 3px;box-shadow: 0 5px 5px #000;-webkit-transform: rotate(10deg);-moz-transform: rotate(10deg);-ms-transform: rotate(10deg);transform: rotate(10deg);display: block; }復(fù)制代碼測(cè)試結(jié)果：
| Expensive Styles | 65.2 | 151.4 | 65.2 | 259.2 | 1923 |
需要注意的是，高耗css樣式如果不會(huì)頻繁的觸發(fā)回流和重繪，只會(huì)在頁(yè)面渲染的時(shí)候被執(zhí)行一次，那么對(duì)頁(yè)面的性能影響是有限的。如果頻繁的觸發(fā)回流和重繪，那么最基本的css樣式也會(huì)影響到頁(yè)面的性能。
那么哪些 css 樣式會(huì)造成頁(yè)面性能的問(wèn)題呢？
- Border-radius
- Shadow
- gradients
- transform rotating
更多的內(nèi)容請(qǐng)參考 連接
瀏覽器渲染第四步：composite
什么是合成層
上面幾個(gè)階段可以用下面一張圖來(lái)表示：
1. 從 Nodes 到 LayoutObjects
DOM 樹(shù)每個(gè) Node 節(jié)點(diǎn)都有一個(gè)對(duì)應(yīng)的 LayoutObject 。LayoutObject 知道如何在屏幕上 paint Node 的內(nèi)容。
2. 從 LayoutObjects 到 PaintLayers
有相同坐標(biāo)的 LayoutObjects ，在同一個(gè)PaintLayer內(nèi)。 根據(jù)創(chuàng)建PaintLayer 的原因不同，可以將其分為常見(jiàn)的 3 類：
- 根元素
- relative、fixed、sticky、absolute
- opacity 小于 1
- CSS 濾鏡（fliter）
- 有 CSS mask 屬性
- 有 CSS mix-blend-mode 屬性（不為 normal）
- 有 CSS transform 屬性（不為 none）
- backface-visibility 屬性為 hidden
- 有 CSS reflection 屬性
- 有 CSS column-count 屬性（不為 auto）或者 有 CSS column-width 屬性（不為 auto）
- 當(dāng)前有對(duì)于 opacity、transform、fliter、backdrop-filter 應(yīng)用動(dòng)畫(huà)
- overflow 不為 visible
- 不需要 paint 的 PaintLayer，比如一個(gè)沒(méi)有視覺(jué)屬性（背景、顏色、陰影等）的空 div。
4. 從 PaintLayers 到 GraphicsLayers
某些特殊的paintLayer會(huì)被當(dāng)成合成層,合成層擁有單獨(dú)的 GraphicsLayer，而其他不是合成層的paintLayer，則和其第一個(gè)擁有GraphicsLayer 父層公用一個(gè)。
每個(gè) GraphicsLayer 都有一個(gè)GraphicsContext，GraphicsContext 會(huì)負(fù)責(zé)輸出該層的位圖，位圖是存儲(chǔ)在共享內(nèi)存中，作為紋理上傳到 GPU 中，最后由 GPU 將多個(gè)位圖進(jìn)行合成，然后 draw 到屏幕上，此時(shí)，我們的頁(yè)面也就展現(xiàn)到了屏幕上。
渲染層提升為合成層的原因
渲染層提升為合成層的原因有一下幾種：
- 直接原因
- 硬件加速的 iframe 元素（比如 iframe 嵌入的頁(yè)面中有合成層
- video元素
- 3d transiform
- 在 DPI 較高的屏幕上，fix 定位的元素會(huì)自動(dòng)地被提升到合成層中。但在 DPI 較低的設(shè)備上卻并非如此
- backface-visibility 為 hidden
- 對(duì) opacity、transform、fliter、backdropfilter 應(yīng)用了 animation 或者 transition（需要注意的是 active 的 animation 或者 transition，當(dāng) animation 或者 transition 效果未開(kāi)始或結(jié)束后，提升合成層也會(huì)失效）
- will-change 設(shè)置為 opacity、transform、top、left、bottom、right（其中 top、left 等需要設(shè)置明確的定位屬性，如 relative 等）
- 后代元素原因
- 有合成層后代同時(shí)本身有 transform、opactiy（小于 1）、mask、fliter、reflection 屬性
- 有合成層后代同時(shí)本身 overflow 不為 visible（如果本身是因?yàn)槊鞔_的定位因素產(chǎn)生的 SelfPaintingLayer，則需要 z-index 不為 auto）
- 有合成層后代同時(shí)本身 fixed 定位
- 有 3D transfrom 的合成層后代同時(shí)本身有 preserves-3d 屬性
- 有 3D transfrom 的合成層后代同時(shí)本身有 perspective 屬性
- overlap 重疊原因
為啥overlap 重疊也會(huì)造成提升合成層渲染? 圖層之間有重疊關(guān)系，需要按照順序合并圖層。
如何優(yōu)化
如果把一個(gè)頻繁修改的dom元素，抽出一個(gè)單獨(dú)的圖層，然后這個(gè)元素的layout, paint 階段都會(huì)在這個(gè)圖層進(jìn)行，從而減少對(duì)其他元素的影響。
使用will-change 或者 transform3d
使用 will-change 或者 transform3d
1. will-change: transform/opacity2. transform3d(0,0,0,)復(fù)制代碼使用加速視頻解碼的節(jié)點(diǎn)
因?yàn)橐曨l中的每一幀都是在動(dòng)的，所以視頻的區(qū)域，瀏覽器每一幀都需要重繪。所以瀏覽器會(huì)自己優(yōu)化，把這個(gè)區(qū)域的給抽出一個(gè)單獨(dú)的圖層
擁有3D(webgl) 上下文或者加速的2D上下文的節(jié)點(diǎn)
混合插件（flash）
如果某一個(gè)元素，通過(guò)z-index在復(fù)合層上面渲染，則該元素也會(huì)被提升到復(fù)合層
需要注意的是，gif 圖片雖然也變化很頻繁，但是 img 標(biāo)簽不會(huì)被單獨(dú)的提到一個(gè)復(fù)合層，所以我們需要單獨(dú)的提到一個(gè)獨(dú)立獨(dú)立的圖層之類。
composite更詳盡的知識(shí)可以了解下面這個(gè)博客： 《GPU Accelerated Compositing in Chrome》
頁(yè)面性能優(yōu)化實(shí)踐
Bounce-btn優(yōu)化
bounce-btn是類似于下面這種的：
如果想實(shí)現(xiàn)這種效果，假設(shè)不考慮性能問(wèn)題，寫(xiě)出下面的代碼話：
<div class="content-box"></div><div class="content-box"></div><div class="content-box"></div><div class="bounce-btn"></div><div class="content-box"></div><div class="content-box"></div><div class="content-box"></div>復(fù)制代碼.bounce-btn {width: 200px;height: 50px;background-color: antiquewhite;border-radius: 30px;margin: 10px auto;transition: all 1s; } .content-box {width: 400px;height: 200px;background-color: darkcyan;margin: 10px auto; }復(fù)制代碼let btnArr = document.querySelectorAll('.bounce-btn'); setInterval(() => {btnArr.forEach((dom) => {if ( dom.style.width ==='200px') {dom.style.width = '300px';dom.style.height = '70px';} else {dom.style.width = '200px';dom.style.height = '50px';}}) },2000)復(fù)制代碼可以發(fā)現(xiàn)這樣的性能是非常差的，我們打開(kāi)dev-tool的paint flashing， 發(fā)現(xiàn)重新渲染的區(qū)域如綠色的區(qū)域所示：
而此時(shí)的性能是，1000ms 的時(shí)間內(nèi)，layout階段花費(fèi)了29.9ms占了18.6%
這個(gè)其實(shí)有兩個(gè)地方，第一是，bounce btn 這個(gè)元素被js 修改了width 、height 這些屬性，從而觸發(fā)了自身layout ——> repaint ——> composite。第二是，bounce btn 沒(méi)有脫離文檔流，它自身布局的變化，影響到了它下面的元素的布局，從而導(dǎo)致下面元素也觸發(fā)了layout ——> repaint ——> composite。
那么我們把修改width, 改為 tansform: scale()
let btnArr = document.querySelectorAll('.bounce-btn'); setInterval(() => {btnArr.forEach((dom) => {if ( dom.style.transform ==='scale(0.8)') {dom.style.transform = 'scale(2.5)';} else {dom.style.transform = 'scale(0.8)';}}) },2000)復(fù)制代碼頁(yè)面性能得到了提高：
重新渲染的區(qū)域只有它自身了。此時(shí)的性能是，1000ms 的時(shí)間內(nèi)，沒(méi)有存在layout階段，
如果繼續(xù)優(yōu)化，我們通過(guò)aimation動(dòng)畫(huà)來(lái)實(shí)現(xiàn)bounce的效果：
@keyframes bounce {0% {transform: scale(0.8);}25% {transform: scale(1.5);}50% {transform: scale(1.5);}75% {transform: scale(1.5);}100% {transform: scale(0.8);}}復(fù)制代碼頁(yè)面中沒(méi)有重新渲染的區(qū)域：
并且頁(yè)面性能幾乎沒(méi)有受到任何影響，不會(huì)重新經(jīng)歷 layout ——> repaint ——> composite.
所以，對(duì)于這種動(dòng)效，優(yōu)先選擇 CSS animation > transform 修改 scale > 絕對(duì)定位 修改width > 文檔流中修改width
跑馬燈的優(yōu)化
跑馬燈的動(dòng)效是：每隔3秒進(jìn)行向左側(cè)滑動(dòng)淡出，然后再滑動(dòng)重新淡入，更新文本為“**砍價(jià)9元”
之前的滑動(dòng)和淡出的效果是通過(guò)vue提供的 <transision> 來(lái)實(shí)現(xiàn)的
<transision> 原理
當(dāng)我們想要用到過(guò)渡效果，會(huì)在vue中寫(xiě)這樣的代碼：
<transition name="toggle"><div class="test"> </transition>復(fù)制代碼但是其實(shí)渲染到瀏覽器中的代碼，會(huì)依次是下面這樣的：
// 過(guò)渡進(jìn)入開(kāi)始的一瞬間 <div class="test toggle-enter">// 過(guò)渡進(jìn)入的中間階段 <div class="test toggle-enter-active">// 過(guò)渡進(jìn)入的結(jié)束階段 <div class="test toggle-enter-active toggle-enter-to">// 過(guò)渡淡出開(kāi)始的一瞬間 <div class="test toggle-leave">// 過(guò)渡淡出的中間階段 <div class="test toggle-leave-active">// 過(guò)渡淡出的結(jié)束階段 <div class="test toggle-leave-active toggle-leave-to">復(fù)制代碼也就是說(shuō)，過(guò)渡效果的實(shí)現(xiàn)，是通過(guò)不停的修改、增加、刪除該dom節(jié)點(diǎn)的class來(lái)實(shí)現(xiàn)。
<transision> 影響頁(yè)面性能
一方面， v-if 會(huì)修改dom節(jié)點(diǎn)的結(jié)構(gòu)，修改dom節(jié)點(diǎn)會(huì)造成瀏覽器重走一遍 layout 階段，也就是重排。另一方面，dom節(jié)點(diǎn)的class被不停的修改，也會(huì)導(dǎo)致瀏覽器的重排現(xiàn)象，因此頁(yè)面性能會(huì)比較大的受到影響。
若頁(yè)面中 <transition> 控制的節(jié)點(diǎn)過(guò)多時(shí)，頁(yè)面的性能就會(huì)比較受影響。
為了證明，下面代碼模擬了一種極端的情況：
<div v-for="n in testArr"><transition name="toggle"><div class="info-block" v-if="isShow"></div></transition> </div>復(fù)制代碼 export default {data () {return {isShow: false,testArr: 1000}},methods: {toggle() {var self = this;setInterval(function () {self.isShow = !self.isShow}, 1000)}},mounted () {this.toggle()}}復(fù)制代碼 .toggle-show-enter {transform: translate(-400px,0);}.toggle-show-enter-active {color: white;}.toggle-show-enter-to {transform: translate(0,0);}.toggle-show-leave {transform: translate(0,0);}.toggle-show-leave-to {transform: translate(-400px,0);}.toggle-show-leave-active {color: white;}復(fù)制代碼上面的代碼在頁(yè)面中渲染了 1000 個(gè)過(guò)渡的元素，這些元素會(huì)在1秒的時(shí)間內(nèi)從左側(cè)劃入，然后劃出。
此時(shí)，我們打開(kāi)google瀏覽器的開(kāi)發(fā)者工具，然后在 performance 一欄中記錄分析性能，如下圖所示：
可以發(fā)現(xiàn)，頁(yè)面明顯掉幀了。在7秒內(nèi)，總共 scripting 的階段為3秒， rendering 階段為1956毫秒。
事實(shí)上，這種跑馬燈式的重復(fù)式效果，通過(guò) animation 的方式也可以輕松實(shí)現(xiàn)。 我們優(yōu)化上面的代碼，改為下面的代碼，通過(guò) animation 動(dòng)畫(huà)來(lái)控制過(guò)渡：
<div v-for="n in testArr"><div class="info-block"></div></div> 復(fù)制代碼 export default {data () {return {isShow: false,testArr: 1000}}} 復(fù)制代碼.info-block {background-color: red;width: 300px;height: 100px;position: fixed;left: 10px;top: 200px;display: flex;align-items: center;justify-content: center;animation: toggleShow 3s ease 0s infinite normal; }@keyframes toggleShow {0% {transform: translate(-400px);}10% {transform: translate(0,0);}80% {transform: translate(0,0);}100% {transform: translate(-400px);} } 復(fù)制代碼打開(kāi)瀏覽器的開(kāi)發(fā)者工具，可以在 performance 里面看到，頁(yè)面性能有了驚人的提升：
為了進(jìn)一步提升頁(yè)面的性能，我們給過(guò)渡的元素增加一個(gè) will-change 屬性，該元素就會(huì)被提升到 合成層 用GPU單獨(dú)渲染，這樣頁(yè)面性能就會(huì)有更大的提升。
優(yōu)化懶加載（需考慮兼容性）
有一些頁(yè)面使用了懶加載，懶加載是通過(guò)綁定 scroll 事件一個(gè)回調(diào)事件，每一次調(diào)用一次回調(diào)事件，就會(huì)測(cè)量一次元素的位置，調(diào)用 getBoundingClientRect() 方法，從而計(jì)算出是否元素出現(xiàn)在了可視區(qū)。
// 懶加載庫(kù)中的代碼，判斷是否進(jìn)入了可視區(qū) const isInView = (el, threshold) => {const {top, height} = el.getBoundingClientRect()return top < clientHeight + threshold && top + height > -threshold }復(fù)制代碼scroll 造成頁(yè)面性能下降
scroll 事件會(huì)被重復(fù)的觸發(fā)，每觸發(fā)一次就要測(cè)量一次元素的尺寸和位置。盡管對(duì) scroll 的事件進(jìn)行了節(jié)流的處理，但在低端安卓機(jī)上仍然會(huì)出現(xiàn)滑動(dòng)不流暢的現(xiàn)象。
優(yōu)化的思路是通過(guò)新增的api—— IntersectionObserver 來(lái)獲取元素是否進(jìn)入了可視區(qū)。
使用intersection observer
intersection observer api 可以去測(cè)量某一個(gè)dom節(jié)點(diǎn)和其他節(jié)點(diǎn)，甚至是viewport的距離。
這個(gè)是實(shí)驗(yàn)性的api，你應(yīng)該查閱https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API#Browser_compatibility查看其兼容性
在過(guò)去，檢測(cè)一個(gè)元素是否在可視區(qū)內(nèi)，或者兩個(gè)元素之間的距離如何，是一個(gè)非常艱巨的任務(wù)。 但獲取這些信息是非常必要的：
在過(guò)去，我們需要不斷的調(diào)用 Element.getBoundingClientRect() 方法去獲取到我們想拿到的信息，然而這些代碼會(huì)造成性能問(wèn)題。
intersection observer api 可以注冊(cè)回調(diào)函數(shù)，當(dāng)我們的目標(biāo)元素，進(jìn)入指定區(qū)域（比如說(shuō)viewport，或者其他的元素）時(shí)，回調(diào)函數(shù)會(huì)被觸發(fā)；
intersectionObserver 的語(yǔ)法
var handleFun = function() {}var boxElement = document.getElementById()var options = {root: null,rootMargin: "0px",threshold: 0.01};observer = new IntersectionObserver(handleFunc, options);observer.observe(boxElement);復(fù)制代碼基于IntersectionObserver的懶加載的庫(kù)
于是自己嘗試封裝了一個(gè)基于IntersectionObserver的懶加載的庫(kù)。
html
<img class="J_lazy-load" data-imgsrc="burger.png"> 復(fù)制代碼你也許注意到上面的代碼中，圖片文件沒(méi)有 src 屬性么。這是因?yàn)樗褂昧朔Q為 data-imgsrc 的 data 屬性來(lái)指向圖片源。我們將使用這來(lái)加載圖片
js
function lazyLoad(domArr) {if ('IntersectionObserver' in window) {let createObserver = (dom) => {var fn = (arr) => {let target = arr[0].targetif (arr[0].isIntersecting) {let imgsrc = target.dataset.imgsrcif (imgsrc) {target.setAttribute('src', imgsrc)}// 解除綁定觀察observer.unobserve(dom)}}var config = {root: null,rootMargin: '10px',threshold: 0.01}var observer = new IntersectionObserver(fn, config)observer.observe(dom)}Array.prototype.slice(domArr)domArr.forEach(dom => {createObserver(dom)})} }復(fù)制代碼這個(gè)庫(kù)的使用也非常簡(jiǎn)單：
// 先引入 import {lazyLoad} from '../util/lazyload.js'// 進(jìn)行懶加載 let domArr = document.querySelectorAll('.J_lazy-load') lazyLoad(domArr)復(fù)制代碼然后測(cè)試一下，發(fā)現(xiàn)可以正常使用：
比較性能
傳統(tǒng)的懶加載 lazy-loder 的頁(yè)面性能如下：
在12秒內(nèi)，存在紅顏色的掉幀現(xiàn)象，一些地方的幀率偏低（在devtool里面是fps的綠色小山較高的地方），用于 scripting 階段的總共有600多ms.
使用intersetctionObserver之后的懶加載性能如下：
在12秒內(nèi)，幀率比較平穩(wěn)，用于 scripting 階段的時(shí)間只有60多ms了。參考鏈接：
總結(jié)
以上是生活随笔為你收集整理的深入理解浏览器解析和执行过程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 简单实现迷你Vue框架
- 下一篇： 感謝有PPStream這種好東西