JavaScript事情道理（十）：襯着引擎和優化機能的技能

到目前為止，在我們之前的“Javascript事變道理”系列文章中，我們一向關注Javascript作為一種言語，其功用，它如安在瀏覽器中實行，怎樣優化等等。

然則，當您構建Web運用程序時，您不只是編寫自力運轉的自力Javascript代碼。您編寫的Javascript與環境舉行交互。相識這類環境，它是怎樣事變的以及它的構成是什麼，將使您能夠構建更好的運用程序，並對運用程序宣布后能夠湧現的潛伏題目做好充分準備。

那末，讓我們看看瀏覽器的主要組件是什麼：

• 用戶界面：這包括地址欄，退卻和行進按鈕，書籤菜單等。實質上，這是瀏覽器顯現的每一個部份，除了您看到網頁自身的窗口。
• 瀏覽器引擎：它處置懲罰用戶界面和襯着引擎之間的交互
• 襯着引擎：它擔任顯現網頁。襯着引擎剖析HTML和CSS，並在屏幕上顯現剖析的內容。
• 收集：這些是收集挪用，比方XHR請求，經由歷程對差別平台運用差別的完成來完成，這些平台位於自力於平台的接口以後。在本系列的前一篇文章中，我們更細緻地議論了收集層。
• UI後端：用於繪製中心小部件，如複選框和窗口。這個後端公開了一個不是平台特定的通用接口。它運用下面的操作系統UI要領。
• Javascript引擎：我們在該系列的前一篇文章中細緻引見了這一點。基本上，這是Javascript實行的處所。
• 數據持久性：您的運用能夠須要在當地存儲一切數據。支撐的存儲機制範例包括localStorage，indexDB，WebSQL和FileSystem。

在這篇文章中，我們將關注襯着引擎，因為它處置懲罰HTML和CSS的剖析和可視化，這是大多數Javascript運用程序不停與之交互的東西。

襯着引擎的概述

襯着引擎的主要職責是在瀏覽器屏幕上顯現請求的頁面。

襯着引擎能夠顯現HTML和XML文檔和圖象。假如您運用分外的插件，引擎還能夠顯現差別範例的文檔，如PDF。

襯着引擎

與Javascript引擎相似，差別的瀏覽器也運用差別的襯着引擎。這些是一些盛行的：

• Gecko &＃8211; 火狐
• WebKit &＃8211; Safari
• Blink &＃8211; Chrome，Opera（從15版最先）

襯着的歷程

襯着引擎從收集層吸收所請求文檔的內容。

構建DOM樹
襯着引擎的第一步是剖析HTML文檔並將剖析的元素轉換為DOM樹中的現實DOM節點。

設想一下你有以下的筆墨輸入：

Hello, friend!

這個HTML的DOM樹以下所示：

基本上，每一個元素都被示意為一切其子元素的父節點子元素直接包括在它的內部。

構建CSSOM樹

CSSOM指的是CSS對象模子。當瀏覽器構建頁面的DOM時，它在援用外部theme.css CSS款式表的head部份碰到link標記。估計它能夠須要該資本來顯現頁面，它馬上發出請求。假定theme.css文件包括以下內容：

body {
font-size: 16px;
}
p {
font-weight: bold;
}
span {
color: red;
}
p span {
display: none;
}
img {
float: right;
}

與HTML一樣，引擎須要將CSS轉換為瀏覽器能夠運用的東西 &＃8211; CSSOM。 以下是CSSOM樹的表面：

你想曉得為何CSSOM有一個樹構造？當盤算頁面上任何對象的末了一組款式時，瀏覽器從適用於該節點的最平常劃定規矩最先（比方，假如它是body元素的子元素，則運用一切body款式），然後遞歸地細化經由歷程運用更詳細的劃定規矩來盤算款式。

讓我們來看看我們給出的詳細例子。包括在body元素中的span標籤中的任何文本的字體大小為16像素，而且具有赤色。這些款式是從body元素繼承而來的。假如span元素是p元素的子元素，則因為正在運用更詳細的款式，因而不會顯現其內容。

別的請注意，上面的樹不是完全的CSSOM樹，只顯現了我們決定在款式表中重寫的款式。每一個瀏覽器都供應了一組默許的款式，也稱為“user agent styles” &＃8211; 這是我們在沒有明白供應任何款式時看到的。我們的款式簡樸地掩蓋這些默許值。

構建襯着樹

HTML中的可視指令與CSSOM樹中的款式數據連繫在一起用於豎立襯着樹。

你能夠會問什麼是襯着樹？這是依據它們在屏幕上顯現的遞次構建的視覺元素樹。它是HTML和響應的CSS的可視化示意。此樹的目標是為了以準確的遞次繪製內容。

Webkit中，襯着樹中的每一個節點都被稱為的襯着器或襯着對象。

這就是上述DOM和CSSOM樹的襯着器樹的表面：

為了構建襯着樹，瀏覽器大抵以下：

• 從DOM樹的根最先，它遍歷每一個可見節點。某些節點不可見（比方，劇本標記，元標記等），而且因為它們未反映在顯現的輸出中而被疏忽。一些節點經由歷程CSS隱蔽，而且也從襯着樹中省略。比方，span節點 &＃8211; 在上面的例子中，它並不存在於襯着樹中，因為我們有一個明白的劃定規矩來設置display：none屬性。
• 關於每一個可見節點，瀏覽器找到恰當的CSSOM劃定規矩並運用它們。
• 它發出帶有內容及其盤算款式的可見節點

你能夠在這裏看看RenderObject的源代碼（在WebKit中）：https://github.com/WebKit/web&＃8230;

我們來看看這個類的一些中心內容：

class RenderObject : public CachedImageClient {
// Repaint the entire object. Called when, e.g., the color of a border changes, or when a border
// style changes.
Node* node() const { ... }
RenderStyle* style; // the computed style
const RenderStyle& style() const;
...
}

每一個襯着器代表一個矩形地區，一般對應於一個節點的CSS框。它包括多少信息，比方寬度，高度和位置。

襯着樹的規劃

當襯着器被豎立並增加到樹中時，它沒有位置和大小。盤算這些值稱為規劃。

HTML運用基於流程的規劃模子，這意味着大部份時候內它能夠經由歷程一次通報盤算多少。坐標系相干於根襯着器。運用頂部和左邊坐標。

規劃是一個遞歸歷程 &＃8211; 它從根顯現器最先，它對應於HTML文檔的元素。規劃經由歷程部份或全部襯着器條理構造遞歸地繼承遞歸，為須要它的每一個襯着器盤算多少信息。

根襯着器的位置是0,0，而且其尺寸具有瀏覽器窗口（也稱為視口）的可見部份的尺寸。

最先規劃歷程意味着給每一個節點確實的坐標，它應當湧現在屏幕上。

繪製襯着樹

在此階段中，遍歷襯着器樹並挪用襯着器的paint（）要領以在屏幕上顯現內容。

繪畫能夠是全局或增量式（與規劃相似）：

• 全局 &＃8211; 全部樹被從新繪製。
• 增量 &＃8211; 只要一些襯着器以不影響全部樹的體式格局舉行變動。襯着器使其矩形在屏幕上無效。這會致使操作系統將其視為須要重繪和天生繪畫事宜的地區。操作系統經由歷程將幾個地區合併為一個智能體式格局來完成。

平常來說，相識繪畫是一個漸進的歷程是很主要的。為了更好的用戶體驗，襯着引擎會嘗試儘快在屏幕上顯現內容。它不會比及一切的HTML被剖析，才最先構建和安排襯着樹。內容的部份內容將被剖析並顯現，而該歷程繼承堅持來自收集的其他內容項目。

處置懲罰劇本和款式表的遞次

當剖析器抵達標記時，劇本將被馬上剖析並實行。文檔剖析停息，直到劇本實行終了。這意味着該歷程是同步的。

假如劇本是外部的，那末它起首必需從收集中獵取（也是同步的）。一切剖析都邑住手，直到抓取完成。

HTML5增加了一個選項，將劇本標記為異步，以便它能夠被其他線程剖析和實行。

優化襯着機能

假如您想優化您的運用，那末您須要關注五個主要方面。這些是您能夠掌握的地區：

• Javascript &＃8211; 在之前的文章中，我們引見了編寫優化代碼的主題，這些代碼不會阻撓UI，內存效率高等等。當觸及襯着時，我們須要斟酌Javascript代碼與DOM元素之間的交互體式格局這一頁。Javascript能夠在UI中豎立大批變動，尤其是在SPA中。
• 款式盤算 &＃8211; 這是肯定哪一個CSS劃定規矩適用於基於婚配選擇器的元素的歷程。一旦定義了劃定規矩，就會運用這些劃定規矩，並盤算每一個元素的終究款式。
• 規劃 &＃8211; 一旦瀏覽器曉得哪些劃定規矩適用於元素，就能夠最先盤算後者佔用的空間以及它在瀏覽器屏幕上的位置。 Web的規劃模子定義了一個元素能夠會影響其他元素。比方，的寬度會影響其子元素的寬度等等。這一切都意味着規劃歷程是盤算密集型的。該畫圖是在多個條理完成的。
• Paint &＃8211; 這是現實像素被添補的位置。該歷程包括繪製文本，色彩，圖象，邊框，暗影等 &＃8211; 每一個元素的每一個視覺部份。
• 合成 &＃8211; 因為頁面部份被劃分為多個圖層，因而須要依據準確的遞次將其繪製到屏幕上，以便頁面顯現準確。這異常主要，特別是關於堆疊元素。

優化您的Javascript

Javascript常常觸發瀏覽器中的視覺變化。當豎立一個SPA時更是如此。

以下是關於Javascript能夠優化哪些部份以改良襯着的一些提醒：

• 為視覺更新防備setTimeout或setInterval。這些將在框架中的某個點挪用回調，末了能夠會發作。我們想要做的就是在畫面最先時觸發視覺變化，不要錯過它。
• 如前所述，將長時候運轉的Javascript盤算移至Web Workers。
• 運用微使命在多個框架中引入DOM變動。這是為了防備使命須要接見DOM，Web Worker不能接見這些使命。這基本上意味着你將一個大使命分解成更小的使命，並依據使命的性子在requestAnimationFrame，setTimeout，setInterval中運轉它們。

優化你的CSS

經由歷程增加和刪除元素，變動屬性等來修正DOM將使瀏覽器從新盤算元素款式，而且在許多狀況下還會全部頁面的規劃或最少部份規劃。

要優化襯着，請斟酌以下幾點：

• 削減選擇器的複雜性。選擇器的複雜度能夠比盤算元素款式所需的時候多50％，而構建款式自身的其他事變則須要花費凌駕50％的時候。
• 削減style盤算必需發作的元素數目。實質上，直接對幾個元素舉行款式變動，而不是使全部頁面失效。

優化規劃

瀏覽器的規劃從新盤算能夠異常沉重。斟酌以下優化：

• 只管削減規劃的數目。當您變動款式時，瀏覽器會搜檢是不是有任何變動請求從新盤算規劃。對屬性（如寬度，高度，左邊，頂部以及一般與多少相干的屬性）的變動須要規劃。所以，只管防備轉變它們。
• 只管在較早的規劃模子上運用Flexbox。它運轉速率更快，可為您的運用程序製造龐大的機能上風。
• 防備強迫同步規劃。須要記着的是，在Javascript運轉時，前一幀中的一切舊規劃值都是已知的，可供您查詢。假如你接見box.offsetHeight它不會是一個題目。然則，假如您在接見該框之前變動了框的款式（比方，經由歷程向元素動態增加一些CSS類），瀏覽器必需先運用款式變動並運轉規劃。這能夠異常耗時且消耗資本，因而請只管防備。

優化paint

這一般是一切使命中運轉時候最長的，因而只管防備這類狀況異常主要。以下是我們能夠做的事變：

• 變動除變更或不透明度之外的任何屬性都邑觸發繪畫。鄭重運用它。
• 假如觸發layout，則還會觸發paint，因為變動多少圖形會致使元素的視覺變動。
• 經由歷程圖層提拔和動畫編排來削減繪畫地區。