WebAssembly 不徹底指北

背景：從 JavaScript 提及

JavaScript 佔據着統治地位，不論是公開仍是私有的項目、任何組織、世界任何地區，JavaScript 都是第一。 -GitHub 2018 年度報告

隨着JavaScript的快速發展，目前它已然成爲最流行的編程語言之一，這背後正是 Web 的發展所推進的。可是隨着JavaScript被普遍的應用，它也暴露了不少問題：

• 語法太靈活致使開發大型 Web 項目困難；
• 性能不能知足一些場景的須要；

這兩大問題成爲JavaScript頭頂上的達摩克利斯之劍，危及着JavaScript更普遍的應用。

Brendan Eich 作夢也沒想到，本身花了十天倉促設計出來的 JavaScript，一經推出就被普遍接受，得到了全世界範圍內大量的用戶使用。前人挖坑，後人來填。既然JavaScript已經成爲了Web編程的事實標準，那麼這兩個亟待解決的問題勢必將要被解決。

MS、Google、Mozilla的探索

MS：TypeScript

第一個問題被著名開源軟件大廠MicroSoft解決。

MicroSoft集結了C#的首席架構師以及Delphi和Turbo Pascal的創始人Anders Hejlsberg等明星陣容，打造了TypeScript。

TypeScript它是JavaScript的一個嚴格超集，並添加了可選的靜態類型和使用看起來像基於類的面向對象編程語法操做 Prototype。因此TypeScript能夠這樣理解：

MicroSoft利用TypeScript這把鋒利的武器打造了VSCode等史詩級項目，因而乎，第一把達摩克利斯之劍"語法太靈活致使開發大型 Web 項目困難"彷佛已經被解決。

可是，因爲TypeScript最終仍然是被編譯成JavaScript在瀏覽器中執行，因此困擾着JavaScript開發者的性能問題，仍然沒有被解決。

Google：V8

早在2008年，Google就推出了自家的JavaScript引擎V8，試圖使用JIT技術提高JavaScript的執行速度，而且它真的作到了。

因爲JIT技術的引入，V8使得Web性能獲得了數十倍的增加！

上圖展現了Chrome的v8與IE的Chakra benchmark結果。具體的地址點我

既然性能獲得瞭如此大的提高，那麼JavaScript廣爲詬病的性能問題獲得瞭解決嗎？爲啥Web性能仍是被挑戰？

單線程 -> 阻塞

Web應用中，性能瓶頸大部分的緣由已經不在JavaScript，而在於DOM。瀏覽器中一般會把DOM和JavaScript獨立實現。下圖展現了不一樣瀏覽器DOM和JavaScript的實現狀況：

因爲Dom渲染和JavaScript引擎是相對獨立的，這兩個模塊相互訪問的時候，都是經過接口訪問。因爲JavaScript單線程的特性，這種訪問只能是單工的。

能夠把DOM和JavaScript各自想象爲一個島嶼，他們之間用橋樑鏈接，JavaScript每次訪問DOM，都要通過這座橋，並交納過橋費，訪問的次數越多，費用就越高，所以，推薦的作法是儘量減小過橋的次數，一直待在JavaScript島上。爲了達到這個目的，可使用Virtual Dom，Web Worker來實現。這裏就再也不贅述。

JIT VS AOT，在重型計算面前仍然力不從心

剛纔談到，V8引擎首次將JIT技術引入JavaScript當中，大幅提高了執行速度。那麼首先咱們須要理解什麼是JIT，以及AOT。

AOT: Ahead-of-Time compilation

必須是強類型語言，編譯在執行以前，編譯直接生成CPU可以執行的二進制文件，執行時CPU不須要作任何編譯操做，直接執行，性能最佳。

JIT: Just-in-Time compilation

沒有編譯環節。執行時根據上下文生成二進制彙編代碼，灌入CPU執行。JIT執行時，能夠根據代碼編譯進行優化，代碼運行時，不須要每次都翻譯成二進制彙編代碼，V8就是這樣優化JavaScript性能的。

因爲JavaScript的動態語言類型已沒法改變，因此只能採用JIT的形式對性能進行優化。

爲了進一步JIT優化效率，繼而提高JavaScript性能，瀏覽器鼻祖Mozilla推出了asm.js。

Mozilla：asm.js

和TypeScript比較類似的是，asm.js一樣也是強類型的JavaScript，可是他的語法則是JavaScript的子集，是爲了JIT性能優化而專門打造的。

一段典型的asm.js代碼以下：

能夠看到，asm.js使用了按位或0的操做，來聲明x爲整形。從而確保JIT在執行過程當中儘快生成相應的二進制代碼，不用再去根據上下文判斷變量類型。

Mozilla給出了asm.js的benchmark：

asm.js To WebAssembly

自從Mozilla提出了asm.js，Google、MicroSoft、Apple都以爲asm.js的思路不錯，因而聯合起來，一同共建WebAssembly生態。

同asm.js不一樣的是，WebAssembly是一份字節碼標準，以字節碼的形式依賴虛擬機在瀏覽器中運行。

能夠依賴Emscripten等編譯器將C++/Golang/Rust/Kotlin等強類型語言編譯成爲WebAssembly字節碼（.wasm文件）。因此WebAssembly並非Assembly（彙編），它只是看起來像彙編而已。一份典型的.wasm文件以下所示：

00000000: 0061 736d 0100 0000 0108 0260 017f 0060  .asm.......`...`
00000010: 0000 0215 0203 656e 7603 6d65 6d02 0001  ......env.mem...
00000020: 026a 7303 6c6f 6700 0003 0201 0107 0b01  .js.log.........
00000030: 0765 7861 6d70 6c65 0001 0a23 0121 0041  .example...#.!.A
00000040: 0042 c8ca b1e3 f68d c8ab ef00 3703 0041  .B..........7..A
00000050: 0841 f2d8 918b 0236 0200 4100 1000 0b    .A.....6..A....
複製代碼

實戰

環境搭建:編譯Emscripten

本次使用官方推薦的CPP語言編譯成爲WebAssembly文件，並在瀏覽器中執行。首先須要搭建Emscripten環境。Emscripten被用於將CPP文件轉換成爲WASM字節碼文件。

常規的搭建流程十分繁瑣：

一、確保安裝CMake、Xcode、Python 2.7.x 
二、git clone https://github.com/juj/emsdk.git
三、./emsdk install --build=Release sdk-incoming-64bit binaryen-master-64bit

等待約1個小時……，切換版本須要從新編譯。

複製代碼

不過，早有好心人爲咱們準備了捷徑：使用Docker鏡像，快速開啓你的WebAssembly之路吧。只須要如下幾步：

一、安裝Docker
二、docker pull trzeci/emscripten:latest
三、alias emcc='docker run –rm -v $(pwd):/src -u emscripten trzeci/emscripten emcc’ 切換版本只須要pull相應的tag 複製代碼

編譯CPP的MD5函數至WASM

首先須要找到一份計算MD5的CPP代碼：

git@github.com:codenoid/md5-cpp.git

使用emscripten.h中的EMSCRIPTEN_KEEPALIVE宏，確保emcc編譯器在編譯時，不會由於該函數沒有被調用而優化掉這個函數。

這裏uint8_t* 被隱式類型轉換爲char*

使用emcc編譯CPP文件至WASM文件：

emcc -O3 -s WASM=1 -s EXTRA_EXPORTED_RUNTIME_METHODS='["cwrap"]’ md5.c 複製代碼

• -O3: 優化級別，O3是最高優化級別

• -s WASM=1：生成wasm代碼，而不是asm.js代碼

• -s EXTRA_EXPORTED_RUNTIME_METHODS=‘[「cwrap」]‘：在JavaScript中使用cwrap函數引用導出函數

最後會生成a.out.js和a.out.wasm兩個文件。分別是WASM和JavaScript交互的膠水文件以及WebAssembly字節碼文件。

計算md5並輸出結果：

這裏有兩點須要注意：

• a.out.js會自動fetch wasm文件，因爲獲取wasm文件也存在跨域的狀況，可使用http-server本地起一個sever。
• CPP的變量類型以及JavaScript的變量類型須要進行轉換，轉換由膠水代碼自動執行，具體的轉換規則以下：

benchmark

既然WebAssembly主打性能提高，那麼benchmark就必不可少啦，針對"ivweb"短字符加密100000次，benchmark的結果以下：

能夠看到WebAssembly相較於純JavaScript，計算性能大約提高了39%，這與廣泛的100%+的性能提高有着較大差距。這是爲何呢？

我又對2M的長文本進行benchmark對比，結果以下：

這一次的提高就比較大了。是什麼形成了如此大的差距呢？我猜想有兩點緣由：

1. 對"ivweb"短字符加密100000次時，JIT優化介入後，不須要每次都去編譯，JavasScript性能獲得了極大提高。
2. 對"ivweb"短字符加密100000次時，膠水代碼執行次數較多，拖慢了性能。

針對與以上兩點猜想，又作了一組benchmark，加密「ivweb」5000000次

能夠看到WebAssembly與純粹的JavaScript性能差距以及不大了，驗證了個人猜測。

本次benchmark代碼我已經上傳到GitHub倉庫中：

git@github.com:PeacefulLion/wasm-benchmark.git

啓示

鑑於V8的強大性能，90%的應用場景下你不須要WebAssembly.

啓示：如何提升JS代碼性能？

1. 聲明變量時提供默認類型，加快JIT介入
2. 不要輕易改變變量的類型
3. Node.js像JAVA同樣也存在JIT預熱？

總結與展望

如今的WebAssembly還並不完美。可是線程的支持，異常處理，垃圾收集，尾調用優化等，都已經加入WebAssembly的計劃列表中了。

未來，WebAssembly可以被用於：

• 擴展瀏覽器端視音頻處理能力（H.265）
• 基於WebAssembly的高性能Web應用(加密、遊戲、挖礦？)

目前Webpack4已經支持import wasm文件的形式調用wasm文件。

將來，WebAssembly 將可能直接經過 HTML 標籤進行引用，好比：

<script src="./wa.wasm"></script>；
複製代碼

或者能夠經過 JavaScript ES6 模塊的方式引用，好比：

import xxx from './wa.wasm';；
複製代碼

資源分享

WAPM

一個WebAssembly包管理器

WasmExplorer

在線 CPP 轉 WASM

參考文章

WebAssembly 現狀與實戰

Web端H.265播放器研發解密

悄悄掀起 WebAssembly 的神祕面紗

---

關注【IVWEB社區】公衆號獲取每週最新文章，通往人生之巔！