JavaScript与WebAssembly进行比较

本文由云+社区发表

做者：QQ音乐前端团队

在识别和描述核心元素的过程当中，咱们分享了构建SessionStack时使用的一些经验法则，这是一个轻量级但健壮且高性能的JavaScript应用程序，以帮助用户实时查看和重现其Web应用程序的缺陷。

此次咱们来分析WebAssembly的工做原理，以及在以下几个方面和JavaScript进行比较：加载时间，执行速度，垃圾回收，内存使用状况，平台API访问，调试，多线程和可移植性。

WebAssembly的功能

WebAssembly（又名wasm）是一种高效的，低级别的编程语言。 它让咱们可以使用JavaScript之外的语言（例如C，C ++，Rust或其余）编写程序，而后将其编译成WebAssembly，进而生成一个加载和执行速度很是快的Web应用程序。

加载时间

为了加载JavaScript，浏览器必须加载全部.js文本文件。 WebAssembly在浏览器中加载速度更快，由于只有已编译的wasm文件才经过互联网传输。而且wasm是一种很是简洁的二进制格式的低级汇编语言，文件更小。

执行

目前Wasm 比本地代码执行速度慢20％。这却是一个使人吃惊的结果，不过，这是一种编译到沙盒环境中的格式而且在不少约束条件下运行，以确保它没有安全漏洞或者很难攻防这个漏洞。与真实的本地代码相比，其实速度降低很小。可是，将来它会更快。

更好的是，它与浏览器无关 - 全部主要引擎都增长了对WebAssembly的支持，而且如今提供相似的执行时间。咱们来看看简单看看V8中发生了什么：

V8 Approach: lazy compilation

在左边，咱们有一些JavaScript源代码，包含JavaScript函数。它首先须要进行分析，以便将全部字符串转换为标记并生成抽象语法树（AST）。AST是JavaScript程序逻辑的内存表示。一旦生成这种表示，V8直接转到机器码。通常来讲，只须要遍历树，生成机器代码，便生成了编译好的函数。从这个过程能够看出，这个阶段并无编译速度的优点。 如今，咱们来看看V8管道在下一阶段的功能：

V8管道设计

此次咱们有TurboFan，V8的优化编译器之一。当您的JavaScript应用程序正在运行时，不少代码在V8中运行。TurboFan能够监控运行缓慢的内容，是否存在瓶颈和热点以优化它们。它将它们推送到后端，这是一个优化的JIT，它能够优化那些很是耗cpu的代码。 虽然它解决了上述问题，可是新的问题在于：分析代码并决定优化哪些内容的过程也会消耗CPU。这反过来又意味着更高的电池消耗，特别是在移动设备上。 然而，wasm不同在于，它会被插入工做流程中，以下所示：

内存模型

WebAssembly可信和不可信状态 例如，编译成WebAssembly的C ++程序的内存是连续的内存块，其中没有“漏洞”。有助于提升安全性的wasm的特性之一是执行堆栈与线性内存分离的概念。在一个C ++程序中，你有一个内存堆，你从堆的底部分配，而后从堆顶增涨堆大小。这便产生一个不少恶意软件利用的漏洞：用一个指针就能够在堆栈内存中查找数据从而更改变量，而这些数据本是你不该该访问到的。

WebAssembly采用彻底不一样的模型。执行堆栈与WebAssembly程序自己是分开的，所以您没法在其中修改并更改变量等内容。并且，这些函数使用整数偏移而不是指针。函数指向一个间接函数表。而后这些直接计算的数字跳转到模块内部的函数中。它是以这种方式构建的，以便您能够同时加载多个wasm模块，造成多个索引列表，而且一切正常。 有关JavaScript中内存模型和管理的更多信息，能够查看关于该主题的很是详细的帖子。

垃圾回收

您已经知道JavaScript的内存管理是使用垃圾回收器处理的。

WebAssembly的状况有点不一样。它支持手动管理内存的语言。您能够自定义在WASM上的垃圾回收模块，可是这个比较复杂。

目前，WebAssembly是围绕C ++和RUST用例设计的。因为wasm是很是低级的，所以只有汇编语言上一步的编程语言才易于编译。C可使用普通的malloc，C ++可使用智能指针，Rust使用彻底不一样的模式（彻底不一样的主题）。这些语言不使用GC，所以它们不须要全部复杂的运行时内容来跟踪内存。WebAssembly对他们来讲是天做之合。

另外，这些语言并非100％设计用于调用复杂的JavaScript事物，如DOM。在C ++中编写整个HTML应用程序是没有意义的，由于C ++不是为它设计的。在大多数状况下，当工程师编写C ++或Rust时，他们的目标是WebGL或高度优化的库（例如重数学计算）。

可是，未来WebAssembly将支持不附带GC的语言。

平台API访问

取决于执行JavaScript的运行时，能够经过你的JavaScript应用程序来访问平台相关的API。例如，若是您在浏览器中运行JavaScript，则您有一组Web APIs，Web应用程序能够调用它来控制Web浏览器/设备功能并访问DOM, CSSOM, WebGL, IndexedDB, Web Audio API等。

然而，WebAssembly模块没法访问任何平台API。一切都是由JavaScript调用的。若是您想访问WebAssembly模块中的某些平台特定的API，则必须经过JavaScript调用它。

例如，若是你想console.log，你必须经过JavaScript来调用它，而不是你的C ++代码。这些JavaScript调用的成本有所下降。

这并不老是如此。该规范将在将来为平台API提供wasm，而且您将可以在没有JavaScript的状况下发布您的应用程序。

Source maps

当您精简JavaScript源代码时，您须要一种正确方式调试它。这就须要Source Maps。基本上， Source Maps 是一种将组合/缩小文件映射回未创建状态的方法。当您为生产而构建时，同时缩小和组合您的JavaScript文件，您将生成一个包含原始文件信息的源映射。当您在生成的JavaScript中查询某一行和列号时，能够在返回原始位置的源地图中执行查找。

WebAssembly目前不支持source maps，由于没有规范，但最终会支持（可能很快）。 当您在C ++代码中设置断点时，您将看到C ++代码而不是WebAssembly。

多线程

JavaScript在单个线程上运行。有不少方法能够利用Event Loop并利用异步编程。

JavaScript也使用Web Workers，但他们有一个很是具体的用例 - 基本上，可能阻塞主UI线程的任何CPU密集计算均可以进入到Web Worker中来提升性能。可是，Web Workers没法访问DOM。

WebAssembly目前不支持多线程。可是，这多是将来的事情。Wasm将更接近本地线程（例如C ++样式线程）。拥有“真实”的线程将在浏览器中创造出许多新的机会。固然，这将打开更多滥用可能性的大门。

可移植性

现在，JavaScript几乎能够在任何地方运行，从浏览器到服务器端甚至嵌入式系统。

WebAssembly被设计为安全和便携。就像JavaScript同样。它将运行在支持主机的每一个环境中（例如每一个浏览器）。就像当年的Java的Applets，WebAssembly有相同的可移植性的愿景。

哪些场景更合适使用WA

在WebAssembly的第一个版本中，主要关注CPU占用大的计算（例如处理数学）。想到的最主流的用途是游戏 - 那里有大量的像素操做。您可使用您习惯的OpenGL在C ++ / Rust中编写您的应用程序，并将其编译为wasm。它会在浏览器中运行。 看看这个（在Firefox中运行）

http://s3.amazonaws.com/mozil...。

这是 Unreal engine.。

另外一种使用WebAssembly（性能方面）可能有意义的状况是实现一些库，这是一个CPU密集型工做。例如，一些图像处理。

如前所述，因为大多数处理步骤都是在编译期间提早完成的，所以wasm能够减小移动设备上的电池消耗（取决于引擎）。

未来，即便您实际上没有编写编译代码，您也可使用WASM二进制文件。您能够在NPM中找到开始使用此方法的项目。

对于DOM操做和沉重的平台API使用，使用JavaScript确实颇有意义，由于它不会增长额外的开销，而且具备本地提供的API。

在SessionStack中，咱们不断加强JavaScript的性能，以编写高度优化且高效的代码。咱们的解决方案须要提供超快的性能，由于咱们不能阻碍客户应用的性能。将SessionStack集成到生产Web应用程序或网站后，它会开始记录全部内容：全部DOM更改，用户交互，JavaScript异常，堆栈跟踪，失败的网络请求和调试数据。全部这些都在您的生产环境中进行，而不会影响产品的任何UX和性能。咱们须要大量优化咱们的代码并尽量使其异步。

不只仅是库文件，当在SessionStack中重放用户回话时，咱们会渲染用户浏览器中发生的全部事件，而且咱们必须重构整个状态，容许您在会话时间线中来回跳转。由于没有更好的选择，为了作到这一点，咱们大量使用了JavaScript提供的异步机会。

借助WebAssembly，咱们将可以将一些最繁重的处理和渲染转换为更适合做业的语言，并将数据收集和DOM操做保留为JavaScript。

若是你想尝试下SessionStack，你能够免费开始。有一个免费的计划)，每个月提供1000个会话。

参考:

• https://www.youtube.com/watch...
• https://www.youtube.com/watch...

此文已由腾讯云+社区在各渠道发布

获取更多新鲜技术干货，能够关注咱们腾讯云技术社区-云加社区官方号及知乎机构号