How Javascript works (Javascript工做原理) (六) WebAssembly 对比 JavaScript 及其使用场景

我的总结:

1.webassembly简介:WebAssembly是一种用于开发网络应用的高效，底层的字节码。容许在网络应用中使用除JavaScript的语言之外的语言(好比C，C++，Rust及其余)来编写应用程序，而后编译成(提前)WebAssembly。

 

 

这是 JavaScript 工做原理的第六章。

如今，咱们将会剖析 WebAssembly 的工做原理，而最重要的是它和 JavaScript 在性能方面的比对：加载时间，执行速度，垃圾回收，内存使用，平台 API 访问，调试，多线程以及可移植性。

咱们构建网页程序的方式正面临着改革－这只是个开始而咱们对于网络应用的思考方式正在发生改变。

首先，认识下 WebAssembly 吧

WebAssembly（又称 wasm） 是一种用于开发网络应用的高效，底层的字节码。

WASM 让你在其中使用除 JavaScript 的语言之外的语言（好比 C, C++, Rust 及其它）来编写应用程序，而后编译成（提前） WebAssembly。

构建出来的网络应用加载和运行速度都会很是快。

加载时间

为了加载 JavaScript，浏览器必须加载全部文本格式的 js 文件。

浏览器会更加快速地加载 WebAssembly，由于 WebAssembly 只会传输已经编译好的 wasm 文件。并且 wasm 是底层的类汇编语言，具备很是紧凑的二进制格式。

执行速度

现在 Wasm 运行速度只比原生代码慢 20%。不管如何，这是一个使人惊喜的结果。它是这样的一种格式，会被编译进沙箱环境中且在大量的约束条件下运行以保证没有任何安全漏洞或者使之强化。和真正的原生代码比较，执行速度的降低微乎其微。另外，将来将会更加快速。

更让人高兴的是，它具有很好的浏览器兼容特性－全部主流浏览器引擎都支持 WebAssembly 且运行速度相关无几。

为了理解和 JavaScript 对比，WebAssembly 的执行速度有多快，你应该首先阅读以前的 JavaScript 引擎工做原理的文章。

让咱们快速浏览下 V8 的运行机制：

V8 技术：懒编译

左边是 JavaScript 源码，包含 JavaScript 函数。首先，源码先把字符串转换为记号以便于解析，以后生成一个语法抽象树。

语法抽象树是 JavaScript 程序逻辑在内存中的图示。一旦生成图示，V8 直接进入到机器码阶段。你基本上是遍历树，生成机器码而后得到编译后的函数。这里没有任何真正的尝试来加速这一过程。

如今，让咱们看一下下一阶段 V8 管道的工做内容：

 

 

V8 管道设计

如今，咱们拥有 TurboFan ，它是 V8 的优化编译程序之一。当 JavaScript 运行的时候，大量的代码是在 V8 内部运行的。TurboFan 监视运行得慢的代码，引发性能瓶颈的地方及热点（内存使用太高的地方）以便优化它们。它把以上监视获得的代码推向后端即优化过的即时编译器，该编译器把消耗大量 CPU 资源的函数转换为性能更优的代码。

它解决了性能的问题，可是缺点便是分析代码及辨别哪些代码须要优化的过程也是会消耗 CPU 资源的。这也即意味着更多的耗电量，特别是在手机设备。

可是，wasm 并不须要以上的所有步骤－它以下所示插入到执行过程当中：

V8 管道设计 + WASM

wasm 在编译阶段就已经经过了代码优化。总之，解析也不须要了。你拥有优化后的二进制代码能够直接插入到后端（即时编译器）并生成机器码。编译器在前端已经完成了全部的代码优化工做。

因为跳过了编译过程当中的很多步骤，这使得 wasm 的执行更加高效。

内存模型

WebAssembly 可信和不可信状态

举个栗子，一个 C++ 的程序的内存被编译为 WebAssembly，它是整段连续的没有空洞的内存块。wasam 中有一个能够用来提高代码安全性的功能即执行堆栈和线性内存隔离的概念。在 C++ 程序中，你有一块动态内存区，你从其底部分配得到内存堆栈，而后从其顶部得到内存来增长内存堆栈的大小。你能够得到一个指针而后在堆栈内存中遍历以操做你不该该接触到的变量。

这是大多数可疑软件能够利用的漏洞。

WebAssembly 采用了彻底不一样的内存模型。执行堆栈和 WebAssembly 程序自己是隔离开来的，因此你没法从里面进行修改和改变诸如变量值的情形。一样地，函数使用整数偏移而不是指针。函数指向一个间接函数表。以后，这些直接的计算出的数字进入模块中的函数。它就是这样运行的，这样你就能够同时引入多个 wasm 模块，偏移全部索引且每一个模块都运行良好。

更多关于 JavaScript 内存模型和管理的文章详见这里。

内存垃圾回收

你已经知晓 JavaScript 的内存管理是由内存垃圾回收器处理的。

WebAssembly 的状况有点不太同样。它支持手动操做内存的语言。你也能够在 wasm 模块中内置内存垃圾回收器，但这是一项复杂的任务。

目前，WebAssembly 是专门围绕 C++ 和 RUST 的使用场景设计的。因为 wasm 是很是底层的语言，这意味着只比汇编语言高一级的编程语言会容易被编译成 WebAssembly。C 语言可使用 malloc，C++ 可使用智能指针，Rust 使用彻底不一样的模式（一个彻底不一样的话题）。这些语言没有使用内存垃圾回收器，因此他们不须要全部复杂运行时的东西来追踪内存。WebAssembly 天然就很适合于这些语言。

另外，这些语言并不可以 100% 地应用于复杂的 JavaScript 使用场景好比监听 DOM 变化 。用 C++ 来写整个的 HTML 程序是毫无心义的由于 C++ 并非为此而设计的。大多数状况下，工程师用使用 C++ 或 Rust 来编写 WebGL 或者高度优化的库（好比大量的数学运算）。

然而，未来 WebAssembly 将会支持不带内存垃圾回功能的的语言。

平台接口访问

依赖于执行 JavaScript 的运行时环境，能够经过 JavaScript 程序来直接访问这些平台所暴露出的指定接口。好比，当你在浏览器中运行 JavaScript，网络应用能够调用一系列的网页接口来控制浏览器／设备的功能且访问 DOM，CSSOM，WebGL，IndexedDB，Web Audio API 等等。

然而，WebAssembly 模块不可以访问任何平台的接口。全部的这一切都得由 JavaScript 来进行协调。若是你想在 WebAssembly 模块内访问一些指定平台的接口，你必须得经过 JavaScript 来进行调用。

举个栗子，若是你想要使用 console.log，你就得经过JavaScript 而不是 C++ 代码来进行调用。而这些 JavaScript 调用会产生必定的性能损失。

状况不会一成不变的。规范将会为在将来为 wasm 提供访问指定平台的接口，这样你就能够不用在程序中内置 JavaScript。

源码映射

当压缩了 JavaScript 代码的时候，你须要有合适的方法来进行调试。

这时候源码映射就派上用场了。

大致上，源码映射就是把合并／压缩了的文件映射到未构建状态的一种方式。当为生产环境进行代码构建的时候，与压缩和合并 JavaScript 一块儿，会生成源码映射用来保存原始文件信息。当你想在生成的 JavaScript 代码中查询特定的行和列的代码的时候，能够在源码映射中进行查找以得到代码的原始位置。

因为没有规范定义源码映射，因此目前 WebAssembly 并不支持，但最终会有的（可能快了）。

当在 C++ 代码中设置了断点，就会看到 C++ 代码而不是 WebAssembly。至少，这是 WebAssembly 源码映射的目标吧。

多线程

JavaScript 是单线程的。有不少方法来利用事件循环和使用在以前的文章中有提到的异步编程。

JavaScript 也使用 Web Workers 可是只有在极其特殊的状况下－大致上，能够把任何可能阻塞 UI 主线程的密集的 CPU 计算移交给 Web Worker 执行以得到更好的性能。可是，Web Worker 不可以访问 DOM。

目前 WebAssembly 不支持多线程。可是，这有多是接下来 WebAssembly 要实现的。Wasm 将会接近实现原生的线程（好比，C++ 风格的线程）。拥有真正的线程将会在浏览器中创造出不少新的机遇。而且固然，会增长滥用的可能性。

 

可移植性

如今 JavaScript 几乎能够运行于任意的地方，从浏览器到服务端甚至在嵌入式系统中。

WebAssembly 设计旨在安全性和可移植性。正如 JavaScript 那样。它将会在任何支持 wasm 的环境（好比每一个浏览器）中运行。

WebAssembly 拥有和早年 Java 使用 Applets 来实现可移植性的一样的目标。

WebAssembly 使用场景

WebAssembly 的最第一版本主要是为了解决大量计算密集型的计算的（好比处理数学问题）。最为主流的使用场景即游戏－处理大量的像素。

你可使用你熟悉的 OpenGL 绑定来编写 C++/Rust 程序，而后编译成 wasm。以后，它就能够在浏览器中运行。

浏览下（在火孤中运行）－http://s3.amazonaws.com/mozilla-games/tmp/2017-02-21-SunTemple/SunTemple.html。这是运行于Unreal engine（这是一个能够用来开发虚拟现实的开发套件）中的。

另外一个合理使用 WebAssembly （高性能）的状况即实现一些处理计算密集型的库。好比，一些图形操做。

正如以前所提到的，wasm 能够有效减小移动设备的电力损耗（依赖于引擎），这是因为大多数的步骤已经在编译阶段提早处理完成。

将来，你能够直接使用 WASM 二进制库即便你没有编写编译成它的代码。你能够在 NPM 上面找到一些开始使用这项技术的项目。

针对操做 DOM 和频繁使用平台接口的状况 ，使用 JavaScript 会更加合理，由于它不会产生额外的性能开销且它原生支持各类接口。

在 SessionStack 咱们一直致力于持续提高 JavaScript 的性能以编写高质量和高效的代码。咱们的解决方案必须拥有闪电般的性能由于咱们不可以影响用户程序的性能。一旦把 SessionStack 整合进网络应用或网站的生产环境，它会开始记录全部的一切：全部的 DOM 变化，用户交互，JavaScript 异常，堆栈追踪，失败的网络请求和调试数据。全部的这一切都是在生产环境中产生且没有影响到产品的任何交互和性能。咱们必须极大地优化咱们的代码而且尽量地让它异步执行。

咱们不只仅有库，还有其它功能！当你在 SessionStack 中重放用户会话，咱们必须渲染问题产生时用户的浏览器所发生的一切，并且咱们必须重构整个状态，容许你在会话时间线上来回跳转。为了使之成为可能，咱们大量地使用异步操做，由于 JavaScript 中没有比这更好的替代选择了。

有了 WebAssembly，咱们就能够把大量的数据计算和渲染的工做移交给更加合适的语言来进行处理而把数据收集和 DOM 操做交给 JavaScript 进行处理。

番外篇

打开 webassembly 官网就能够在头部醒目地看到显示它兼容的浏览器。分别是火孤，Chrome，Safari，IE Edge。点开 learn more 能够查看到这是于 2017／2／28 达成一致推出浏览器预览版。如今各项工做开始进入实施阶段了，相信在将来的某个时刻就能够在生产环境使用它了。官网上面介绍了一个 JavaScript 的子集 asm.js。另外，这里有一个 WebAssembly 和 JavaScript 进行性能比对的测试网站。