近幾年，WebAssembly在快速的成長中，被稱為未來的web發展方向。
本文主要內容是關於WebAssembly，包括和asm.js的一些對比，以及WebAssembly的一些特性和開發方式。
本文主要內容來自Google I/O '17中Alex Danilo的關於WebAssembly的主題演講。感興趣的可以去YouTube看原文視訊。

JavaScript效能瓶頸

首先，我們需要從JavaScript說起，JavaScript目前作為web端的中流砥柱，可以說是撐起了一片天下，加上最近火熱的node.js，大有一統前後端的趨勢。但其作為一門解釋型語言，在大型專案中的執行速度實在是差強人意。通過下面這張圖我們可以通過一個簡單的“+”運算，來看看JavaScript引擎都需要做什麼。

上圖為JavaScript如何把執行加號，因為在JavaScript中，一個“+”的兩邊可能是任何型別的資料，並且兩邊的型別並不一定相等，所以在執行時候，引擎首先需要判斷型別，然後再根據型別執行對應的操作，我們從上圖中也可以看到，一個“+”的過程相當複雜。而對於現代引擎來說，已經很難去優化這部分過程，所有的都是必須的。

所以現在有很多關於這方面的研究，關於提升JavaScript的效能瓶頸。目前主要有兩種思路：

1. 一種是以typescript，JSX 為代表。比如typescript在編寫的時候需要程式設計師指定變數的型別，和一門強型別語言一樣，然後再編譯成JavaScript，相當於把強型別編譯成弱型別。
2. 以及幾個來自Mozilla的天才工程師發明了asm.js，asm最初的設計目標是在Emscripten中，將寫好的c++轉換成js中一個很小的子集，通過用型別標註，來識別變數型別，而js引擎會將這部分程式碼轉換成更快的原生程式碼。
   下面是一個示例：

//asm.js示例
function add1(x){
     x = x|0;
     return (x+1)|0
}
//通過x後面標註的|0，可以識別x是一個int型別變數。

關於上面兩種方法，很快就發現第二種的潛力和速度是要明顯優於第一種的。對於第一種，只是加快了現有的編譯速度，比如JIT編譯。但是對於第二種，卻可以大大改變現在JavaScript的編譯過程，甚至實現AOT。

隨著幾年的發展，人們發現asm.js的確對JavaScript效能提示有很好的效果。但是，asm也存在著缺陷，因為它並未標準化，導致它在不同瀏覽器上的支援不一樣，導致了效能差異也很明顯，有的瀏覽器對它支援不好。

所以，在Mozilla, Google, Microsoft, and Apple的聯合下，對asm.js去粗取精，進行標準化，誕生了WebAssembly，WebAssembly並不是一種需要去寫的語言，也沒有人會去這麼做，它可以說是一種編譯目標。

首先我們需要清楚一件事情，如果想要極限的優化程式碼執行，讓它執行的更快，減少無用中間過程， 就如上面的“+”操作，我們最終極的目標就是“+”能夠直接被轉換為一條簡單CPU指令操作。而這個也是WebAssembly想要做的。

而WebAssembly目前可以以原生程式碼速度的1.2倍執行，這個資料看上去令人非常吃驚的。但它的確已經存在了，並且這項技術也已經被四個主流的瀏覽器引擎所支援。

過去對於web效能的提升

在正式介紹之前，我們可以回顧下以前提升web效能的一些方式。

在過去提升Web效能的方式主要是通過外掛，比如flash和它的JIT。但是我們也知道這項技術在今天已經過時了，原因之一也是因為它的安全問題，哪怕是在沙盒環境中，它們的安全漏洞依舊存在。其次，這些外掛對Web API的支援並不好。當然，最主要的一個原因應該是移動端的蓬勃發展，導致這些外掛已再無用武之地。

再後來，是Google的Native Client計劃。它的目標是將js編譯後執行在web瀏覽器中。但是缺陷和明顯，和web api的互動性弱，不支援dom物件，後來也產生了portable Native Client，但是因為安全原因實現太過困難，也沒有瀏覽器會那麼做。

與asm的對比

下面我們簡單看看在V8引擎中，為什麼WebAssembly會比asm更好，主要體現在優化引擎TurboFan參與 的階段。
以上面的示例asm.js程式碼為例，我們看看這段程式碼在引擎中發生了什麼。

首先瀏覽器對程式碼進行解析，分析詞法環境進行，生成ast樹。ast樹是記憶體中你的程式的邏輯表示。不同瀏覽器對於接下來的步驟會有所不同，在v8中，引擎會根據生成的AST直接生成對應的機器碼，這部分由V8的Full Compiler完成。事實上，這段解析js的過程已經是很快了，基本不再有可能去優化這個過程了。

在上面生成的是未經過優化的程式碼。接下來，在V8中會對部分程式碼（由上面的Full Compiler執行一段時間後得出的“熱門”程式碼和那些執行較慢的程式碼）使用它的TurboFan優化引擎。對程式碼進行重新編譯，從而大大提高效率。

對於asm.js，它會參與整個分析階段，包括生成ast，生成機器碼，找出那些使用“熱門”的程式碼以及重編譯等等，這些其實都是屬於CPU週期，asm.js卻需要全程參與。但如果是用WebAssembly，就如下圖所示，WebAssembly會出現在最後階段，這是因為WebAssembly在編譯階段已經完成了優化，所以在不需要再參與分析階段。

所以，WebAssembly相比asm大大減小了優化編譯時期的工作量。通過資料顯示，而相比與asm.js，WebAssembly 的速度比asm.js快2/3(指的是執行時速度)。

WebAssembly介紹

下面，我們將要正式介紹WebAssembly。

關於WebAssembly，之前看過很多人問，有了WebAssembly是不是意味著我們不再需要去寫JavaScript了，答案當然是NO。WebAssembly只是JavaScript的一個補充，它提供了一個途徑，去讓那些寫C++，C或是rust code以及其他靜態型別語言的人，把它們寫的編譯成一個模組，而這個模組可以被JavaScript呼叫，與JavaScript協同工作。

WebAssembly作為JavaScript的補充，提供了和c++一樣的強型別機制，例如int32。有了這些強型別的機制，引擎就可以省去之前花費大量時間的型別處理，將JavaScript像C++一樣進行AOT（靜態編譯），從而實現將JavaScript的速度提升到和原生程式碼一樣的程度。

使用WebAssembly，你可以不受任何影響的使用所有的web API，所有的標準DOM函式以及API，當然，也有一些新的東西，比如32位的浮點數或是64位整數，以及新增的threas支援和SIMD(單指令多資料)。需要了解的是，WebAssembly 的執行堆是完全與WebAssembly 程式隔離的，所以你是無法干涉或者改變它的執行過程，這也是一個很重要的安全特性。

需要指出的一點是，WebAssembly 是無法訪問任何的平臺APIs。所以，你需要通過JavaScript本身與調解這一切，而WebAssembly 只需要去完成它本身能夠做的，比如數值方面的工作。

WebAssembly 語言介紹

下面這張圖展示了WebAssembly 的一些要素，數值型別與c++相同，並且在WebAssembly中，它們與c++一樣同樣是靜態型別。操作方面，提供基本的四則運算，除此之外，也包括平方根，取整。

支援情況

而對於開發者所關心的支援情況，

我們可以看到，目前這項技術是被主流引擎廠商所支援，所以開發者不用擔心支援情況。

WebAssembly 開發

現在開發者現在可以到webassembly官網去獲得如何開發WebAssembly 的一些指導，先從一個hello World開始。這個網站包括了基本所有WebAssembly的內容，包括技術細節，API和DEMO。

作為開發 WebAssembly的工具 。目前有binarian，這也是新誕生一種工具，通過與emscripten一同協作來產生WebAssembly code。此外，也可以用其他工具比如GCC 。

接下來，當你有了一個c++檔案，就可以通過相應的編譯命令，得到兩個檔案，.js和.WASM。這個js檔案便可以直接在瀏覽器中執行。
同時，也可以在WASM中呼叫js，包括一些DOM APIs，通過使用EM_ASM這個命令：

//CALL JS FROM WASM
#include<emscripten.h>
int main(){
    EM_ASM(
        const elt = document.getElementById("hello-world");
        elt.innerText = "Hello World";
    );
    return 0;
}

當然，不僅限於Web API，你同樣也可以可以在C++中匯入你在js中定義的函式。

總結

以上就是關於webassembly的一些介紹，現在webassembly被稱為未來web的發展方向。個人認為它是解決JavaScript效能瓶頸的出路，期待以後web能夠給人們展示越來越炫酷和驚豔的頁面。

開發資源：

示例：