WebAssembly在前端的应用前景

前段时间在做一个音视频直播的项目,遇到一些性能问题团队中有大牛建议使用WebAssembly实现c端的解决方案代码移到js端实现,对于我这个只听过WebAssembly的存在而不知道具体何物的“骨干”倍感汗颜,于是找时间调查了下这个东西的前世今生。

来自MDN的定义:
WebAssembly是一种新的编码方式,可以在现代的网络浏览器中运行 - 它是一种低级的类汇编语言,具有紧凑的二进制格式,可以接近原生的性能运行,并为诸如C / C ++等语言提供一个编译目标,以便它们可以在Web上运行。它也被设计为可以与JavaScript共存,允许两者一起工作。

翻译成大白话就是利用WebAssembly可以实现c/c+或其他语言编写浏览器可以执行的代码,继而利用c/c++语言的高效性能来提升浏览器的性能。

披着华丽外衣诞生
对于做过多年前端开发的人,相信近几年随着前端业务爆炸般的增长随之而来也出现很多想新的技术,前端已经不再是HTML+JS+CSS的世界了,
特别是js语言语法太灵活导致开发大型 Web 项目困难;性能不能满足一些场景的需要;

相比较TypeScript的设计目的应该是解决JavaScript的“痛点”:弱类型和没有命名空间,导致很难模块化,不适合开发大型程序。另外它还提供了一些语法糖来帮助大家更方便地实践面向对象的编程,但是ts最终还是要编译成js去执行,WebAssembly的出世是从本质上解决这一问题,WebAssembly提供了浏览器直接运行c/c++编译好的文件执行。

另外相较于v8引擎从node端解决了js单线程xiaolv问题,但是在浏览器端依然是瓶颈WebAssembly可以实现c/c++对多线程的操作继而大大提高浏览器效率。

还有js的自动垃圾回收机制不小心就会导致内存溢出性能低下的问题,c/c++语言具备内存管理机制,手动处理垃圾回收。

综上:WebAssembly具备以下优势

文件加载 - WebAssembly 文件体积更小,所以下载速度更快。

解析 - 解码 WebAssembly 比解析 JavaScript 要快

编译和优化 - 编译和优化所需的时间较少,因为在将文件推送到服务器之前已经进行了更多优化,JavaScript 需要为动态类型多次编译代码

重新优化 - WebAssembly 代码不需要重新优化,因为编译器有足够的信息可以在第一次运行时获得正确的代码

执行 - 执行可以更快,WebAssembly 指令更接近机器码

垃圾回收 - 目前 WebAssembly 不直接支持垃圾回收,垃圾回收都是手动控制的,所以比自动垃圾回收效率更高。

Google、MicroSoft、Apple 联合起来,一同共建 WebAssembly 生态。而且目前部分浏览器上已经实现WebAssembly实验版本;

现实的骨干
首先需要搭建 Emscripten 环境。Emscripten 被用于将 CPP 文件转换成为 WASM 字节码文件。
常规的搭建流程十分繁琐:

1、确保安装 CMake、Xcode、Python 2.7.x
2、git clone https://github.com/juj/emsdk.git
3、./emsdk install --build=Release sdk-incoming-64bit binaryen-master-64bit

集成vs ide环境,这一步相当麻烦虽然最后勉强实现但是中间过程不堪回首,也是到了这一步调查终结了,

顺带说下利用docker资源会更快搭建环境的。
。。。。。。。。
。。。。。。。。
。。。。。。。。

团队中有大牛已经实现编译好.wasm文件了而且目前 Webpack4 已经支持 import wasm 文件的形式调用 wasm 文件。

没吃过猪肉看次猪走路花费时间也值了。

发布了69 篇原创文章 · 获赞 6 · 访问量 1885

猜你喜欢

转载自blog.csdn.net/weixin_40073115/article/details/103766722