WebAssembly，Web的新时代
在瀏覽器之爭(zhēng)中，Chrome憑借JavaScript的卓越性能取得了市場(chǎng)主導(dǎo)地位，然而由于JavaScript的無類型特性，導(dǎo)致其運(yùn)行時(shí)消耗大量的性能做為代價(jià)，這也是JavaScript的瓶頸之一。WebAssembly旨在解決這一問題。本文從WebAssembly的起源到開發(fā)實(shí)踐對(duì)其做全面探究，幫助開發(fā)者對(duì)WebAssembly有全面的了解。
緣起
讓我們從瀏覽器大戰(zhàn)說起。微軟憑借Windows系統(tǒng)捆綁Internet Explorer的先天優(yōu)勢(shì)擊潰Netscape后，進(jìn)入了長(zhǎng)達(dá)數(shù)年的靜默期。而Netscape則于1998年將Communicator開源，并由Mozilla基金會(huì)衍生出Firefox瀏覽器，在2004年發(fā)布了1.0版本。從此，第二次瀏覽器大戰(zhàn)拉開帷幕。這場(chǎng)大戰(zhàn)由Firefox瀏覽器領(lǐng)銜，Safari、Opera等瀏覽器也積極進(jìn)取，Internet Explorer的主導(dǎo)地位首次受到挑戰(zhàn)。2008年Google推出Chrome瀏覽器，不但逐步侵蝕Firefox的市場(chǎng)，更是壓制了老邁的Internet Explorer。在此次大戰(zhàn)之后的2012年，StatCounter的數(shù)據(jù)指出Chrome以微弱優(yōu)勢(shì)超越Internet Explorer成為世界上最流行的瀏覽器。
分析Google Chrome瀏覽器戰(zhàn)勝Internet Explorer的原因，除了對(duì)Web標(biāo)準(zhǔn)更友善的支持外，卓越的性能是其中相當(dāng)重要的因素，而瀏覽器性能之爭(zhēng)的本質(zhì)則體現(xiàn)在JavaScript引擎。此前，JavaScript引擎的實(shí)現(xiàn)方式經(jīng)歷了遍歷語法樹到字節(jié)碼解釋器等較為原始的方式，將每條源代碼翻譯成相應(yīng)的機(jī)器碼并執(zhí)行，并不保存翻譯后的機(jī)器碼，使得解釋執(zhí)行很慢。2008年9月，Google發(fā)布了V8 JavaScript引擎。V8被設(shè)計(jì)用于提高Web瀏覽器中JavaScript的執(zhí)行性能，通過即時(shí)編譯JIT（Just-In-Time）技術(shù)，在執(zhí)行時(shí)將JavaScript代碼編譯成更為高效的機(jī)器代碼并保存，下次執(zhí)行同一代碼段時(shí)無需再編譯，使得JavaScript獲得了幾十倍的性能提升。
然而，JavaScript是個(gè)無類型（untyped，變量沒有類型）的語言，這直接導(dǎo)致表達(dá)式c=a+b有多重含義：
- a、b均為數(shù)字，則算術(shù)運(yùn)算符+表示值相加；
- a、b為字符串，則+運(yùn)算符表示字符串連接；
- ?…
表達(dá)式執(zhí)行時(shí)，JIT編譯器需要檢查a和b的類型，確定操作行為。若a、b均為數(shù)字，JIT編譯器則將a、b確認(rèn)為整型，而一旦某一變量變成字符串，JIT編譯器則不得不將之前編譯的機(jī)器碼推倒重來。由此可見，JavaScript的無類型特性建立在消耗大量性能代價(jià)的基礎(chǔ)之上。即便JIT編譯器在對(duì)變量類型發(fā)生變化時(shí)已進(jìn)行相應(yīng)優(yōu)化，但仍然有很多情況JavaScript引擎未進(jìn)行或無法優(yōu)化，例如for-of、try-catch、try-finally、with語句以及復(fù)合let、const賦值的函數(shù)等。
由此可見，JavaScript的無類型是JavaScript引擎的性能瓶頸之一，改進(jìn)方案有兩種：一是設(shè)計(jì)一門新的強(qiáng)類型語言并強(qiáng)制開發(fā)者進(jìn)行類型指定；二是給現(xiàn)有的JavaScript加上變量類型。
微軟開發(fā)的TypeScript屬于第一種改進(jìn)方案。它是擴(kuò)展了JavaScript特性的語言，包含了類型批注，編譯時(shí)類型檢查，類型推斷和擦除等功能，TypeScript開發(fā)者在聲明變量時(shí)指定類型，使得JavaScript引擎能夠更快將這種強(qiáng)類型的語言編譯成弱類型。
看看第二種方案：
代碼1表示帶有兩個(gè)參數(shù)（a和b）的JavaScript函數(shù)，和通常JavaScript代碼不同的地方在于a=a | 0及b=b | 0，以及返回值后面均利用標(biāo)注進(jìn)行了按位OR操作。這么做的優(yōu)點(diǎn)是使JavaScript引擎強(qiáng)制轉(zhuǎn)換變量的值為整型執(zhí)行。通過標(biāo)注加上變量類型，JavaScript引擎就能更快地編譯。
既然增加變量類型能夠提升Web性能，有沒有辦法將靜態(tài)類型代碼例如C/C++等轉(zhuǎn)換成JavaScript指令的子集呢？上面的這段代碼恰恰是作為JavaScript子集的asm.js，由代碼2的C語言編譯而來：
事實(shí)上，早在1995年起就已經(jīng)有Netscape Plugin API（NPAPI）在內(nèi)的可以使用瀏覽器運(yùn)行C/C++程序的項(xiàng)目在開發(fā)。而2013年問世的asm.js是目前較為廣泛的方案。asm.js是一種中間編程語言，允許用C/C++語言編寫的計(jì)算機(jī)軟件作為Web應(yīng)用程序運(yùn)行，并保持更好的性能，而Mozilla Firefox從版本22起成為第一個(gè)為asm.js特別優(yōu)化的網(wǎng)頁瀏覽器。
Google也同樣在為原生代碼運(yùn)行在Web端而努力。Google Native Client（NaCl）采用沙盒技術(shù)，讓Intel x86、ARM或MIPS子集的機(jī)器碼直接在沙盒上運(yùn)行。它能夠在無需安裝插件的情況下從瀏覽器直接運(yùn)行原生可執(zhí)行代碼，使Web應(yīng)用程序可以用接近于機(jī)器碼運(yùn)作的速度來運(yùn)行。而Google Portable Native Client（PNaCl）則稍有變化，通過一些前端編譯器將C/C++源代碼編譯成LLVM的中間字節(jié)碼而不是x86或ARM代碼，并且進(jìn)行優(yōu)化以及鏈接（如表1所示）。
有了類型支持，第二種方案性能提升潛力遠(yuǎn)遠(yuǎn)大于第一種。
然而，無論是asm.js或現(xiàn)有PNaCl的解決方案，都面臨著一些缺陷（例如1KB的C源碼編譯生成asm.js后的大小有480KB）或其他瀏覽器不支持的窘境，而2016年10月對(duì)Chromium問題跟蹤代碼的評(píng)論更是表明，Google Native Client小組已被關(guān)閉。
作為Web瀏覽器性能和代碼重用的解決方案，asm.js及PNaCl都沒能被普遍接受，那么有沒有上述表格中的特性全部占優(yōu)，且跨廠商的解決方案呢？
WebAssembly旨在解決這個(gè)問題。
新時(shí)代
WebAssembly（簡(jiǎn)稱Wasm）是一種新的適合于編譯到Web的，可移植的，大小和加載時(shí)間高效的格式。這是一個(gè)新的與平臺(tái)無關(guān)的二進(jìn)制代碼格式，目標(biāo)是解決JavaScript性能問題。這個(gè)新的二進(jìn)制格式遠(yuǎn)小于JavaScript，可由瀏覽器的JavaScript引擎直接加載和執(zhí)行，這樣可節(jié)省從JavaScript到字節(jié)碼，從字節(jié)碼到執(zhí)行前的機(jī)器碼所花費(fèi)的即時(shí)編譯JIT（Just-In-Time）時(shí)間。 作為一種低級(jí)語言，它定義了一個(gè)抽象語法樹（Abstract Syntax Tree，AST），開發(fā)人員可以以文本格式進(jìn)行調(diào)試。
WebAssembly描述了一個(gè)內(nèi)存安全的沙箱執(zhí)行環(huán)境，可以在現(xiàn)有的JavaScript虛擬機(jī)中實(shí)現(xiàn)。 當(dāng)嵌入到Web中時(shí)，WebAssembly將強(qiáng)制執(zhí)行瀏覽器的同源和權(quán)限安全策略。因此，和經(jīng)常出現(xiàn)安全漏洞的Flash插件相比，WebAssembly是一個(gè)更加安全的解決方案。
WebAssembly可由C/C++等語言編譯而來。此外，WebAssembly由Google、Mozilla、微軟以及蘋果公司牽頭的W3C社區(qū)組共同努力，基本覆蓋主流的瀏覽器廠商，因此其可移植性相較Silverlight等有極大提升，平臺(tái)兼容問題將不復(fù)出現(xiàn)。
在Web平臺(tái)的很多項(xiàng)目中，對(duì)于原生新功能的支持需要Web瀏覽器或Runtime提供復(fù)雜的標(biāo)準(zhǔn)化的API來實(shí)現(xiàn)，但是JavaScript API往往較慢。使用WebAssembly，這些標(biāo)準(zhǔn)API可以更簡(jiǎn)單，并且操作在更低的水平。例如，對(duì)于一個(gè)面部識(shí)別的Web項(xiàng)目，對(duì)于訪問數(shù)據(jù)流我們可以由簡(jiǎn)單的JavaScript API實(shí)現(xiàn)，而把面部識(shí)別原生SDK做的事情交由WebAssembly實(shí)現(xiàn)。
需要了解的是，WebAssembly不是將C/C++等其他語言編譯到JavaScript，更不是一種新的編程語言。
探究
asm.js
上文的C語言求和代碼經(jīng)由編譯器生成asm.js后如代碼3所示。
上述代碼轉(zhuǎn)換為WebAssembly的文本格式稍顯復(fù)雜，為了理解方便，我們從精簡(jiǎn)的asm.js開始（見代碼4）。
wast文本文件
將asm.js代碼轉(zhuǎn)換為WebAssembly的文本格式 add.wast（轉(zhuǎn)換工具見本文工具鏈章節(jié)，如代碼5所示）。
WebAssembly中代碼的可裝載和可執(zhí)行單元被稱為一個(gè)模塊（module）。在運(yùn)行時(shí)，一個(gè)模塊可以被一組import值實(shí)例化，多個(gè)模塊實(shí)例能夠訪問相同的共享狀態(tài)。目前文本格式中的module主要用S表達(dá)式來表示。雖然S表達(dá)格式不是正式的文本格式，但它易于表示AST。WebAssembly也被設(shè)計(jì)為與ES6的modules集成。
一個(gè)單一的邏輯函數(shù)定義包含兩個(gè)部分：功能部分聲明在模塊中每個(gè)內(nèi)部函數(shù)定義的簽名，代碼段部分包含由功能部分聲明的每個(gè)函數(shù)的函數(shù)體。WebAssembly是帶有返回值的靜態(tài)類型，并且所有參數(shù)都含有類型。上面的add.wast可以解讀為：
- 聲明了一個(gè)名為$add的函數(shù)；
- 包含兩個(gè)參數(shù)a和b，兩者都是32位整型；
- 結(jié)果是一個(gè)32位整型；
- 函數(shù)體是一個(gè)32位的加法：
- 上面是局部變量$a得到的值；
- 下面是局部變量$b得到的值；
- 由于沒有明確的返回節(jié)點(diǎn)，因此return是該加法函數(shù)的最后加載指令。
二進(jìn)制Wasm文件
如圖1所示，由C語言求和代碼經(jīng)過編譯生成二進(jìn)制文件，通讀文件可以找到相應(yīng)的頭部、類型、導(dǎo)入、函數(shù)以及代碼段等。通過JavaScript API載入Wasm二進(jìn)制文件后，最終轉(zhuǎn)換到機(jī)器碼執(zhí)行。
工具鏈
開發(fā)人員現(xiàn)在可以使用相應(yīng)的工具鏈從C / C ++源文件編譯WebAssembly模塊。WebAssembly由許多工具支持，以幫助開發(fā)人員構(gòu)建和處理源文件和生成的二進(jìn)制內(nèi)容。
Emscripten
Emscripten是其中無法回避的工具之一，如圖2所示。在圖2中，Emscripten SDK管理器（emsdk）用于管理多個(gè)SDK和工具，并且指定當(dāng)前正被使用到編譯代碼的特定SDK和工具集。
Emscripten的主要工具是Emscripten編譯器前端（emcc），它是例如GCC的標(biāo)準(zhǔn)編譯器的簡(jiǎn)易替代實(shí)現(xiàn)。
Emcc使用Clang將C/C++文件轉(zhuǎn)換為L(zhǎng)LVM（源自于底層虛擬機(jī)Low Level Virtual Machine）字節(jié)碼，使用Fastcomp（Emscripten的編譯器核心，一個(gè)LLVM后端）把字節(jié)碼編譯成JavaScript。輸出的JavaScript可以由Node.js執(zhí)行，或者嵌入HTML在瀏覽器中運(yùn)行。這帶來的直接結(jié)果就是，C和C++程序經(jīng)過編譯后可在JavaScript上運(yùn)行，無需任何插件。
WABT和Binaryen
除此之外，對(duì)于想要使用由其他工具（如Emscripten）生成的WebAssembly二進(jìn)制文件感興趣的開發(fā)者，目前http://webassembly.org/官方額外提供了另外兩組不同的工具：
- WABT ——WebAssembly二進(jìn)制工具包；
- Binaryen——編譯器和工具鏈。
WABT工具包支持將二進(jìn)制WebAssembly格式轉(zhuǎn)換為可讀的文本格式。其中wasm2wast命令行工具可以將WebAssembly二進(jìn)制文件轉(zhuǎn)換為可讀的S表達(dá)式文本文件。而wast2wasm命令行工具則執(zhí)行完全相反的過程。
Binaryen則是一套更為全面的工具鏈，是用C++編寫成用于WebAssembly的編譯器和工具鏈基礎(chǔ)結(jié)構(gòu)庫（如圖3所示）。WebAssembly是二進(jìn)制格式（Binary Format）并且和Emscripten集成，因此該工具以Binary和Emscript-en的末尾合并命名為Binaryen。它旨在使編譯WebAssembly容易、快速、有效。它包含且不僅僅包含下面的幾個(gè)工具。
- wasm-as：將WebAssembly由文本格式（當(dāng)前為S表達(dá)式格式）編譯成二進(jìn)制格式；
- wasm-dis：將二進(jìn)制格式的WebAssembly反編譯成文本格式；
- asm2wasm：將asm.js編譯到WebAssembly文本格式，使用Emscripten的asm優(yōu)化器；
- s2wasm：在LLVM中開發(fā)，由新WebAssembly后端產(chǎn)生的.s格式的編譯器；
- wasm.js：包含編譯為JavaScript的Binaryen組件，包括解釋器、asm2wasm、S表達(dá)式解析器等。
Binaryen目前提供了兩個(gè)生成WebAssembly的流程，由于emscripten的asm.js生成已經(jīng)非常穩(wěn)定，并且asm2wasm是一個(gè)相當(dāng)簡(jiǎn)單的過程，所以這種將C/C ++編譯為WebAssembly的方法已經(jīng)可用（如圖4所示）。
由此可見，Emscripten以及Binaryen提供了完整的C/C++到WebAssembly的解決方案。而Binaryen則幫助提升了WebAssembly的工具鏈生態(tài)。
提示
由于WebAssembly正處于活躍開發(fā)階段，各項(xiàng)編譯步驟和編譯工具會(huì)有大幅變更和改進(jìn)，相信最終的編譯工具和步驟會(huì)趨于便捷，開發(fā)者需要留意官方網(wǎng)站的最新動(dòng)態(tài)。
實(shí)戰(zhàn)
Linux和mac OS平臺(tái)編譯原生代碼到WebAssembly可由如下步驟實(shí)現(xiàn)。
編譯環(huán)境準(zhǔn)備
操作系統(tǒng)必須有可以工作的編譯器工具鏈，因此需要安裝GCC、cmake環(huán)境，此外Python、Node.js及Java環(huán)境也是需要的（其中Java為可選，如圖5所示）。
如果是以其他方式安裝了Node.js，可能需要更新~/.emscripten文件的NODE_JS屬性。
安裝正確的emscripten分支
要編譯原生代碼到WebAssembly，我們需要emscripten的incoming分支。由于emscripten不僅僅是用于WebAssembly的編譯工具鏈，選擇正確的分支尤為重要（如圖6所示）。
其中URLTO具體的URL是https://s3.amazonaws.com/mozilla-games/emscripten/releases/emsdk-portable.tar.gz。
處理安裝異常
可運(yùn)行emcc -v命令進(jìn)行驗(yàn)證安裝。如果遇到如圖7所示的錯(cuò)誤，表明帶有JavaScript后端的LLVM編譯器并未被生成。
通過圖8步驟，可以解決該問題，并且在~/.emscripten 文件中修改如下配置：
開始編譯程序
現(xiàn)在一個(gè)完整的工具鏈已經(jīng)具備，我們可以使用它來編譯簡(jiǎn)單的程序到WebAssembly。但是，還有一些其他注意事項(xiàng)：
- 必須通過參數(shù)-s Wasm=1到emcc（否則默認(rèn)emcc將編譯出asm.js）；
- 除了Wasm二進(jìn)制文件和JavaScript wrapper外，如果還希望emscripten生成一個(gè)可直接運(yùn)行的程序的HTML頁面，則必須指定一個(gè)擴(kuò)展名為.html的輸出文件。
在編譯之前，首先準(zhǔn)備一個(gè)最基本的add.c程序，見代碼6。
按代碼7所示的命令編輯好add.c程序并編譯：
運(yùn)行WebAssembly應(yīng)用
以Chrome瀏覽器為例，如果直接在瀏覽器內(nèi)本地打開HTML文件，會(huì)有圖9所示的錯(cuò)誤：?
由于XMLHttpRequest跨域請(qǐng)求不支持file://協(xié)議，必須經(jīng)由HTTP實(shí)際輸出，可以由Python的SimplHTTPServer改進(jìn)，見代碼8：
在瀏覽器中輸入http://127.0.0.1:8080并打開add.html，就能直接看到轉(zhuǎn)換成WebAssembly的應(yīng)用程序輸出結(jié)果。
創(chuàng)建獨(dú)立WebAssembly
默認(rèn)情況下，emcc會(huì)創(chuàng)建JavaScript文件和WebAssembly的組合，其中JS加載包含編譯代碼的WebAssembly。對(duì)于C/C++開發(fā)人員，他們可能更傾向于創(chuàng)建獨(dú)立的WebAssembly，用于JavaScript開發(fā)人員調(diào)用，見代碼9。
上述命令運(yùn)行后，我們可以得到獨(dú)立的Wasm文件。需要說明的是，該參數(shù)仍然在開發(fā)中，可能隨時(shí)發(fā)生規(guī)范和實(shí)現(xiàn)變更。
JavaScript API調(diào)用
從C/C++程序編譯獲得一個(gè).wasm模塊之后，JavaScript開發(fā)人員可以通過如下方式進(jìn)行載入.wasm文件并執(zhí)行。WebAssembly社區(qū)組也有計(jì)劃通過Streams使用streaming以及異步編譯，見代碼10。
最后一行調(diào)用導(dǎo)出的WebAssembly函數(shù)，它反過來調(diào)用我們導(dǎo)入的JS函數(shù)，最終執(zhí)行add(201700, 2)，并且在控制臺(tái)獲得期望的結(jié)果輸出（如圖10所示）。
性能
那么，WebAssembly的真實(shí)性能如何呢？首先我們用一直被用來作為CPU基準(zhǔn)測(cè)試的斐波那契 （Fibonacci）數(shù)列來進(jìn)行對(duì)比，這里使用的是性能較差的遞歸算法，在Node.js v7.2.1環(huán)境下，能夠看到WebAssembly性能優(yōu)勢(shì)越發(fā)明顯（如圖11所示）。
再看看最基本的1000毫秒時(shí)間內(nèi)，求和計(jì)算的運(yùn)算量統(tǒng)計(jì)，在同一臺(tái)計(jì)算機(jī)的Firefox 50.1.0版本的運(yùn)算結(jié)果如圖12所示。
盡管重復(fù)測(cè)試時(shí)結(jié)果不盡相同，重啟瀏覽器并多次測(cè)試取平均值后依然可以看到WebAssembly的運(yùn)算量比JavaScript快了近一個(gè)量級(jí)。
Demo
圖13展示了Angry Bots Demo，它是由WebAssembly項(xiàng)目發(fā)布的一個(gè)Demo，由Unity游戲移植而來。
通過如下方式可以體驗(yàn)WebAssembly在瀏覽器中的強(qiáng)大性能。即便Google Chrome較新的穩(wěn)定版也已支持WebAssembly，還是推薦使用canary版及Firefox的nightly版進(jìn)行測(cè)試。
1-1. Google Chrome；?
1-2. Mozilla Firefox；?
1-3. Opera；?
1-4. Vivaldi。
2-1. Google Chrome：chrome://flags/#enable-webassembly；?
2-2. Mozilla Firefox：about:config→接受→搜索javascript.options.wasm→設(shè)置為true；?
2-3. Opera：opera://flags/#enable-webassembly；?
2-4. Vivaldi：vivaldi://flags#enable-webassembly。
訪問：http://webassembly.org/demo/。
使用W、A、S、D等鍵實(shí)現(xiàn)移動(dòng)操作，點(diǎn)擊鼠標(biāo)進(jìn)行射擊。該WebAssembly游戲在瀏覽器中運(yùn)行相當(dāng)流暢，媲美原生性能。
除了最新的瀏覽器開始對(duì)WebAssembly逐步支持外，Intel開源技術(shù)中心開發(fā)的Crosswalk項(xiàng)目（https://crosswalk-project.org/）早在2016年11月初的Crosswalk 22穩(wěn)定版（Windows及Android 平臺(tái)）即已加入對(duì)WebAssembly實(shí)驗(yàn)性的支持，開發(fā)者可以使用該版本體驗(yàn)Angry Bots Demo。
開發(fā)者
WebAssembly對(duì)于Web有顯著的性能提升，對(duì)于開發(fā)者尤其是前端或者JavaScript開發(fā)人員而言，并不意味著WebAssembly將會(huì)取代JavaScript（如圖14所示）。
WebAssembly被設(shè)計(jì)為對(duì)JavaScript的補(bǔ)充，而不是替代，是為了提供一種方法來獲得應(yīng)用程序的關(guān)鍵部分接近原生性能。隨著時(shí)間的推移，雖然WebAssembly將允許多種語言（不僅僅是C/C++）被編譯到Web，但是JavaScript的發(fā)展勢(shì)頭不會(huì)因此被削弱，并且仍然將保持Web的單一動(dòng)態(tài)語言。此外，由于WebAssembly構(gòu)建在JavaScript引擎的基礎(chǔ)架構(gòu)上，JavaScript和WebAssembly將在許多場(chǎng)景中配合使用。
那么WebAssembly是不是僅僅面向C/C++開發(fā)者呢？答案依舊是否定的。WebAssembly最初實(shí)現(xiàn)的重點(diǎn)是C/C++，由Mozilla主導(dǎo)開發(fā)的注重高效、安全和并行的Rust也能在2016年末被成功編譯到WebAssembly了，未來還會(huì)繼續(xù)增加其他語言的支持，見代碼11。?
在未來，通過ES6模塊接口與JavaScript集成，Web開發(fā)人員并不需要編寫C++，而是可以直接利用其他人編寫的庫，重用模塊化C++庫可以像使用JavaScript中的modules一樣簡(jiǎn)單。
進(jìn)展
依據(jù)開發(fā)路線圖，2016年10月31日，WebAssembly到達(dá)瀏覽器預(yù)覽的里程碑。Google Chrome V8引擎及Mozilla Firefox SpiderMonkey引擎都已經(jīng)在trunk上支持WebAssembly瀏覽器預(yù)覽。2016年12月下旬，Microsoft Edge瀏覽器使用的JavaScript引擎ChakraCore v1.4.0啟用了WebAssembly瀏覽器預(yù)覽支持。而Webkit JavaScriptCore引擎對(duì)于該支持也在積極進(jìn)行中。
目前，WebAssembly社區(qū)組已經(jīng)有初始（MVP）二進(jìn)制格式發(fā)布候選和JavaScript API在多個(gè)瀏覽器中實(shí)現(xiàn)。作為瀏覽器預(yù)覽期間的一部分，WebAssembly社區(qū)組（WebAssembly Community Group）現(xiàn)在正在征求更廣泛的社區(qū)反饋。社區(qū)組的初步目標(biāo)是瀏覽器預(yù)覽在2017年第一季度結(jié)束，但在瀏覽器預(yù)覽期間的重大發(fā)現(xiàn)可能會(huì)延長(zhǎng)該周期。當(dāng)瀏覽器預(yù)覽結(jié)束時(shí)，社區(qū)組將產(chǎn)生WebAssembly的草案規(guī)范，并且瀏覽器廠商可以開始默認(rèn)提供符合規(guī)范的實(shí)現(xiàn)。預(yù)計(jì)在2017年上半年，四大主流瀏覽器對(duì)原生的WebAssembly支持將到達(dá)穩(wěn)定版。
具體到Google V8引擎的最新進(jìn)展，asm.js代碼將不再通過Turbofan JavaScript編譯器而是編譯到WebAssembly后，在WebAssembly的原生執(zhí)行環(huán)境中執(zhí)行最終的機(jī)器碼。這種改變帶來的好處有，為asm.js將預(yù)先編譯（AOT，Ahead Of Time Compilation）帶到了Chrome，且完全向后兼容。新的WebAssembly編譯渠道重用了一些Turbofan JavaScript編譯器后端部分，因此能夠在少了很多編譯和優(yōu)化消耗的前提下，產(chǎn)生類似的代碼。在Google Chrome中，WebAssembly將很快在Canary版中默認(rèn)啟用，開發(fā)團(tuán)隊(duì)也期望能夠發(fā)布到2017年第一季度末的穩(wěn)定版中。
社區(qū)
包含所有主要瀏覽器廠商代表的W3C Web——Assembly社區(qū)組于2015年4月底成立。該小組的任務(wù)是，在編譯到適用于Web的新的、便攜的、大小和加載時(shí)間高效的格式上，促進(jìn)早期的跨瀏覽器協(xié)作。該社區(qū)組也正在將WebAssembly設(shè)計(jì)為W3C開放標(biāo)準(zhǔn)。目前，除了文中所述主流瀏覽器廠商Mozilla、Google、微軟、及蘋果公司之外，Opera CTO及Intel的8位該領(lǐng)域?qū)＜揖鶇⑴c了該社區(qū)組。當(dāng)然，并不是只有社區(qū)組成員才能參與標(biāo)準(zhǔn)的制定，任何人都可以在https://github.com/WebAssembly做出貢獻(xiàn)。
展望
由于主要的瀏覽器廠商對(duì)WebAssembly支持表現(xiàn)積極，并且都在實(shí)現(xiàn)WebAssembly的各項(xiàng)功能，因此在Web中高性能需求的應(yīng)用例如在線游戲、音樂、視頻流、AR／VR、平臺(tái)模擬、虛擬機(jī)、遠(yuǎn)程桌面、壓縮及加密等都能夠獲得接近于原生的性能。相信WebAssembly將會(huì)開創(chuàng)Web的新時(shí)代。
作者：張敏，Intel開源技術(shù)中心Web團(tuán)隊(duì)軟件技術(shù)經(jīng)理，原Opera Software軟件經(jīng)理，在瀏覽器及Web Runtime領(lǐng)域工作10年，專注于Web及開源技術(shù)。?
總結(jié)
以上是生活随笔為你收集整理的WebAssembly，Web的新时代的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 中国的支付清算体系
- 下一篇： 基于WebStorm, React和An