JavaScript 事情道理之十一－襯着引擎及機能優化小技能

2019年8月24日 94次阅读 来源: Troland

原文請查閱
這裏，略有刪減，本文採納
學問同享簽名 4.0 國際許可協定同享，BY
Troland。

本系列延續更新中，Github 地點請查閱這裏。

這是 JavaScript 事情道理的第十一章。

迄今為止，之前的 JavaScript 事情道理系列文章集中於關注 JavaScript 言語自身的功用，在閱讀器中的實行狀況，怎樣優化等等。

然則，當在構建收集運用的時刻，不單單議只是編寫本身運轉的 JavaScript 代碼。所編寫的 JavaScript 代碼與運轉環境息息相干。明白 JavaScript 運轉環境，它的運轉道理以及其構成會讓你構建出更好的運用而且一旦讓運用程序運轉於種種環境下的時刻，讓你越發胸中有數地應對潛伏的題目。

《JavaScript 事情道理之十一－襯着引擎及機能優化小技能》

那末，讓我們一探閱讀器主要組件吧：

  • 用戶界面: 包括地點欄，退卻和行進按鈕，書籤菜單等等。本質上，這裏包括了除顯現用戶所看到的網頁自身的窗口之外的閱讀器的每一個部份。
  • 閱讀器引擎: 處置懲罰用戶界面和襯着引擎的交互
  • 襯着引擎: 擔任顯現網頁。襯着引擎剖析 HTML 和 CSS 並在屏幕上顯現剖析的內容。
  • 收集: 運用各個平台的差別完成所提議的諸如 XHR 請求的收集挪用，這些收集挪用是基於跨平台的接口完成的。
  • UI 後端: 擔任繪製諸如複選框和窗口的中心部件。它暴露出一個平台無關的泛型接口。它底層運用操縱體系 UI 要領。
  • JavaScript 引擎: 我們在之前的系列文章中有細緻引見過。基本上，這是 JavaScript 代碼實行的處所。
  • 數據存儲: 收集運用能夠須要當地存儲一切數據。支撐的存儲機制範例包括 localStorage, indexDB, WebSQL 以及 FileSystem。

本文將專註引見襯着引擎，因為它是用來處置懲罰 HTML 和 CSS 的剖析和可視化的，而這些是大多數的 JavaScript 運用須要延續舉行交互的方面。

襯着引擎概述

襯着引擎的主要職責即在閱讀器屏幕上顯現請求的頁面。

襯着引擎能夠顯現 HTML，XML 文檔以及圖片。假如運用分外的插件，就能夠顯現諸如 PDF 的差別範例的文檔。

襯着引擎

與 JavaScript 引擎相似，差別閱讀器也運用差別的襯着引擎。以下為比較盛行的引擎：

  • Gecko－Firefox
  • WebKit－Safari
  • Blink－Chrome, Opera(從版本 15 最先)

襯着歷程

襯着引擎從收集層獵取到請求的文檔內容。

《JavaScript 事情道理之十一－襯着引擎及機能優化小技能》

構建 DOM 樹

襯着引擎的第一步即剖析 HTML 文檔和轉化剖析的元素為 DOM 樹 上的現實 DOM 節點。

假定有以下的文本輸入框：

<html>
  <head>
    <meta charset="UTF-8">
    <link rel="stylesheet" type="text/css" href="theme.css">
  </head>
  <body>
    <p> Hello, <span> friend! </span> </p>
    <div> 
      <img src="smiley.gif" alt="Smiley face" height="42" width="42">
    </div>
  </body>
</html>

HTML 的 DOM 樹相似如許：

《JavaScript 事情道理之十一－襯着引擎及機能優化小技能》

基本上，每一個元素是直接包括於其內的元素的父節點。然後順次類推。

構建 CSSOM 樹

CSSOM 即 CSS Object Model。當閱讀器構建頁面的 DOM 樹的時刻，它在 head 標籤部份碰到一個援用外部 theme.css 款式表的 link 標籤。示意它能夠須要款式表來襯着頁面，因而便立時分配一個請求來獵取款式表。假定以下為 theme.css 文件內容：

body { 
  font-size: 16px;
}

p { 
  font-weight: bold; 
}

span { 
  color: red; 
}

p span { 
  display: none; 
}

img { 
  float: right; 
}

與 HTML 一樣，襯着引擎須要把 CSS 轉化為閱讀器能夠操縱的東西－即 CSSOM。以下為 CSSOM 的也許樣子容貌：

《JavaScript 事情道理之十一－襯着引擎及機能優化小技能》

想知道為何 CSSOM 是樹狀構造的嗎？當為頁面上的恣意對象盤算其終究的款式集的時刻，閱讀器先把最為通用的款式劃定規矩運用於該節點（比方，它是 body 的子節點，會先運用 body 的一切款式）然後經由過程運用更加詳細的款式劃定規矩來遞歸重定義盤算的款式。

讓我們看下詳細的例子吧。body 中的 span 標籤中的任何筆墨款式為字體大小 16 像素且字體色彩為赤色。這些款式繼承自 body 元素。p 元素的子元素 span 因為運用了更加詳細的款式從而不會顯現其內容(display:none)。

另有，請注重以上 CSSOM 樹並不完全而且只顯現了款式表中指定的重寫款式。每一個閱讀器供應了一份默許的款式集即 『用戶代辦款式』－ 這即當沒有供應任何款式的時刻的默許顯現款式。我們的款式只是簡樸地重寫了這些默許款式。

構建襯着樹

HTML 中的可視化指令和 CSSOM 樹的款式數據結合起來建立襯着樹。

你能夠為問襯着樹是什麼？它是按遞次構建可視化元素並顯現在屏幕上的樹。它是帶有響應的款式的 HTML 的視覺表現。該樹旨在按正確的遞次繪製內容。

在 Webkit 中襯着樹中的每一個節點等於一個襯着器或許襯着器對象。

以下為以上的 DOM 和 CSSOM 樹合成的襯着器樹的也許樣子容貌：

《JavaScript 事情道理之十一－襯着引擎及機能優化小技能》

為了建立襯着樹，閱讀器也許做了幾下幾件事：

  • 從 DOM 樹的根節點最先，遍歷每一個可見節點。一些節點是不可見的（比方，script 標籤，meta 標籤等等），然後會被疏忽，因為它們並不會在襯着的輸出中顯現。一些節點經由過程款式隱蔽然後也會被疏忽。比方以上例子中的 span 節點，因為為其顯式設置了 display: none 的款式。
  • 閱讀器為每一個可見節點運用相對應的 CSSOM 劃定規矩並運用這些款式劃定規矩。
  • 釋放出包括內容及其經由盤算的款式的可見節點。

能夠閱讀下 RenderObject 的源碼(Webkit 中)：https://github.com/WebKit/web…

看一下這個類的一些中心構件吧：

class RenderObject : public CachedImageClient {
  // 重繪全部對象。當邊框色彩轉變或許邊框款式變動的時刻挪用。
  
  Node* node() const { ... }
  
  RenderStyle* style;  // 盤算的款式
  const RenderStyle& style() const;
  
  ...
}

每一個襯着器對象代表一個矩形地區通常是和一個節點的 CSS 盒模子相對應。它包括諸如寬度，高度以及定位的多少信息。

襯着樹規劃

當建立了襯着器而且增加到襯着樹的時刻，它並沒有定位和大小的信息。盤算這些值即稱為規劃。

HTML 運用了流式規劃模子，意即大多數狀況下能夠一次性盤算出襯着器的多少信息。坐標體系是相干於根襯着器的。這裏運用 Top 和 left 坐標。

規劃是一個遞歸的歷程－它從根襯着器最先舉行襯着，根襯着器即 HTML 文檔的 html 元素。規劃繼承經由過程一部份或許全部襯着器層級構造遞歸舉行，為每一個須要盤算多少信息的襯着器盤算其信息。

根襯着器的定位為 0,0 和大小即為閱讀器窗口的可視化部份(比方 viewport)。

舉行規劃的歷程即盤算出每一個節點在屏幕上顯現的正確位置。

繪製襯着樹

該階段，遍歷襯着器樹然後挪用襯着器的 paint() 要領來在屏幕上顯現其內容。

繪製能夠是全局或增量式的(相似於規劃)：

  • 全局－重繪全部樹。
  • 增量－以某種體式格局只變動部份襯着器而不會影響到整顆樹。襯着器取消其在屏幕上的矩形地區。這會致使操縱體系把它看成是一個須要重繪的地區並天生一個 paint 事宜。操縱體系會智能地把幾個地區合併成一個以提拔襯着機能。

總之，明白繪製是個漸進式的歷程是很主要的。為了更好的交互體驗，襯着引擎會試圖儘快在屏幕上顯現內容。它不會守候一切的 HTML 構造剖析完成才最先構建和規劃襯着樹。會優先剖析和顯現部份內容，與此同時延續處置懲罰從收集吸收的剩下的內容項。

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

當剖析器碰到 <script> 標籤的時刻會馬上剖析和實行該標籤內里的代碼。全部文檔的剖析會住手直到劇本實行終了。意即該歷程是同步的。

當 script 援用的是一個外部資本，必需起首獵取該資本(也是同步的)。一切的剖析會住手直到獵取該劇本資本。

HTML5 增加了一個選項來異步加載該資本，如許就能夠運用別的的線程來剖析和實行該資本。IE 能夠運用 defer 屬性，別的能夠運用 async 屬性。IE10 以下運用 defer 屬性，IE10 以上也能夠運用 async 屬性。

這裡有一個須要注重的處所即 IE10 以下關於 defer 的支撐，翻開 https://caniuse.com 查找即可發明關於 IE10 以下的支撐是一些須要注重的處所即 defer 的劇本有能夠會在 DOMContentLoaded 事宜以後才最先運轉，拜見這裏，這裏就不做試驗了，有興緻能夠點擊這裏測試下 IE 下的表現。

這裏輕微做一下引伸，在 jQuery 源碼中，ready.js 有一段以下的代碼：

// Catch cases where $(document).ready() is called
// after the browser event has already occurred.
// Support: IE <=9 - 10 only
// Older IE sometimes signals "interactive" too soon
if ( document.readyState === "complete" ||
    ( document.readyState !== "loading" && !document.documentElement.doScroll ) ) {

    // Handle it asynchronously to allow scripts the opportunity to delay ready
    window.setTimeout( jQuery.ready );

} else {

    // Use the handy event callback
    document.addEventListener( "DOMContentLoaded", completed );

    // A fallback to window.onload, that will always work
    window.addEventListener( "load", completed );
}

內里的 window.setTimeout( jQuery.ready ); 是許可劇本有時機耽誤實行 ready 事宜。也許是為 IE script 標籤的 defer 屬性預備的吧？

優化襯着機能

若想要優化收集運用的機能，須要關注五個主要的方面。這些方面是你能夠舉行掌握的：

  1. JavaScript－之前的文章中有引見了編寫不壅塞 UI ，高效的代碼等等。談到襯着時刻，須要斟酌 JavaScript 代碼是怎樣和頁面上的 DOM 元素舉行交互的。JavaScript 會在界面上做許多的變動，特別是在單頁運用中。
  2. 款式盤算－這個歷程即運用款式劃定規矩到婚配選擇器的元素上。一旦定義了款式劃定規矩，它們會運用於對應的元素，然後盤算每一個元素的終究款式。
  3. 規劃－一旦閱讀器相識元素運用的款式劃定規矩，它會最先盤算元素所佔用的空間和其在閱讀器屏幕上的顯現位置。依據網頁的規劃模子定義一個元素的規劃會影響到別的的元素。比方，<body> 標籤的寬度會影響到其子孫元素的寬度等等。這即意味着規劃歷程是相稱耗時的。繪製是在多個圖層完成的。
  4. 繪製－該階段即最先添補現實像素。這一歷程包括繪製筆墨，色彩，圖片，邊框，暗影等一切每一個元素的可見部份。
  5. 合成－因為頁面部份被繪製成潛伏的多層，它們必需在屏幕以正確的遞次舉行繪製，如許頁面襯着才會一般。這是至關主要的，特別是關於那些堆疊元素。

優化 JavaScript 代碼

JavaScript 常常會在閱讀器端觸發視覺轉變。尤其是在構建 SPA 的歷程中會更多。

這裡有一些優化 JavaScript 中部份代碼來提拔襯着效力的發起：

  • 防止運用 setTimeout 或許 setInterval 來舉行視覺的變動。這些會在幀的某個時候點挪用 callback，有多是在幀的末端。如許就會形成卡頓。必需在幀的最先觸發視覺變動。
  • 把耗時的 JavaScript 移入之前提到的網頁事情線程。
  • 運用微使命來處置懲罰跨多個幀的 DOM 變動。這是為了防備當使命須要接見 DOM，而收集事情線程沒法辦到的狀況的。

    意即須要把一個大型的使命分割為多個小使命然後依據差別的使命性子在 requestAnimationFrame ，setTimeout 或 setInterval 中實行。

優化款式

經由過程增加和移除元素及變動屬性等等修正 DOM 會致使閱讀器從新盤算元素款式及大多數狀況全部頁面或許部份頁面的規劃。

運用以下要領來優化襯着：

  • 削減選擇器的複雜度。選擇器複雜度會佔用凌駕盤算所需元素款式的 50% 的時候，剩餘時候即構建款式自身。
  • 削減必需發生款式盤算的元素的個數。本質上，直接變動少數元素的款式而不是使全部頁面的款式失效。

優化規劃

規劃是很消耗閱讀器機能的。斟酌以下優化計劃：

  • 只管削減規劃的數目。當變動款式的時刻，閱讀器搜檢款式變動是不是須要從新盤算規劃。一般而言變動諸如 width, height, left, top 等和多少學相干的屬性會須要規劃。所以，只管防止修正它們。
  • 只管運用 flexbox 來舉行規劃而不是老式的規劃模子。它會襯着得更快而且會極大地提拔收集運用的機能。
  • 防止強迫同步規劃。須要記着的是當運轉 JavaScript的時刻，上一幀的老的規劃值是已知的且能夠被查詢獲得。當接見 box.offsetHeight 這並不會形成機能題目。然則，假如在接見它之前變動它的款式(比方為元素動態增加款式類)，閱讀器將不得不起首運用款式變動然後運轉規劃盤算款式。這將會異常耗時和耗資本，所以全力防止如許做。

優化繪製

這常常會是一切使命中最耗時的，所以只管防止觸發繪製。優化計劃：

  • 變動除 transfroms 或許 opacity 外的屬性會觸發繪製。所以省着點用啊。
  • 當觸發一個規劃也會觸發繪製，因為變動元素的多少信息會變動元素的展現結果。
  • 經由過程提拔層和動畫編排來削減繪製地區。

擴大

參考谷歌官方關於機能的文檔，提拔元素運用以下的代碼：

.moving-element {
  will-change: transform;
}

運用 FASTDOM 來防止強迫同步規劃和發抖。

別的關於 JavaScript 代碼的優化方面，防止去處置懲罰一些微優化，比方運用 offsetTop 比用 getBoundingClientRect 速率更快，但這得基於所建立的收集運用而言，假定建立一個遊戲，對機能請求異常高而且挪用這些要領的處所多，那末機能的提拔將會很可觀的。還記得之前常常會去運用諸如 jsperf 來測試某個要領的速率，千萬別鑽牛角尖，隨機應變，防止掉入去計算那些細小的優化而支付過大的精神。

關於襯着能夠運用一些骨架圖來提拔用戶體驗。

一些主意

  • 關於機能的體驗，實在你能夠設想成造屋子吧，假如是全部翻修當然是會越發耗時，然則假如裝修某個地區就會提拔機能。
  • 然後有个中的某個屬性會提拔機能，這能夠明白為『工欲善其事必先利其器』。
  • 關於使命的切分能夠明白為，建立設想的哲學，小技能。

參考資本

本系列延續更新中，Github 地點請查閱這裏。

    原文作者：Troland
    原文地址: https://segmentfault.com/a/1190000015310731
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞