JavaScript 是如何運行的？

什麼是JavaScript？

咱們來確認一下JavaScript的定義：JavaScript 是一門解釋型的動態語言。

解釋型語言是相對於編譯型語言存在的，源代碼不是直接編譯爲目標代碼，而是轉成中間代碼，再由解釋器對中間代碼進行解釋運行。

主流編程語言有編譯型（如 C++）、解釋型（如 JavaScript）、和半解釋半編譯（如 Java）這幾大類型。

代碼是怎麼運行的？

首先咱們來了解一下代碼是怎麼運行的。

咱們知道，代碼是由CPU執行的，而目前的CPU並不能直接執行諸如if…else之類的語句，它只能執行二進制指令。可是二進制指令對人類實在是太不友好了：咱們很難快速準確的判斷一個二進制指令1000010010101001表明什麼？因此科學家們發明彙編語言。

彙編語言

彙編語言實際上就是二進制指令的助記符。

假設10101010表明讀取內存操做，內存地址是10101111，寄存器地址是11111010，那麼完整的操做101010101010111111111010就表明讀取某個內存地址的值並裝載到寄存器，而彙編語言並無改變這種操做方式，它只是二進制指令的映射：

LD:10101010 
id:10101111
R:11111010

這樣上述指令就能夠表達爲LD id R ，大大加強了代碼的可讀性。

可是這樣還不夠友好，CPU只能執行三地址表達式，和人的思考方式、語言模式相距甚遠。因此偉大的科學家們又發明了高級語言。

高級語言

「代碼是寫給人看的，不是寫給機器看的，只是順便計算機能夠執行而已。」

高級語言之因此稱之爲「高級」，就是由於它更加符合咱們的思惟和閱讀習慣。if…else這種語句看起來要比1010101010舒服的多了。可是計算機並不能直接執行高級語言，因此還須要把高級語言轉化爲彙編語言/機器指令才能執行。這個過程就是編譯。

JavaScript 須要編譯嗎？

JavaScript毫無疑問是高級語言，因此它確定是須要編譯後才能執行。但爲何咱們又稱之爲解釋型語言呢？它和編譯型語言、半解釋半編譯型語言又有什麼區別呢？咱們先從編譯提及。

編譯

以前咱們已經瞭解編譯的概念，下面咱們來聊聊平臺：一樣一份C++代碼在Windows上會編譯成.obj文件，而在Linux上則生成.o文件，二者不能通用。這是由於一個可執行文件除了代碼外還須要操做系統 API、內存、線程、進程等系統資源，而不一樣的操做系統其實現也不盡相同。好比咱們熟悉的I/O多路複用（事件驅動的靈魂），在Windows上的實現方案是IOCP方案，在Linux上是epoll。因此針對不一樣的平臺，編譯型語言須要分別編譯，甚至須要分別編寫，並且生成的可執行文件其格式並不相同。

跨平臺

Java在此之上更進一步，它經過引入字節碼實現了跨平臺運行：不管是在什麼操做系統上.java文件編譯出的都是.class文件（這就是字節碼文件，一種中間形態的目標代碼）。而後Java對不一樣的系統提供不一樣的Java虛擬機用於解釋執行字節碼文件。解釋執行並不生成目標代碼，但其最終仍是要轉爲彙編/二進制指令來給計算機執行的。

假如咱們本身徹底獨立的新寫一個簡單的操做系統，那麼它能不能運行Java呢？很顯然是不能的，由於並無這個系統相應的JVM。因此Java的跨平臺、任何其餘語言的跨平臺，都是有侷限性的。

Java採用半解釋半編譯的好處就是大大提高了開發效率，然而相應的則下降了代碼的執行效率，畢竟虛擬機是有性能損失的。

解釋執行

JavaScript則更進一步。它是徹底的解釋執行，或者叫作即時編譯。它不會有中間代碼生成，也不會有目標代碼生成。這個過程一般由宿主環境（如瀏覽器、Node.js）包辦。

編譯過程

如今咱們確認了，即便是解釋執行的語言，也是須要編譯的。那麼代碼是如何編譯的呢？咱們來簡單瞭解一下。

詞法分析

詞法分析會把語句分解成詞法單元，即Token。

function square(n){
 return n*n;
}

這個函數會被詞法分析器識別爲function ，square，(，n，)，{，return，，n ,*，n ，}而且給它們加上標註，表明這是一個變量仍是一個操做。

語法分析

這個過程會把Token轉化成抽象語法樹（AST）：

{
 type:'function',
    id:{
        type:'id'
        name:'square'
    },
    params:[
        {
            type:'id',
            name:'n'
        }
    ]
    ...
}

優化及代碼生成

在這一步編譯器會作一些優化工做，好比刪除多餘運算、刪除未用賦值、合併部分變量等等操做，最後生成目標代碼。

因爲即時編譯型語言的編譯一般發生在運行前幾微秒，因此編譯器來不及作太多的優化工做。這也是相比編譯型語言，早期JavaScript性能孱弱的緣由之一。不過就如今而言，益於 V8 引擎（相比早期的JavaScript的引擎轉換成字節碼或解釋執行，Node.js能夠用 V8 提供的 JS2C 工具將 JavaScript 轉譯爲 C++代碼），JavaScript 和其餘語言性能上的差距已經不足爲道了。

連接及裝載

目標代碼基本不能獨立運行。應用程序通常都會由多個部分（模塊）組成 ，好比C++中一個簡單的輸出就要引入標準庫 iostream：

#include <iostream>
using namespace std;
int main(){    
    cout << "Happy Hacking!\n";    
    return 0;
}

編譯器須要把多份目標代碼（庫）連接起來才能生成可執行文件。至此，咱們簡單的瞭解了編譯過程。但實際上編譯比咱們所講的要複雜得多，在此就不在展開了。

什麼是動態語言，動態類型？

咱們還知道，JavaScript是動態語言。那麼什麼是動態語言？

一般來講，這是指在運行時代碼能夠根據某些條件改變自身結構的語言。好比JavaScript在運行時新的函數、對象、甚至代碼均可以被引進（eval）；又好比Objective-C，它也能夠在運行時修改對象，但它不能動態建立類，也沒有 eval 方法。那Objective-C算是動態語言嗎？因此我認爲，動態語言是個程度的問題，咱們沒必要在這個概念上太過糾結，能夠更多的關注其應用。APP中經常使用的熱更新功能就是基於動態語言特性而得以實現的。

JavaScript又是一門動態類型的語言，動態類型又是什麼？動態類型的定義卻是很明確：數據類型不是在編譯階段肯定，而是在運行時肯定。

那麼 TypeScript 是什麼類型的語言呢？它有靜態類型檢查，它是靜態語言嗎？實際上它只是 JavaScript 的一個方言。TypeScript 最終仍是要轉譯爲 JavaScript 才能執行（tsc），就如同咱們使用babel 把 ES6 代碼轉譯爲 ES5 同樣。這個過程嚴格上來講不是編譯。

TypeScript 最大的優點就是靜態類型檢查和類型推斷，這是 JavaScript 嚴重缺失的能力。但實際上若是咱們忽略IDE 給的報錯提示強行運行 TS 代碼，也仍是有概率可以成功跑起來的。

錯誤

剛剛咱們提到報錯，不妨再擴展說一說錯誤。一般來講錯誤分爲如下幾種：

• 編譯時錯誤
• 連接時錯誤
• 運行時錯誤

是否是和編譯過程可以嚴格對應起來？

編譯時錯誤

編譯時錯誤分爲：

• 語法錯誤

  var str ='s ;

  這就是典型的語法錯誤，這種代碼沒法生成AST，在詞法分析階段就會報錯。一般咱們這麼寫代碼，IDE 就會報錯。這是IDE的優化工做，和詞法分析相關。

• 類型錯誤

  編譯器會檢查咱們聲明的變量和函數的類型，JavaScript中咱們很是熟悉的Type Error:undefined is not object就是此類錯誤。

連接時錯誤

在連接階段發生的異常。這種狀況 JavaScript 中比較少見，在編譯型語言中比較常見。

運行時錯誤

這是最難排查的錯誤了，舉例來講：

int divider(int a,int b){
    return a/b;
}

上面的代碼在編輯編譯、連接階段都沒問題，也可以正常的生成可執行文件。可是一旦如此使用divider(1,0)就會報錯了，這就是典型的運行時錯誤。一般來講運行時錯誤都是程序不夠健壯致使的。

JavaScript中最多見的十個錯誤：

下圖是某錯誤處理平臺收集統計的JavaScript Top10 錯誤，其中7個TypeError，1個 ReferenceError：

顯然這 8 種問題，咱們都能用 TypeScript 在編碼早期及時應對。

結語

如今咱們已經瞭解JavaScript是如何運行的。可是瞭解這些可以幫咱們寫出更好的代碼嗎？

答案是確定的。且不說TypeScript可以幫助咱們完善類型檢查和類型推斷，JavaScript的做用域、this也是和編譯過程強相關的；而目前主流的小程序框架都可以支持一套代碼、多個平臺，相信讀完本文後，你大體也瞭解了這些技術背後的原理。
Happy Hacking！

順便給你們推薦一下Fundebug，很好用的BUG監控工具~