摘要：既然出現(xiàn)了，那怎么辦，目前并沒(méi)聽(tīng)說(shuō)出現(xiàn)什么新的技術(shù)替代它雖然它真的已經(jīng)很不適合現(xiàn)代的前端了，那么只能開(kāi)發(fā)一個(gè)新的引擎提高性能，這就是火狐家的量子引擎又叫。這就是所謂的，火狐前一個(gè)引擎所做的那樣。

本文翻譯自Inside a super fast CSS engine: Quantum CSS ，如果想要閱讀原文，可以點(diǎn)擊前往，以下內(nèi)容夾雜本人一些思考，翻譯也并不一定完全。

為什么翻譯這篇文章尼，一開(kāi)始只是好奇，基本在前端技術(shù)圈子混過(guò)都知道火狐正在用Rust語(yǔ)言開(kāi)發(fā)新的瀏覽器引擎，作為前端開(kāi)發(fā)對(duì)火狐的感情還是大大的有（雖然現(xiàn)在已經(jīng)離不開(kāi)chrome了），但是還是希望火狐能夠再次引領(lǐng)Web的變革。
可以說(shuō)前端這幾年解決了前端工程化的很多痛點(diǎn)，但是性能這個(gè)坎依舊，期望webassembly盡快普及，但是對(duì)于前端必定又是一場(chǎng)腥風(fēng)血雨，前端不會(huì)一直是現(xiàn)在這樣的前端。既然webassembly出現(xiàn)了，那css怎么辦，目前并沒(méi)聽(tīng)說(shuō)出現(xiàn)什么新的技術(shù)替代它（雖然它真的已經(jīng)很不適合現(xiàn)代的前端了），那么只能開(kāi)發(fā)一個(gè)新的引擎提高性能，這就是火狐家的量子引擎：Quantum CSS（又叫Stylo）。

這是火狐正在開(kāi)發(fā)的Quantum項(xiàng)目，目的當(dāng)然是為了讓瀏覽器更快，從上圖可以看得到各個(gè)模塊，而Quantum CSS處于中間位置，這跟它在整個(gè)渲染過(guò)程中的位置一樣，利用Rust可以相當(dāng)有效利用現(xiàn)代處理器多核心的特性，能夠幾倍的提速。既然這么厲害，那從哪里可以體驗(yàn)?zāi)幔涸诨鸷麼ightly版進(jìn)入about:config設(shè)置layout.css.servo.enabled 屬性為 true就可以體驗(yàn)這吊炸天的引擎。

站在巨人的肩膀上，當(dāng)然除了利用現(xiàn)代處理器的并行能力，還借鑒當(dāng)前各家瀏覽器積累的一些優(yōu)化技術(shù)，接下來(lái)會(huì)一一解析這些優(yōu)化技術(shù)，如何讓引擎更快。

CSS引擎是瀏覽器渲染引擎的一部分，而渲染引擎會(huì)把我們的HTML和CSS轉(zhuǎn)換成屏幕上的像素（也就是畫(huà)面吧）。
各家瀏覽器都會(huì)有自家的渲染引擎，例如谷歌的Blink，Edge的EdgeHTML，Safari的Webkit和火狐的Gecko，雖然有這么多引擎，但是他們都做著同樣的事情：把HTML和CSS渲染成我們可以感知的界面。
而他們內(nèi)部的工作需要：

首先解析HTML文檔，生成DOM節(jié)點(diǎn)樹(shù)，讓瀏覽器可以知道頁(yè)面的結(jié)構(gòu)和各個(gè)節(jié)點(diǎn)的關(guān)系。

然后就要弄清楚每個(gè)元素長(zhǎng)什么樣子了，圓的還是方的，有邊框還是沒(méi)邊框等等；所以這個(gè)時(shí)候就需要知道每個(gè)元素需要應(yīng)該用什么樣式。

除了知道長(zhǎng)的樣子，還要知道各個(gè)節(jié)點(diǎn)的位置和布局。引擎會(huì)為所有可見(jiàn)的節(jié)點(diǎn)都會(huì)創(chuàng)建一個(gè)box，但是box并不僅為DOM節(jié)點(diǎn)而創(chuàng)建，DOM節(jié)點(diǎn)內(nèi)部也可以有其他box，例如幾行文字。

知道該應(yīng)用的樣式和位置，現(xiàn)在輪到繪制這些box了，這個(gè)工作可能會(huì)在多個(gè)layer上發(fā)生。可以認(rèn)為就像舊時(shí)動(dòng)畫(huà)制作技術(shù)，在一張透明的膠片上繪制背景，在另外的膠片上繪制人物或者其他元素。這樣的話就如果人物會(huì)動(dòng)起來(lái)的時(shí)候，就只用重新繪制人物那張膠片了，不用繪制其他的，這樣就省事好多了。

到了這一步現(xiàn)在我們有不同的膠片（layer），是時(shí)候開(kāi)始合成了（composite），但是合成之前，我們可能還會(huì)應(yīng)用一些transform，旋轉(zhuǎn)啊，偏移啊等等。最后把他們按照層級(jí)堆在一起，背景在后，人物在前等等，然后最終渲染到屏幕上。

綜合后，我們可以知道CSS引擎開(kāi)始計(jì)算樣式時(shí)需要兩樣?xùn)|西：DOM的節(jié)點(diǎn)樹(shù)和一系列的樣式規(guī)則。
CSS引擎會(huì)遍歷所有DOM節(jié)點(diǎn)并計(jì)算每個(gè)節(jié)點(diǎn)所應(yīng)用的樣式，它會(huì)讓DOM節(jié)點(diǎn)每個(gè)CSS屬性都有一個(gè)值，就算你在樣式表中并沒(méi)有聲明，它可能來(lái)自繼承或者默認(rèn)值，或者客戶端的樣式表（User Agent Style）。
可以認(rèn)為引擎就像填表格一樣，把這些最后計(jì)算出來(lái)的值一個(gè)一個(gè)填進(jìn)去。

為了得到上面的表格，CSS引擎需要做兩件事：

搞清楚每個(gè)節(jié)點(diǎn)所應(yīng)用的樣式規(guī)則（selector matching）

把一些你沒(méi)有聲明的值，根據(jù)繼承或者默認(rèn)值補(bǔ)充上去（the cascade）

首先找出配置當(dāng)前的節(jié)點(diǎn)的樣式規(guī)則，放到一個(gè)list上去，這里也包括客戶端的樣式表。

然后會(huì)計(jì)算各個(gè)樣式規(guī)則之間的權(quán)重，并且根據(jù)權(quán)重排序。

根據(jù)權(quán)重大小，得出最終應(yīng)用的樣式屬性的值。

級(jí)聯(lián)（The cascade）目的是為了讓CSS更容易編寫(xiě)和維護(hù)，由于級(jí)聯(lián)的存在，你可以在body上設(shè)置color屬性，而li,p,span等元素可以直接使用同樣的color，不需要每個(gè)元素都要去定義一次。
為了實(shí)現(xiàn)這個(gè)功能，CSS引擎會(huì)從表格里面尋找一些屬性值仍然為空的值，如果屬性默認(rèn)是繼承的話，CSS引擎會(huì)從父節(jié)點(diǎn)那里繼承屬性值，如果所有父節(jié)點(diǎn)都沒(méi)有定義該屬性值的話，就會(huì)使用默認(rèn)的值。
現(xiàn)在我們的表格都填滿了

上述表格的形式，只是一種表現(xiàn)方式，引擎真實(shí)的內(nèi)部不是這樣的。CSS擁有成千上百的屬性，如果引擎為每個(gè)節(jié)點(diǎn)都生成這樣一張表，會(huì)很快耗掉所有內(nèi)存。
相反引擎內(nèi)部通常會(huì)使用style struct sharing，樣式的數(shù)據(jù)會(huì)集中在不同對(duì)象里面（style struct），然后使用指針指向這些對(duì)象。

這會(huì)很大程度上節(jié)省內(nèi)存，因?yàn)楦鱾€(gè)節(jié)點(diǎn)間都很有可能擁有相似的屬性值（例如兄弟節(jié)點(diǎn)間），另外因?yàn)楹芏鄬傩砸彩峭ㄟ^(guò)繼承獲取的，所以父節(jié)點(diǎn)可以跟子節(jié)點(diǎn)間共享這些屬性值。

如果我們不去優(yōu)化這些工作，整個(gè)樣式計(jì)算工作就會(huì)是這樣：

這是巨量的工作，而且并不僅僅在頁(yè)面加載的時(shí)候發(fā)生，它會(huì)隨著用戶的交互時(shí)刻都在存在（例如hover一個(gè)元素，CSS引擎需要從新計(jì)算樣式）。

這樣就意味著必須得去優(yōu)化樣式的計(jì)算工作，在過(guò)去20年，已經(jīng)測(cè)試過(guò)不同的優(yōu)化策略，而Quantum CSS則是組合利用這些最優(yōu)的優(yōu)化策略。

我們現(xiàn)在的CPU大多擁有多個(gè)核心，而Quantum CSS則會(huì)把不同DOM節(jié)點(diǎn)的樣式計(jì)算工作分配到不同的核心上去，但是實(shí)現(xiàn)也有相當(dāng)?shù)碾y度，其中一個(gè)原因就是DOM節(jié)點(diǎn)樹(shù)并不一定均勻的，這會(huì)導(dǎo)致其中一部分核心工作負(fù)荷比其他核心大。

為了讓各個(gè)核心工作負(fù)荷更加合理，Quantum CSS使用了一種技術(shù)稱(chēng)作 work stealing，當(dāng)一個(gè)DOM節(jié)點(diǎn)被處理的時(shí)候，引擎可以把它的子節(jié)點(diǎn)計(jì)算工作分成幾個(gè)“work units”并且放進(jìn)隊(duì)列中。
當(dāng)其中一個(gè)核心清空自身隊(duì)列的工作后，它能夠?qū)ふ移渌?duì)列上的其他work units然后執(zhí)行，這意味著我們不需要提前就去分配好工作，在運(yùn)行時(shí)也會(huì)達(dá)到最高的工作效率。

在大部分瀏覽器里面，很難讓這種機(jī)制毫無(wú)錯(cuò)誤的運(yùn)行，而且CSS引擎本身就非常復(fù)雜，它在渲染引擎中兩個(gè)最復(fù)雜的模塊（DOM和layout）中間。這個(gè)過(guò)程非常容易產(chǎn)生bug，而且并行程序?qū)е碌腷ug非常難debug，可以通過(guò)這篇文章了解更多。

對(duì)于每個(gè)DOM節(jié)點(diǎn)，CSS引擎需要遍歷所有樣式規(guī)則去進(jìn)行selector matching，且對(duì)于大部分節(jié)點(diǎn)這種matching并不會(huì)經(jīng)常改變。例如，用戶hover一個(gè)父節(jié)點(diǎn)，它的樣式規(guī)則可能會(huì)改變，但是我們?nèi)匀恍枰匦伦庸?jié)點(diǎn)的樣式規(guī)則去處理屬繼承的屬性值，而子節(jié)點(diǎn)之前匹配的規(guī)則很有可能不會(huì)改變。
如果我們記錄好子節(jié)點(diǎn)匹配哪些樣式規(guī)則，而不用每次都進(jìn)行一次selector matching，這可能會(huì)得到很大的優(yōu)化。這就是所謂的rule tree，火狐前一個(gè)引擎所做的那樣。
CSS引擎會(huì)遍歷樣式規(guī)則幫DOM節(jié)點(diǎn)找出匹配的選擇器，然后根據(jù)權(quán)重排序，從而創(chuàng)建出一個(gè)樣式規(guī)則的鏈表，然后將這個(gè)鏈表添加到rule tree中。

CSS引擎會(huì)盡可能利用已有的分支，為rule tree保持最少的分支數(shù)。
如果大部分鏈表中大部分的選擇器，跟已存在的分支一樣，引擎會(huì)順著路徑，除非它到達(dá)一個(gè)節(jié)點(diǎn)，rule tree并不存在一樣分支，引擎就會(huì)添加一個(gè)新的分支。

在重新計(jì)算樣式的過(guò)程中，引擎會(huì)快速檢查父節(jié)點(diǎn)的改變是否會(huì)導(dǎo)致子節(jié)點(diǎn)匹配的樣式規(guī)則改變。如果沒(méi)有，子節(jié)點(diǎn)可以根據(jù)自己指向rule tree節(jié)點(diǎn)的指針計(jì)算樣式。引擎會(huì)rule tree的節(jié)點(diǎn)往上查找，獲取整個(gè)匹配的規(guī)則，從權(quán)重最大到權(quán)重最小的。這樣就可以很輕松的跳過(guò)selector matching這一步了。

但是這樣仍然還有很多工作要做，畢竟一個(gè)頁(yè)面上節(jié)點(diǎn)成千上萬(wàn)，這時(shí)候并行計(jì)算的魔法又可以大顯神威了。

由于整個(gè)頁(yè)面的節(jié)點(diǎn)可能會(huì)有成千上萬(wàn)個(gè)，它們當(dāng)中很多都匹配著相同的規(guī)則。例如wiki頁(yè)面中每個(gè)p元素其實(shí)逗匹配著相同的樣式規(guī)則，擁有一樣的computed styles。
如果這里沒(méi)有做優(yōu)化，可能每個(gè)段落都要重新計(jì)算，但是如果有一種方法來(lái)證明每個(gè)段落的樣式規(guī)則都是一樣，引擎就只需計(jì)算一次就可以了。
這就是所謂的style sharing cache，由Chrome和Safari所發(fā)明的一種優(yōu)化方式，在引擎處理一個(gè)節(jié)點(diǎn)后會(huì)把computed style放到cache里面，然后開(kāi)始計(jì)算下一個(gè)節(jié)點(diǎn)的時(shí)候，引擎會(huì)先檢查cache里面是否已經(jīng)存在計(jì)算后的值。
而這些檢查包括：

兩個(gè)節(jié)點(diǎn)是否都有一樣的ID和Class等，如果一樣它們匹配同樣的規(guī)則。

對(duì)于非selector的行內(nèi)樣式，它們是否擁有一樣的值。

它們的父節(jié)點(diǎn)都是否指向同一個(gè)computed style object，如果一樣它們的繼承的值都會(huì)一樣。

但是也有很多其他的情況，導(dǎo)致這些檢查失效，例如：如果一個(gè)CSS規(guī)則使用了:first-child選擇器，就算兩個(gè)節(jié)點(diǎn)都已經(jīng)符合上述的規(guī)則，結(jié)果也會(huì)是檢查不通過(guò)。
在Webkit和Blink, style sharing cache在這些情況下會(huì)放棄檢查并不會(huì)使用cache。由于大部分網(wǎng)站都使用了這些modern selectors（CSS3），這個(gè)優(yōu)化的作用變得越來(lái)越少，所以Blink團(tuán)隊(duì)最近把它移除了。
在Quantum CSS，我們收集了所有這些怪異的選擇器（CSS3）然后讓它們加入檢查。我們會(huì)把結(jié)果存儲(chǔ)為0和1，如果兩個(gè)元素?fù)碛型瑯拥?和1，那我們就知道他們是匹配同樣的樣式規(guī)則。

這樣我們就可以繼續(xù)享受style sharing cache帶來(lái)的優(yōu)化。

前半部分可以讓我們知道CSS引擎的工作內(nèi)容，后半部分讓我們了解新引擎是如何優(yōu)化性能的，真的學(xué)習(xí)了很多，我想你也一樣。