JavaScript 是如何工做的：解析、抽象語法樹（AST）+ 提高編譯速度5個技巧

時間 2019-11-05

標籤 javascript 如何解析抽象語法樹 ast 提高編譯速度技巧欄目 JavaScript 简体版

原文原文鏈接

這是專門探索 JavaScript 及其所構建的組件的系列文章的第 14 篇。javascript

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等着你！前端

若是你錯過了前面的章節，能夠在這裏找到它們：java

概述

咱們都知道運行一大段 JavaScript 代碼性能會變得很糟糕。這段代碼不只須要經過網絡傳輸，並且還須要解析、編譯成字節碼，最後執行。在以前的文章中，咱們討論了 JS 引擎、運行時和調用堆棧等，以及主要由谷歌 Chrome 和 NodeJS 使用的V8引擎。它們在整個 JavaScript 執行過程當中都發揮着相當重要的做用。這篇說的抽象語法樹一樣重要:在這咱們將瞭解大多數 JavaScript 引擎如何將文本解析爲對機器有意義的內容，轉換以後發生的事情以及作爲 Web 開發者如何利用這一知識。git

編程語言原理

那麼，首先讓咱們回顧一下編程語言原理。無論你使用什麼編程語言，你須要一些軟件來處理源代碼以便讓計算機可以理解。該軟件能夠是解釋器，也能夠是編譯器。不管你使用的是解釋型語言(JavaScript、Python、Ruby)仍是編譯型語言(c#、Java、Rust)，都有一個共同的部分:將源代碼做爲純文本解析爲 抽象語法樹(abstract syntax tree, AST) 的數據結構。github

AST 不只以結構化的方式顯示源代碼，並且在語義分析中扮演着重要角色。在語義分析中，編譯器驗證程序和語言元素的語法使用是否正確。以後，使用 AST 來生成實際的字節碼或者機器碼。web

抽象語法樹（abstract syntax tree 或者縮寫爲 AST），或者語法樹（syntax tree），是源代碼的抽象語法結構的樹狀表現形式，這裏特指編程語言的源代碼。和抽象語法樹相對的是具體語法樹（concrete syntaxtree），一般稱做分析樹（parse tree）。通常的，在源代碼的翻譯和編譯過程當中，語法分析器建立出分析樹。一旦 AST 被建立出來，在後續的處理過程當中，好比語義分析階段，會添加一些信息。

AST 程序

AST 不只僅是用於語言解釋器和編譯器，在計算機世界中，它們還有多種應用。使用它們最多見的方法之一是進行靜態代碼分析。靜態分析器不執行輸入的代碼，可是，他們仍然須要理解代碼的結構。正則表達式

例如，你可能想要實現一個工具，該工具能夠找到公共代碼結構，以便你能夠重構它們以減小重複。你可能會經過使用字符串比較來實現這一點，但這個會至關簡單且有侷限性。編程

固然，若是你對實現這樣的工具感興趣，你不須要編寫本身的解析器。有許多與 Ecmascript規範徹底兼容的開源項目。Esprima 和 Acorn 便是黃金搭檔，還有許多工具能夠幫助解析器生成輸出，即 ASTs ，ASTs 被普遍應用於代碼轉換。c#

例如，你可能但願實現一個將 Python 代碼轉換爲J avaScript 的轉換器。基本思想是使用Python 轉換器生成 AST，而後使用 AST 生成JavaScript代碼。segmentfault

你可能會以爲難以置信，事實是 ASTs 只是部分語言的不一樣表示法。在解析以前，它被表示爲遵循一些規則的文本，這些規則構成了一種語言。在解析以後，它被表示爲一個樹結構，其中包含與輸入文本徹底相同的信息。所以，也能夠進行反向解析而後回到文本。

JavaScript 解析

讓咱們看看 AST 是如何構建的。咱們用一個簡單的 JavaScript 函數做爲例子:

function foo(x) {
    if (x > 10) {
        var a = 2;
        return a * x;
    }

    return x + 10;
}

解析器會產生以下的 AST：

注意，爲了觀看方便，這裏是解析器將生成的結果的簡化版本。實際的 AST 要複雜得多。然而，這裏的目的是爲了運行源碼以前的第一個步驟前。若是人想查看實際的 AST 是什麼樣子，能夠訪問 AST Explorer。它是一個在線工具，你以在其中輸入一些 JavaScript 並輸出對應的 AST。

你可能會問，爲何須要知道 JavaScript解析器工做原理，畢竟這是瀏覽器工做，你想法是部分正確。下圖展現了 JavaScript 執行過程當中不一樣階段的耗時。仔細瞅瞅，你或許會發現一些有趣的東西。

發現沒？一般狀況下，瀏覽器解析 JavaScript 大約需佔總執行時間的 15% 到 20%。我沒有具體統計過這些數值。這些是來自真實應用程序和以某種方式使用 JavaScript 的網站的統計數據。也許 15% 看起來不是不少，但相信我，這是不少。

一個典型的單頁程序加載 0.4 mb 左右的 JavaScript，瀏覽器須要大約 370ms 來解析它。也許你會又說，這也不是不少嘛，自己花費的時間並很少。但請記住，這只是將 JavaScript 代碼解析爲 AST 所須要的時間。這並不包括運行自己的時間，也不包括在頁面加載，如 CSS 和 HTML 渲染過程的耗時。這些還只涉及桌面，移動瀏覽器的狀況會更加複雜，在手機上花在解析上的時間一般是桌面瀏覽器的 2 到 5 倍。

上圖顯示了 1MB JavaScript 包在不一樣類的移動和桌面瀏覽器解析時間。

更重要的是，爲了得到更多類原生的用戶體驗而把愈來愈多的業務邏輯堆積在前端，Web 應用程序正變得愈來愈複雜。你能夠輕易地想到網絡應用受到的性能影響。只需打開瀏覽器開發工具，而後使用該工具來解析、編譯和瀏覽器中發生的全部其餘事情上所消耗的時間。

不幸的是，移動瀏覽器上沒有開發者工具。不過不用擔憂，這並不意味着你對此無能爲力。由於有 DeviceTiming 工具,它能夠用來幫助檢測受控環境中腳本的解析和運行時間。它經過插入代碼來封裝本地代碼，這樣每次從不一樣的設備訪問頁面時，就能夠在本地測量解析和運行時間。

好事就是 JavaScript 引擎作了不少工做來避免冗餘的工做，並獲得了更好的優化，如下爲主流瀏覽器使用的技術。

例如，V8 實現腳本流(script streaming)和代碼緩存技術。腳本流即腳本一旦開始下載，async 和 deferred的腳本就會在單獨的線程上解析。這意味着在下載腳本完成後幾乎當即完成解析，這會提高 10% 的頁面加載速度。

每次訪問頁面時，JavaScript 代碼一般編譯爲字節碼。然而，一旦用戶訪問另外一頁面，該字節碼就被丟棄。發生這種狀況是由於編譯後的代碼很大程度上依賴於編譯時機器的狀態和上下文。這是 Chrome 42 引入字節碼緩存的緣由。該技術會本地緩存編譯過的代碼，這樣當用戶返回同一頁面時，諸以下載，解析和編譯等全部步驟都會被跳過。這使得 Chrome 能夠節省大約 40％的解析和編譯時間。此外，這還能夠節省移動設備的電量。

在 Opera 中，Carakan 引擎能夠重用另外一個程序最近編譯過的輸出。沒有要求代碼必須來自相同的頁面甚至同個域下。這種緩存技術實際上很是高效，還能夠徹底跳過編譯步驟。它依賴於典型的用戶行爲和瀏覽場景:每當用戶在應用程序/網站中遵循某個用戶的特定瀏覽習慣，都會加載相同的 JavaScript 代碼。不過，Carakan 引擎早已被谷歌的 V8 所取代。

Opera 新的 JavaScript 引擎「Carakan」，目前速度是其餘已存在 JavaScript 引擎（基於 SunSpider）的2.5倍。其在轉化爲本地機器代碼時專門針對正則表達式作了優化。

Firefox 使用的 SpiderMonkey 引擎不會緩存全部內容。它能夠過渡到監視階段，在這個階段中，它計算執行給定腳本的次數。基於此計算，它推導出頻繁使用而能夠被優化的代碼部分。

SpiderMonkey 是 Mozilla 項目的一部分，是一個用 C 語言實現的 JavaScript 腳本引擎，另外還有一個叫作Rhino 的 Java 版本。

顯然，有些人決定什麼都不作。Safari 的首席開發人員 Maciej Stachowiak 表示，Safari 不會對編譯後的字節碼進行任何緩存。緩存技術他們是有考慮過的問題，可是他們尚未實現，由於生成代碼的耗時小於總運行時間的 2%。

這些優化不會直接影響 JavaScript 源代碼的解析，可是會盡量徹底避免。畢竟作總比沒作好點？

咱們能夠作不少事情來改善應用程序的初始加載時間。最小化加載的 JavaScript 數量：代碼越小、解析所須要時間就越少，運行時間也就越小。要作到這一點，咱們只能在當前的路由上加載所需的代碼，而不是加載一大陀的代碼。例如，PRPL模式即表示該種代碼傳輸類型。或者，能夠檢查代碼的依賴關係，看看是否有什麼冗餘的依賴致使代碼庫膨脹，然而，這些東西須要很大的篇幅來進行討論。

本文的主要的目的討論做爲 Web 開發人員能夠作些什麼來幫助 JavaScript 解析器更快地完成它的工做。還有,現代JavaScript 解析器使用 啓發法(heuristics) 來決定是否當即運行指定的代碼片斷或者推遲在將來的某個時候運行。基於這些啓發法，解析器將進行即時或懶解析。

啓發法是針對模型求解方法而言的，是一種逐次逼近最優解的方法。這種方法對所求得的解進行反覆判斷實踐修正直至滿意爲止。啓發法的特色是模型簡單，須要進行方案組合的個數少，所以便於找出最終答案。此方法雖不能保證獲得最優解，但只要處理得當，可得到決策者滿意的近似最優解。通常步驟包括:定義一個計算總費用的方法;報定判別準則;規定方案改選的途徑;創建相應的模型;送代求解。

當即解析會運行須要當即編譯的函數。它主要作三件事:構建 AST，構建做用域層級和查找全部語法錯誤。另外一方面，懶解析只運行未編譯的函數。它不構建AST，也不查找全部語法錯誤，它只構建做用域層級，與當即解析相比節省了大約一半的時間。

顯然，這不是一個新概念。即便像 IE 9 這樣的瀏覽器也支持這種類型的優化，儘管與如今的解析器的工做方式相比，這種優化方式還很初級。

來看一個例子，假設有如下代碼片斷:

function foo() {
    function bar(x) {
        return x + 10;
    }

    function baz(x, y) {
        return x + y;
    }

    console.log(baz(100, 200));
}

foo()

就像前面的例子同樣，代碼被輸入到語法分析器中，語法分析器進行語法分析並輸出AST，以下：

聲明函數 foo
調用函數 foo
在 foo 裏聲明函數 bar 接收參數 x, 並返回 x 和 10 相加的結果
在 foo 裏聲明函數 baz 接收參數 x和 y, 並返回 x 和 y 相加的結果
調用 baz 函數傳入 100 和 2。
調用 console.log 參數爲以前函數調用的返回值。

那麼期間發生了什麼? 解析器看到 bar 函數的聲明、baz 函數的聲明、bar函數的調用和 console.log 的調用。可是，解析器作了一些徹底無關的額外工做即解析 bar 函數。爲何這可有可無? 由於函數 bar 歷來沒有被調用過(或者至少在那個時候沒有)。這是一個簡單的示例，看起來可能有些不一樣尋常，但在許多實際應用程序中，許多聲明的函數從未被調用。

這裏不解析bar函數，該函數聲明瞭卻沒有調用它。只在須要的時候在函數運行前進行真正的解析。懶解析仍然須要找到函數的整個主體併爲其聲明，但僅此而已。它不須要語法樹，由於它尚未被處理。另外，它不會從堆中分配內存，而堆一般會佔用至關多的系統資源，簡而言之，跳過這些步驟會帶來很大的性能改進。

因此以前的例子，解析器實際上會像以下這樣解析：

注意，這裏只確認 bar 函數聲明，沒有進入 bar 函數體。在這種狀況下，函數體只是一個返回語句。可是，與大多數實際應用程序同樣，它能夠更大，包含多個返回語句、條件語句、循環、變量聲明，甚至嵌套函數聲明。這徹底是在浪費時間和系統資源，由於這個函數永遠不會被調用。

這是一個至關簡單的概念，但實際上，它的實現是很是難的，不侷限於以上示例。整個方法還能夠適用於函數、循環、條件、對象等。基本上，全部須要解析的東西。

例如，下面是一個很是常見的 JavaScript 模式。

var myModule = (function() {
     // 整個模塊的邏輯
     // 返回模塊對象
})();

大多數現代 JavaScript 解析器都能識別這種模式，此模式表示代碼須要當即解析。

那麼爲何解析器不都使用懶解析呢? 若是懶解析某些代碼，這些代碼須要當即執行，這實際上會使代碼運行速度變慢。須要運行一次懶解析以後進行另外一個當即解析，這和當即解析相比，運行速度會慢 50%。

如今對解析器底層原理有了大體的瞭解，是時候考慮如何提升解析器的解析速度。能夠用這種方式編寫代碼，以便在正確的時間解析函數。大多數解析器都能識別一種模式:使用括號封裝函數。對於解析器來講，這幾乎老是一個積極的信號，即函數須要當即執行。若是解析器看到一個左括號，緊接着是一個函數聲明，它將當即解析這個函數。能夠經過顯式地聲明當即執行的函數來幫助解析器加快解析速度。

假設有一個名爲 foo 的函數。

function foo(x) {
    return x * 10;
}

由於沒有明顯地標識代表須要當即運行該函數因此瀏覽器會進行懶解析。然而，咱們肯定這是不對的，那麼能夠運行兩個步驟。

首先，將函數存儲在一個變量中:

var foo = function foo(x) {
    return x * 10;
};

注意，這裏有使用函數的名稱 foo,這不是必需的，可是建議這樣作，由於在拋出異常的狀況下，stacktrace 會保留實際函數名稱，而不只僅是 <anonymous>。

以上事例解析器執行懶解析，能夠用括號封裝起來，讓解析器進行當即解析：

var foo = (function foo(x) {
    return x * 10;
});

如今，解析器看見 function 關鍵字前的左括號便會當即進行解析。

由於須要知道解析器在哪些狀況下執行懶解析或者當即解析，因此很難手動管理。此外，還須要花時間考慮是否當即調用某個函數，確定沒人想這麼作的。

最後，這種地讓代碼更難閱讀和理解。可使用 Optimize.js 能夠幫咱們作這類事情，該工具只是用來優化 JavaScript 源代碼的初始加載時間，它們對代碼進行靜態分析，而後經過使用括號封裝須要當即運行的函數以便瀏覽器當即解析並準備運行它們。

像往常同樣編碼，而後有一段代碼看起來像這樣的：

(function() {
    console.log('Hello, World!');
})();

一切看起來都很好，如預期的那樣工做，並且速度很快，由於在函數聲明以前添加左括號。固然，在進入生產環境以前須要進行代碼壓縮，如下爲壓縮工具的輸出：

!function(){console.log('Hello, World!')}();

好像沒問題，代碼像之前同樣工做。可是好像少了什麼，壓縮工具刪除包裹函數的括號，而是在函數前放置了一個感嘆號，這意味着解析器將跳過此並將執行惰解析。

最重要的是，爲了可以執行該函數，它將在懶解析以後當即進行當即解析。這會使代碼運行得更慢，幸運的是，能夠利用 Optimize.js 來解決此類問題，傳給 Optimize.js 壓縮過的代碼會輸出以下代碼：

!(function(){console.log('Hello, World!')})();

這還差很少，如今擁有一箭雙鵰方案：壓縮代碼且解析器正確地識別懶解析和當即解析的函數。

預編譯

但爲何不能在服務器端完成全部這些工做呢？畢竟，最好這樣作一次並將結果提供給客戶端，而不強制各個客戶端重複作該項事情。那麼，目前正在討論引擎是否應該提供一種執行預編譯腳本的方法，這樣就能夠節省瀏覽器運行時間。

從本質上講，該思路是擁有能夠生成字節碼的務器端工具，這樣只須要傳輸字節碼並在客戶端運行，以後會看到啓動時間的一些主要差別。這可能聽起來很誘人，但事情並不是那麼簡單，還可能會產生相反的效果，由於它會更大，而且極可能須要簽署代碼並出於安全緣由對其進行處理。例如，V8 團隊正在努力解決重複解析問題，這樣預編譯有可能實際並無多大的用處。