摘要:也有的元素被完全無(wú)視,比如的元素。對(duì)于每個(gè)元素,必須在所有中找到符合的并將對(duì)應(yīng)的規(guī)則進(jìn)行合并。這樣做是為了減少無(wú)效匹配次數(shù),從而匹配快性能更優(yōu)。識(shí)別屬性值,創(chuàng)建對(duì)象,并將對(duì)象存入解釋器堆棧。數(shù)組中的每一項(xiàng)紀(jì)錄了這個(gè)的,的值,權(quán)重層疊規(guī)則。
作為前端,我們每天都在與CSS打交道,那么CSS的原理是什么呢?一、瀏覽器渲染
開篇,我們還是不厭其煩的回顧一下瀏覽器的渲染過(guò)程,先上圖:
正如上圖所展示的,我們?yōu)g覽器渲染過(guò)程分為了兩條主線:
其一,HTML Parser 生成的 DOM 樹;
其二,CSS Parser 生成的 Style Rules ;
在這之后,DOM 樹與 Style Rules 會(huì)生成一個(gè)新的對(duì)象,也就是我們常說(shuō)的 Render Tree 渲染樹,結(jié)合 Layout 繪制在屏幕上,從而展現(xiàn)出來(lái)。
本文的重點(diǎn)也就集中在第二條分支上,我們來(lái)探究一下 CSS 解析原理。二、Webkit CSS 解析器
瀏覽器 CSS 模塊負(fù)責(zé) CSS 腳本解析,并為每個(gè) Element 計(jì)算出樣式。CSS 模塊雖小,但是計(jì)算量大,設(shè)計(jì)不好往往成為瀏覽器性能的瓶頸。
CSS 模塊在實(shí)現(xiàn)上有幾個(gè)特點(diǎn):CSS 對(duì)象眾多(顆粒小而多),計(jì)算頻繁(為每個(gè) Element 計(jì)算樣式)。這些特性決定了 webkit 在實(shí)現(xiàn) CSS 引擎上采取的設(shè)計(jì),算法。如何高效的計(jì)算樣式是瀏覽器內(nèi)核的重點(diǎn)也是難點(diǎn)。
先來(lái)看一張圖:
Webkit 使用 Flex 和 Bison 解析生成器從 CSS 語(yǔ)法文件中自動(dòng)生成解析器。
它們都是將每個(gè) CSS 文件解析為樣式表對(duì)象,每個(gè)對(duì)象包含 CSS 規(guī)則,CSS 規(guī)則對(duì)象包含選擇器和聲明對(duì)象,以及其他一些符合 CSS 語(yǔ)法的對(duì)象,下圖可能會(huì)比較明了:
Webkit 使用了自動(dòng)代碼生成工具生成了相應(yīng)的代碼,也就是說(shuō)詞法分析和語(yǔ)法分析這部分代碼是自動(dòng)生成的,而 Webkit 中實(shí)現(xiàn)的 CallBack 函數(shù)就是在 CSSParser 中。
CSS 的一些解析功能的入口也在此處,它們會(huì)調(diào)用 lex , parse 等生成代碼。相對(duì)的,生成代碼中需要的 CallBack 也需要在這里實(shí)現(xiàn)。
舉例來(lái)說(shuō),現(xiàn)在我們來(lái)看其中一個(gè)回調(diào)函數(shù)的實(shí)現(xiàn),createStyleRule(),該函數(shù)將在一般性的規(guī)則需要被建立的時(shí)候調(diào)用,代碼如下:
CSSRule* CSSParser::createStyleRule(CSSSelector* selector) { CSSStyleRule* rule = 0; if (selector) { rule = new CSSStyleRule(styleElement); m_parsedStyleObjects.append(rule); rule->setSelector(sinkFloatingSelector(selector)); rule->setDeclaration(new CSSMutableStyleDeclaration(rule, parsedProperties, numParsedProperties)); } clearProperties(); return rule; }
從該函數(shù)的實(shí)現(xiàn)可以很清楚的看到,解析器達(dá)到某條件需要?jiǎng)?chuàng)建一個(gè) CSSStyleRule 的時(shí)候?qū)⒄{(diào)用該函數(shù),該函數(shù)的功能是創(chuàng)建一個(gè) CSSStyleRule ,并將其添加已解析的樣式對(duì)象列表 m_parsedStyleObjects 中去,這里的對(duì)象就是指的 Rule 。
那么如此一來(lái),經(jīng)過(guò)這樣一番解析后,作為輸入的樣式表中的所有 Style Rule 將被轉(zhuǎn)化為 Webkit 的內(nèi)部模型對(duì)象 CSSStyleRule 對(duì)象,存儲(chǔ)在 m_parsedStyleObjects 中,它是一個(gè) Vector。
但是我們解析所要的結(jié)果是什么?
1.通過(guò)調(diào)用 CSSStyleSheet 的 parseString 函數(shù),將上述 CSS 解析過(guò)程啟動(dòng),解析完一遍后,把 Rule 都存儲(chǔ)在對(duì)應(yīng)的 CSSStyleSheet 對(duì)象中;
2.由于目前規(guī)則依然是不易于處理的,還需要將之轉(zhuǎn)換成 CSSRuleSet。也就是將所有的純樣式規(guī)則存儲(chǔ)在對(duì)應(yīng)的集合當(dāng)中,這種集合的抽象就是 CSSRuleSet;
3.CSSRuleSet 提供了一個(gè) addRulesFromSheet 方法,能將 CSSStyleSheet 中的 rule 轉(zhuǎn)換為 CSSRuleSet 中的 rule ;
4.基于這些個(gè) CSSRuleSet 來(lái)決定每個(gè)頁(yè)面中的元素的樣式;
三、CSS 選擇器解析順序可能很多同學(xué)都知道排版引擎解析 CSS 選擇器時(shí)是從右往左解析,這是為什么呢?
1.HTML 經(jīng)過(guò)解析生成 DOM Tree(這個(gè)我們比較熟悉);而在 CSS 解析完畢后,需要將解析的結(jié)果與 DOM Tree 的內(nèi)容一起進(jìn)行分析建立一棵 Render Tree,最終用來(lái)進(jìn)行繪圖。Render Tree 中的元素(WebKit 中稱為「renderers」,F(xiàn)irefox 下為「frames」)與 DOM 元素相對(duì)應(yīng),但非一一對(duì)應(yīng):一個(gè) DOM 元素可能會(huì)對(duì)應(yīng)多個(gè) renderer,如文本折行后,不同的「行」會(huì)成為 render tree 種不同的 renderer。也有的 DOM 元素被 Render Tree 完全無(wú)視,比如 display:none 的元素。
2.在建立 Render Tree 時(shí)(WebKit 中的「Attachment」過(guò)程),瀏覽器就要為每個(gè) DOM Tree 中的元素根據(jù) CSS 的解析結(jié)果(Style Rules)來(lái)確定生成怎樣的 renderer。對(duì)于每個(gè) DOM 元素,必須在所有 Style Rules 中找到符合的 selector 并將對(duì)應(yīng)的規(guī)則進(jìn)行合并。選擇器的「解析」實(shí)際是在這里執(zhí)行的,在遍歷 DOM Tree 時(shí),從 Style Rules 中去尋找對(duì)應(yīng)的 selector。
3.因?yàn)樗袠邮揭?guī)則可能數(shù)量很大,而且絕大多數(shù)不會(huì)匹配到當(dāng)前的 DOM 元素(因?yàn)閿?shù)量很大所以一般會(huì)建立規(guī)則索引樹),所以有一個(gè)快速的方法來(lái)判斷「這個(gè) selector 不匹配當(dāng)前元素」就是極其重要的。
4.如果正向解析,例如「div div p em」,我們首先就要檢查當(dāng)前元素到 html 的整條路徑,找到最上層的 div,再往下找,如果遇到不匹配就必須回到最上層那個(gè) div,往下再去匹配選擇器中的第一個(gè) div,回溯若干次才能確定匹配與否,效率很低。
對(duì)于上述描述,我們先有個(gè)大概的認(rèn)知。接下來(lái)我們來(lái)看這樣一個(gè)例子,參考地址:
span> 111 span>
span> 222 span>
333
444
CSS 選擇器:
div > div.jartto p span.yellow{ color:yellow; }對(duì)于上述例子,如果按從左到右的方式進(jìn)行查找:
1.先找到所有 div 節(jié)點(diǎn);
2.在 div 節(jié)點(diǎn)內(nèi)找到所有的子 div ,并且是 class = “jartto”;
3.然后再依次匹配 p span.yellow 等情況;
4.遇到不匹配的情況,就必須回溯到一開始搜索的 div 或者 p 節(jié)點(diǎn),然后去搜索下個(gè)節(jié)點(diǎn),重復(fù)這樣的過(guò)程。這樣的搜索過(guò)程對(duì)于一個(gè)只是匹配很少節(jié)點(diǎn)的選擇器來(lái)說(shuō),效率是極低的,因?yàn)槲覀兓ㄙM(fèi)了大量的時(shí)間在回溯匹配不符合規(guī)則的節(jié)點(diǎn)。如果換個(gè)思路,我們一開始過(guò)濾出跟目標(biāo)節(jié)點(diǎn)最符合的集合出來(lái),再在這個(gè)集合進(jìn)行搜索,大大降低了搜索空間。來(lái)看看從右到左來(lái)解析選擇器:
1.首先就查找到 的元素;
2.緊接著我們判斷這些節(jié)點(diǎn)中的前兄弟節(jié)點(diǎn)是否符合 P 這個(gè)規(guī)則,這樣就又減少了集合的元素,只有符合當(dāng)前的子規(guī)則才會(huì)匹配再上一條子規(guī)則。結(jié)果顯而易見了,眾所周知,在 DOM 樹中一個(gè)元素可能有若干子元素,如果每一個(gè)都去判斷一下顯然性能太差。而一個(gè)子元素只有一個(gè)父元素,所以找起來(lái)非常方便。試想一下,如果采用從左至右的方式讀取 CSS 規(guī)則,那么大多數(shù)規(guī)則讀到最后(最右)才會(huì)發(fā)現(xiàn)是不匹配的,這樣會(huì)做費(fèi)時(shí)耗能,最后有很多都是無(wú)用的;而如果采取從右向左的方式,那么只要發(fā)現(xiàn)最右邊選擇器不匹配,就可以直接舍棄了,避免了許多無(wú)效匹配。
瀏覽器 CSS 匹配核心算法的規(guī)則是以從右向左方式匹配節(jié)點(diǎn)的。這樣做是為了減少無(wú)效匹配次數(shù),從而匹配快、性能更優(yōu)。四、CSS 語(yǔ)法解析過(guò)程CSS 樣式表解析過(guò)程中講解的很細(xì)致,這里我們只看 CSS 語(yǔ)法解釋器,大致過(guò)程如下:
五、內(nèi)聯(lián)樣式如何解析?
1.先創(chuàng)建 CSSStyleSheet 對(duì)象。將 CSSStyleSheet 對(duì)象的指針存儲(chǔ)到 CSSParser 對(duì)象中。
2.CSSParser 識(shí)別出一個(gè) simple-selector ,形如 “div” 或者 “.class”。創(chuàng)建一個(gè) CSSParserSelector 對(duì)象。
3.CSSParser 識(shí)別出一個(gè)關(guān)系符和另一個(gè) simple-selecotr ,那么修改之前創(chuàng)建的 simple-selecotr, 創(chuàng)建組合關(guān)系符。
4.循環(huán)第3步直至碰到逗號(hào)或者左大括號(hào)。
5.如果碰到逗號(hào),那么取出 CSSParser 的 reuse vector,然后將堆棧尾部的 CSSParserSelector 對(duì)象彈出存入 Vecotr 中,最后跳轉(zhuǎn)至第2步。如果碰到左大括號(hào),那么跳轉(zhuǎn)至第6步。
6.識(shí)別屬性名稱,將屬性名稱的 hash 值壓入解釋器堆棧。
7.識(shí)別屬性值,創(chuàng)建 CSSParserValue 對(duì)象,并將 CSSParserValue 對(duì)象存入解釋器堆棧。
8.將屬性名稱和屬性值彈出棧,創(chuàng)建 CSSProperty 對(duì)象。并將 CSSProperty 對(duì)象存入 CSSParser 成員變量m_parsedProperties 中。
9.如果識(shí)別處屬性名稱,那么轉(zhuǎn)至第6步。如果識(shí)別右大括號(hào),那么轉(zhuǎn)至第10步。
10.將 reuse vector 從堆棧中彈出,并創(chuàng)建 CSSStyleRule 對(duì)象。CSSStyleRule 對(duì)象的選擇符就是 reuse vector, 樣式值就是 CSSParser 的成員變量 m_parsedProperties 。
11.把 CSSStyleRule 添加到 CSSStyleSheet 中。
12.清空 CSSParser 內(nèi)部緩存結(jié)果。
13.如果沒(méi)有內(nèi)容了,那么結(jié)束。否則跳轉(zhuǎn)值第2步。通過(guò)上文的了解,我們知道,當(dāng) CSS Parser 解析完 CSS 腳本后,會(huì)生成 CSSStyleSheetList ,他保存在Document 對(duì)象上。為了更快的計(jì)算樣式,必須對(duì)這些 CSSStyleSheetList 進(jìn)行重新組織。
計(jì)算樣式就是從 CSSStyleSheetList 中找出所有匹配相應(yīng)元素的 property-value 對(duì)。匹配會(huì)通過(guò)CSSSelector 來(lái)驗(yàn)證,同時(shí)需要滿足層疊規(guī)則。
將所有的 declaration 中的 property 組織成一個(gè)大的數(shù)組。數(shù)組中的每一項(xiàng)紀(jì)錄了這個(gè) property 的selector,property 的值,權(quán)重(層疊規(guī)則)。
可能類似如下的表現(xiàn):
p > a { color : red; background-color:black; } a { color : yellow } div { margin : 1px; }重新組織之后的數(shù)組數(shù)據(jù)為(weight我只是表示了他們之間的相對(duì)大小,并非實(shí)際值。)
selector selector weight a color:yellow 1 p > a color:red 2 p > a background-color:black 2 div margin:1px 3 好了,到這里,我們來(lái)解決上述問(wèn)題:
首先,要明確,內(nèi)斂樣式只是 CSS 三種加載方式之一;
其次,瀏覽器解析分為兩個(gè)分支,HTML Parser 和 CSS Parser,兩個(gè) Parser 各司其職,各盡其責(zé);
最后,不同的 CSS 加載方式產(chǎn)生的 Style rule ,通過(guò)權(quán)重來(lái)確定誰(shuí)覆蓋誰(shuí);到這里就不難理解了,對(duì)瀏覽器來(lái)說(shuō),內(nèi)聯(lián)樣式與其他的加載樣式方式唯一的區(qū)別就是權(quán)重不同。深入了解,請(qǐng)閱讀Webkit CSS引擎分析
六、何謂 computedStyle ?到這里,你以為完了?Too young too simple, sometimes naive!
瀏覽器還有一個(gè)非常棒的策略,在特定情況下,瀏覽器會(huì)共享 computedStyle,網(wǎng)頁(yè)中能共享的標(biāo)簽非常多,所以能極大的提升執(zhí)行效率!如果能共享,那就不需要執(zhí)行匹配算法了,執(zhí)行效率自然非常高。
也就是說(shuō):如果兩個(gè)或多個(gè) element 的 computedStyle 不通過(guò)計(jì)算可以確認(rèn)他們相等,那么這些 computedStyle 相等的 elements 只會(huì)計(jì)算一次樣式,其余的僅僅共享該 computedStyle 。
那么有哪些規(guī)則會(huì)共享 computedStyle 呢?
該共享的element不能有id屬性且CSS中還有該id的StyleRule.哪怕該StyleRule與Element不匹配。
tagName和class屬性必須一樣;
mappedAttribute必須相等;
不能使用sibling selector,譬如:first-child, :last-selector, + selector;
不能有style屬性。哪怕style屬性相等,他們也不共享;
span>p style="color:red">paragraph1span>p> span>p style="color:red">paragraph2span>p>當(dāng)然,知道了共享 computedStyle 的規(guī)則,那么反面我們也就了解了:不會(huì)共享 computedStyle 的規(guī)則,這里就不展開討論了。
深入了解,請(qǐng)參考:Webkit CSS 引擎分析 - 高效執(zhí)行的 CSS 腳本
七、眼見為實(shí)
如上圖,我們可以看到不同的 CSS 選擇器的組合,解析速度也會(huì)受到不同的影響,你還會(huì)輕視 CSS 解析原理嗎?感興趣的同學(xué)可以參考這里:speed/validity selectors test for frameworks
八、有何收獲?1.使用 id selector 非常的高效。在使用 id selector 的時(shí)候需要注意一點(diǎn):因?yàn)?id 是唯一的,所以不需要既指定 id 又指定 tagName:
Bad p#id1 {color:red;} Good #id1 {color:red;}當(dāng)然,你非要這么寫也沒(méi)有什么問(wèn)題,但這會(huì)增加 CSS 編譯與解析時(shí)間,實(shí)在是不值當(dāng)。2.避免深層次的 node ,譬如:
Bad div > div > div > p {color:red;} Good p-class{color:red;}3.慎用 ChildSelector ;
4.不到萬(wàn)不得已,不要使用 attribute selector,如:p[att1=”val1”]。這樣的匹配非常慢。更不要這樣寫:p[id=”id1”]。這樣將 id selector 退化成 attribute selector。
Bad p[id="id1"]{color:red;} p[class="class1"]{color:red;} Good #id1{color:red;} .class1{color:red;}5.理解依賴?yán)^承,如果某些屬性可以繼承,那么自然沒(méi)有必要在寫一遍;
九、總結(jié)
6.規(guī)范真的很重要,不僅僅是可讀性,也許會(huì)影響你的頁(yè)面性能。這里推薦一個(gè) CSS 規(guī)范,可以參考一下。“學(xué)會(huì)使用”永遠(yuǎn)都是最基本的標(biāo)準(zhǔn),但是懂得原理,你才能觸類旁通,超越自我。文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/101344.html
相關(guān)文章
天天都在使用CSS,那么CSS的原理是什么呢?
摘要:也有的元素被完全無(wú)視,比如的元素。對(duì)于每個(gè)元素,必須在所有中找到符合的并將對(duì)應(yīng)的規(guī)則進(jìn)行合并。這樣做是為了減少無(wú)效匹配次數(shù),從而匹配快性能更優(yōu)。識(shí)別屬性值,創(chuàng)建對(duì)象,并將對(duì)象存入解釋器堆棧。數(shù)組中的每一項(xiàng)紀(jì)錄了這個(gè)的,的值,權(quán)重層疊規(guī)則。 作為前端,我們每天都在與CSS打交道,那么CSS的原理是什么呢? 一、瀏覽器渲染 開篇,我們還是不厭其煩的回顧一下瀏覽器的渲染過(guò)程,先上圖:show...
前端知識(shí)點(diǎn)整理
摘要:難怪超過(guò)三分之一的開發(fā)人員工作需要一些知識(shí)。但是隨著行業(yè)的飽和,初中級(jí)前端就業(yè)形勢(shì)不容樂(lè)觀。整個(gè)系列的文章大概有篇左右,從我是如何成為一個(gè)前端工程師,到各種前端框架的知識(shí)。 為什么 call 比 apply 快? 這是一個(gè)非常有意思的問(wèn)題。 作者會(huì)在參數(shù)為3個(gè)(包含3)以內(nèi)時(shí),優(yōu)先使用 call 方法進(jìn)行事件的處理。而當(dāng)參數(shù)過(guò)多(多余3個(gè))時(shí),才考慮使用 apply 方法。 這個(gè)的原因...
前端知識(shí)點(diǎn)整理
摘要:難怪超過(guò)三分之一的開發(fā)人員工作需要一些知識(shí)。但是隨著行業(yè)的飽和,初中級(jí)前端就業(yè)形勢(shì)不容樂(lè)觀。整個(gè)系列的文章大概有篇左右,從我是如何成為一個(gè)前端工程師,到各種前端框架的知識(shí)。 為什么 call 比 apply 快? 這是一個(gè)非常有意思的問(wèn)題。 作者會(huì)在參數(shù)為3個(gè)(包含3)以內(nèi)時(shí),優(yōu)先使用 call 方法進(jìn)行事件的處理。而當(dāng)參數(shù)過(guò)多(多余3個(gè))時(shí),才考慮使用 apply 方法。 這個(gè)的原因...
如何學(xué)JavaScript
摘要:書籍如下面向?qū)ο缶幊讨改希L(fēng)格輕松易懂,比較適合初學(xué)者,原型那塊兒講得透徹,種繼承方式呢。還有另一件事情是,比如發(fā)現(xiàn)自己某個(gè)知識(shí)點(diǎn)不太清楚,可以單獨(dú)去百度。 作者:小不了鏈接:https://zhuanlan.zhihu.com/p/...來(lái)源:知乎著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。 鑒于時(shí)不時(shí),有同學(xué)私信問(wèn)我(老姚,下同)怎么學(xué)前端的問(wèn)題。這里統(tǒng)一回...
margin合并、塌陷,清除浮動(dòng)
摘要:合并的外邊距的高度等于兩個(gè)發(fā)生合并的外邊距的高度中的較大者。那我們?cè)趺崔k,回到主題清除浮動(dòng)。你可能忘了偽元素是行內(nèi)元素,只有塊元素才能清除浮動(dòng)。所以我們最好后,主動(dòng)清除一下浮動(dòng),避免以后遇到很奇怪的問(wèn)題。 這是我的第一篇掘金文章,希望大家不要嫌棄。我還是一名在校大學(xué)生,就是想把自己所學(xué)到的知識(shí)寫出來(lái),加深自己的印象,記錄自己成長(zhǎng)的過(guò)程,這篇文章主要是介紹HTML 、 CSS 的一些小知...
發(fā)表評(píng)論
0條評(píng)論
The question
男|高級(jí)講師
TA的文章
閱讀更多
【接口測(cè)試—postman】5分鐘讓你學(xué)會(huì)接口測(cè)試工具——postman的基礎(chǔ)常用技巧,看完少走一周
閱讀 1768·2021-10-11 10:57
LibreOffice – 免費(fèi)跨平臺(tái)辦公套件可替代Microsoft Office套件
閱讀 2352·2021-10-08 10:14
前端每日實(shí)戰(zhàn):163# 視頻演示如何用原生 JS 創(chuàng)作一個(gè)多選一場(chǎng)景的交互游戲(內(nèi)含 3 個(gè)視頻)
閱讀 3393·2019-08-29 17:26
[總結(jié)]CSS/CSS3常用樣式與web移動(dòng)端資源
閱讀 3340·2019-08-28 17:54
Service Worker 淺析
閱讀 3021·2019-08-26 13:38
瀏覽器內(nèi)核之WebKit 架構(gòu)與模塊
閱讀 2885·2019-08-26 12:19
webpack4大結(jié)局:加入騰訊IM配置策略,實(shí)現(xiàn)前端工程化環(huán)境極致優(yōu)化
閱讀 3608·2019-08-23 18:05
用內(nèi)存空間圖理解javascript變量存儲(chǔ)機(jī)制,深度理解閉包
閱讀 1277·2019-08-23 17:04