WebAssembly完全入门——了解wasm的前世今身

最新推荐文章于 2024-07-26 00:22:37 发布

SH的全栈笔记

最新推荐文章于 2024-07-26 00:22:37 发布

阅读量739

点赞数 3

分类专栏：前端文章标签： webassembly 前端 wasm

本文链接：https://blog.csdn.net/weixin_42667608/article/details/110427246

版权

本文详细介绍了WebAssembly的起源、优势以及在大型项目中的应用，包括AutoCAD和Google Earth。WebAssembly作为JavaScript的补充，提供了更高的性能和更多可能。文章还提供了在Node和React中使用WebAssembly的实战步骤，帮助读者更好地理解和运用这项技术。

摘要由CSDN通过智能技术生成

前言

接触WebAssembly之后，在google上看了很多资料。感觉对WebAssembly的使用、介绍、意义都说的比较模糊和笼统。感觉看了之后收获没有达到预期，要么是文章中的例子自己去实操不能成功，要么就是不知所云、一脸蒙蔽。本着业务催生技术的态度，这边文章就诞生了。前部分主要是对WebAssembly的背景做一些介绍，WebAssembly是怎么出现的，优势在哪儿。如果想直接开始撸代码试试效果，可以直接跳到最后一个板块。

WebAssembly是什么？

定义

首先我们给它下个定义。

WebAssembly 或者 wasm 是一个可移植、体积小、加载快并且兼容 Web 的全新格式

例子

当然，我知道，即使你看了定义也不知道WebAssembly到底是什么东西。废话不多说，我们通过一个简单的例子来看看WebAssembly到底是什么。

上图的左侧是用C++实现的求递归的函数。中间是十六进制的Binary Code。右侧是指令文本。可能有人就问，这跟WebAssembly有个屁的关系？其实，中间的十六进制的Binary Code就是WebAssembly。

编译目标

大家可以看到，其可写性和可读性差到无法想象。那是因为WebAssembly不是用来给各位用手一行一行撸的代码，WebAssembly是一个编译目标。什么是编译目标？当我们写TypeScript的时候，Webpack最后打包生成的JavaScript文件就是编译目标。可能大家已经猜到了，上图的Binary就是左侧的C++代码经过编译器编译之后的结果。

WebAssembly的由来

性能瓶颈

在业务需求越来越复杂的现在，前端的开发逻辑越来越复杂，相应的代码量随之变的越来越多。相应的，整个项目的起步的时间越来越长。在性能不好的电脑上，启动一个前端的项目甚至要花上十多秒。这些其实还好，说明前端越来越受到重视，越来越多的人开始进行前端的开发。

但是除了逻辑复杂、代码量大，还有另一个原因是JavaScript这门语言本身的缺陷，JavaScript没有静态变量类型。这门解释型编程语言的作者Brendan Eich，仓促的创造了这门如今被广泛使用的语言，以至于JavaScript的发展史甚至在某种层面上变成了填坑史。为什么说没有静态类型会降低效率。这会涉及到一些JavaScript引擎的一些知识。

静态变量类型所带来的问题

这是Microsoft Edge浏览器的JavaScript引擎ChakraCore的结构。我们来看一看我们的JavaScript代码在引擎中会经历什么。

JavaScript文件会被下载下来。
然后进入Parser，Parser会把代码转化成AST（抽象语法树）.
然后根据抽象语法树，Bytecode Compiler字节码编译器会生成引擎能够直接阅读、执行的字节码。
字节码进入翻译器，将字节码一行一行的翻译成效率十分高的Machine Code.

在项目运行的过程中，引擎会对执行次数较多的function进行优化，引擎将其代码编译成Machine Code后打包送到顶部的Just-In-Time(JIT) Compiler，下次再执行这个function，就会直接执行编译好的Machine Code。但是由于JavaScript的动态变量，上一秒可能是Array，下一秒就变成了Object。那么上一次引擎所做的优化，就失去了作用，此时又要再一次进行优化。