记一次完整 C++ 项目编译成 WebAssembly 的实践-阿里云开发者社区

开发者社区> 新零售淘系技术> 正文

记一次完整 C++ 项目编译成 WebAssembly 的实践

简介: 有 2W+ 行代码,一篇通用的技术方案

image.png
作者| 张翰(门柳)
出品|阿里巴巴新零售淘系技术部

本文知识点提炼:
1、把复杂的 C++ 框架编译成 WebAssembly。
2、在 wasm 模块里调用 DOM API !
3、在 js 和 wasm 之间传递复杂数据结构。
4、对 WebAssembly 技术发展的期待。

上一篇文章《基础为零?如何将 C++ 编译成 WebAssembly》里介绍了怎么把简单的 C++ demo 编译成 WebAssembly,但这是远远不够的。正好手头在写一个 C++ 的项目,功能独立完整也足够复杂(有 2W+ 行代码),就顺便编译成了 WebAssembly,未必是一个合适的使用场景,主要是为了学习这项技术,亲身体验一下过程中遇到的问题。

项目背景

我现在在用 C++ 写一个原生的响应式框架,定位和前端框架差不多,但是用 C++ 来实现,可以有更好的性能,也方便对接各种原生渲染引擎和各种语言。上层开发者仍然以 JS 为开发语言,API 和 Web Component 相似,而且可以像小程序和 Vue.js 那样用模板+数据(声明式+响应式)的方式开发原生 UI,框架本身就不介绍了,本文的重点是涉及 WebAssembly 的部分。

▐ 为什么要编译成 WebAssembly ?

框架是 C++ 写的,本身的设计是源码集成进各种渲染容器的,跟随原生 SDK 发版,即使是对接浏览器,也是和浏览器内核代码(如 UC 的 U4 内核)打包在一起,但这样就无法运行在独立的浏览器上,功能无法降级。如果说把 C++ 代码编译成 WebAssembly 的话,那框架就可以从远程加载了再运行,相当于 C++ 的框架也有了动态化的能力。

简单来讲,现在这个 C++ 框架已经能运行在各种原生渲染引擎之上了,我想保持同一份 C++ 源码,让它能运行在干净的浏览器中。

这条链路应该只会用于降级的场景,重点是验证链路能不能跑通,性能倒不是我最关注的问题。

需求分析

▐ 要实现的目标

首先细化一下要实现的目标,下面是一段使用响应式框架 API 开发的代码,它可以运行在原生渲染引擎上,目标是让这段代码能运行在干净的浏览器里:

// 1. 自定义一个组件
class HelloWorld extends ReactiveElement { /* ... */ }
// 2. 向环境中注册组件,给定一个名称
customElements.define('hello-world', HelloWorld)
// 3. 定义组件的模板
customElements.defineTemplate(HelloWorld, {
  type: 'h1',
  // 添加数据绑定,表示 h1 的 innerText 是由表达式 message 计算出来的
  innerText: { '@binding': '`Say: ${message}`' }
})
// 4. 创建组件,传递初始数据
const app = new HelloWorld({ message: 'Hi~' })
// 5. 把组件挂载到 #root
customElements.mount('#root', app)
// 6. 更新组件的数据,会自动触发 UI 的更新
app.setState({
  message: "What's up!"
})

这段代码是一个完整的例子, 1, 2, 4 是 Web Component 的标准写法(用 ReactiveElement 代替 HTMLElement),浏览器已经支持,5 是用于挂载节点的语法糖, 3 和 6 是新增的 API,用于定义组件的模板和传递数据。方案算是对 Web Component 的增强,加入了模板和数据绑定的能力,在真实场景里模板不会是手写的,而是由小程序、Vue.js 所定义的模板语法编译而来。

看起来用 JS 写个 polyfill 就可以搞定。但是模板的运算和数据绑定怎么实现?里面是可以包含循环、分支和表达式的,前端框架的做法是把它编译成 js 代码,如果写 polyfill,很可能又写出了一个前端框架,或者基于现有前端框架做封装,但是这样就和原生框架的行为不一致了。

▐ 遇到的问题

想用响应式框架跑通上面的例子,就是要实现这么一个调用链路:

demo.js <-----> [响应式框架] <-----> DOM API

在原生框架中,ReactiveElement class 和 customElements 上的接口都是由 C++ 实现的,类似于 DOM API,有 ES6 的类,也有普通函数,接受的参数有 class(Function),String 和 Object 等各种类型。然而 wasm 目前只可以 import 和 export C 语言函数风格的 API,而且参数只有四种数据类型(i32, i64, f32, f64),都是数字,可以理解为赤裸裸的二进制编码,没法直接传递复杂的类型和数据结构。所以在浏览器中这些高级类型的 API 必须靠 JS 来封装,中间还需要一个机制实现跨语言转换复杂的数据结构。

WebAssembly 是一种编译目标,虽然运行时是 wasm 和 JS 之间互相调用,但是写代码的时候感知到的是 C++ 和 JS 之间的互相调用。文中说的 JS 和 C++ 的调用,实际意思是 JS 和 wasm 模块之间的调用。
另外,如果要实现在浏览器里渲染和更新 UI 的话,就必须要用到 DOM API,众所周知 WebAssembly 调用不了 DOM API,也不是个靠谱的用法。原生框架提供了 C++ 的 ComponentRenderer 抽象类来对接渲染引擎,不同的渲染引擎分别实现这个类然后注入框架,不管靠谱不靠谱,在浏览器里也只能靠 JS 实现这个渲染器了,封装 DOM 操作然后把接口传给 C++ 调用,而且也要传递复杂的数据结构。如果想精确更新某个特定组件节点,还得解决 C++ 组件和 JS 组件一对一 binding 的问题。

总结下来,是两个问题:

  1. 在 C++ 和 JS 之间传递复杂数据结构。(数据通信)
  2. 实现 C++ 和 JS 复杂数据类型的一对一绑定。(类型绑定)

技术方案

▐ 如何编译代码

首先需要确定一下如何把 C++ 文件编译成 wasm 文件,前一篇文章讲提到两种方式,用 Emscripten 会生成 wasm + js 两个文件,可以很好的跑在浏览器和 Node.js 上;用 wasi-sdk 可以编译出独立的 wasm 包,但是想把它运行起来需要运行时给它注入必要的接口。

image.png

我的目标是跑在浏览器里,所以用 Emscripten 来编译,生成一份 “js glue” 文件来辅助运行, 像个奥利奥,有种必须被 js 捏在手里运行的感觉,但是在浏览器里不得不这样。这很可能是浏览器里 WebAssembly 和 JS 需要长期保持的关系…… 有提案说用

image.png

具体怎么编译?参考 Emscripten 官方文档配置一下编译脚本就好了,这里列出响应式框架的其中一部分编译脚本,可供参考。

image.png

使用 wasi-sdk 的编译链路我也在尝试,可以编译出来独立的 wasm 包,但是目前还没把它运行起来,需要在运行时注入响应式框架依赖的渲染接口。

算上上面的 demo 文件,一共有三个文件,大概的执行顺序是 1. 加载框架的 js 文件, 2. 框架 js 文件自动加载并编译 wasm 文件,3. 执行 demo 文件。伪代码如下:

<script src="path/to/wasm-framework.js"></script>
<script>
  initializeWasmAPIs().then(exports => {
    // wasm 初始化完成后,动态插入 demo 的脚本
    const $script = document.createElement('script')
    $script.setAttribute('src', `path/to/demo.js`)
    document.body.appendChild($script)
  })
</script>

▐ 接口的互相调用

明确了打包生成的代码是 js-wasm-js 这种奥利奥格式的,代入上面提到的调用链路里就是这样:

(A)        (B)        (C)        (D)
demo.js <-----> [js <---> wasm <---> js] <-----> DOM API

看起来这个渲染链路是比较长的,但是中括号里的属于框架内部的调用,不被外界感知的。全部展开来,可以分成 A/B/C/D 四个环节的接口调用,其中 (A) 和 (D) 都是 js 和 js 之间的调用,封装 API 而已,没什么难的,关键要搞定 (B) 和 (C) 的调用。

再回过头来看 wasm 在运行时的层次结果,如下图左半部分,demo.js 属于逻辑 JS,运行与响应式框架之上,响应式框架运行与浏览器之上。再把每一层展开,可以看到每层之间的接口调用关系,如下图右半部分所示:

image.png

图中 (A) 透出的接口就是上面 demo.js 用到的接口,主要是一个 ReactiveElement 的 ES6 class 和 customElements 这个对象。 (D) 就是前端很熟悉的 DOM API,不再赘述。中间响应式框架这层把 wasm + js 两个文件画成三层的奥利奥结构,是因为虽然 js 文件只有一个,但是从逻辑上区分它做了两件事情,分别处理 wasm 的输入和输出。

前面提到过 wasm 通过 import/export 的方式实现和外部的接口调用,而且接口只能是普通的函数而且参数只能是数字,分别对应了图中的 (C) 和 (B)。所以运行与 wasm 下方的 js renderer 是负责封装 DOM API,把它转成 wasm 声明的 import 接口 (C),在实例化 wasm 包的时候把接口注入进去。

(C) 接口的详细设计如下图所示,以 _ui 开头的都是响应式框架声明的、需要在运行时注入的接口。

image.png

同理,wasm 导出的接口也是 C 语言函数风格的,想要转成 Web Component 风格的 API 需要在 JS 层做封装,这就是图中 js api wrapper 这一层所做的事,拿到 wasm 导出的接口 (B) 并把它封装成 (A)。

(B) 接口的详细格式如下图所示,以 _ui 开头的都是响应式框架导出的。

image.png

在实际编译的时候,Emscripten 提供了 --pre-js ,--post-js 和 --js-library 等方式注入 JS 代码,具体含义参考其官方文档。我在项目里用 --post-js 打包 api.js 文件实现接口 (B) 到 (A) 的封装,用 --js-library 打包 renderer.js 文件,实现 (D) 到 (C) 的封装。

除了上面提到的接口封装方式以外, Emscripten 还提供了 Embind 和 Web IDL Binder 的方式绑定 JS 接口,原理和上面方法相同,我觉得封装太厚了就没选择使用。

▐ 搞定数据通信

接口调用搞定了,然后还需要搞定传值的问题。wasm 导入和导出的函数参数只能是数字,要传递复杂值,必须借助 WebAssembly.Memory() 实现,它是由宿主环境开辟的内存,交给 wasm 模块来运行,在运行时这块内存可以被 wasm 模块和宿主环境共同管理,这是 wasm 和宿主环境实现大块数据通信的基础。

传递内存 buffer

如下代码创建了一块初始大小为 256 的内存(单位是“页”,每页64KB),并在实例化时传递给 wasm 模块。

const wasmMemory = new WebAssembly.Memory({ initial: 256 })
WebAssembly.instantiate(wasmBinary, {
  env: {
    memory: wasmMemory
  }
})

这块内存就是 wasm 模块运行时使用的内存,可以通过 wasm 指令读取、写入以及 grow,对应到 C++ 源码里就是指针和 new/malloc 之类的操作;同时这块内存又是一个 js 变量,也可以在 js 里读写它的值。
所以 js 和 wasm 通信的过程就是:先把想要传递的数据序列化成 ArrayBuffer,然后把 buffer 写入 Memory 并且把数据的起始位置、数据大小传给 wasm 模块,在 wasm 中根据位置取到这块 buffer,最后把 buffer 反序列化成自己想要的类型。伪代码如下:

// 把想要传递的数据转成 ArrayBuffer (假设是 Uint8Array)
const dataBuffer = encodeDataByJS({ /* my data */ })
// 向 wasm 申请一段内存,由 wasm 代码负责实现并返回内存内存起始地址
const offset = applyMemoryFormWasm(dataBuffer.length)
// 以 unit8 的格式操作 wasm 的内存 (格式应该与 dataBuffer 的格式相同)
const heapUint8 = new Uint8Array(wasmMemory.buffer, offset, dataBuffer.length)
// 把数据写入 wasm 内存
heapUint8.set(dataBuffer)

传递复杂数据结构

仅支持传递 buffer 并不能解决所有问题,总不能在写代码的时候都去手动操作内存吧,而且 JS 的数据类型和 C++ 的数据类型差别很大,传递数字和数组还好一些,在传递复杂数据结构的时候,如何正确的实现数据的序列化和反序列化?

先说一下通用的解法,这是一个跨语言数据结构转换的问题。面对同一块内存,要让不同的语言都能按照同样的格式(或内存布局)来读取这块内存,就得定义一套语言无关的二进制数据格式。这个在业界有挺多方案的,首先有种叫 BSON 的数据格式,就是二进制版本的 JSON,主要用在 MongoDB 数据库里。另外 Google 的 Protocol Buffers 也是做这个事情的,自定义了一套二进制格式,并且提供了多种语言(没有 JS)的序列化、反序列化 API。另外 Flutter 的 MethodChannel 也是自己设计了一套二进制编码格式,用于实现跨语言的接口调用。

但是上面这些方式用在 WebAssembly 里都不太合适,或者说太重太麻烦了,现在 WebAssembly 社区在讨论的 WebAssembly Interface Types 就是要解决这个问题的,借鉴 Web IDL 的思路,有希望定义出一套适用于 wasm 的语言无关的类型标准,但是目前还有很多问题需要解决,如 anyref 和 GC objects 的支持等。

思来想去,针对我这个场景,我最终决定用 JSON 字符串实现数据的序列化,因为比较省事……

image.png

如上图所示,二进制的 Buffer 是可以在 C++ 和 JS 共同访问的,在 JS 里我把想要传递的数据都用 JSON.stringify() 转成字符串,然后用 TextEncoder 把字符串转成 Uint8Array,解码的时候,先用 TextDecoder 把二进制数据转成字符串,然后用 JSON.parse() 转成我想要的数据结构。在 JS 里我全都用浏览器提供的 API 就可以实现序列化和反序列化,不需要自己写太多代码。在 C++ 里,从二进制数据到 std::string 的转换是很简单的,直接构造和取值就行了,而且巧了,在响应式框架里我设计了一套和 JS 类型对等的 C++ 数据结构,实现了类似 JSON.stringify() 和 JSON.parse() 接口,内部的组件模板、数据绑定、组件状态都可以转换成这套数据类型。所以,对我这个框架来说,每一步的序列化反序列化接口都已经存在了,我只要把它们串起来就行了。

使用 JSON 字符串来传递复杂类型仅仅适用于我这个项目,并不是个通用方案,如何高效实现 wasm 数据通信还要具体情况具体分析。

功能的实现

▐ 代码实现

技术方案以及介绍的比较清楚了,具体代码该怎么写就不说太多了,与框架内部的逻辑有关,与 WebAssembly 关系不大。下面就以 setState() 这个接口的伪代码为例,简单捋一下调用流程。

image.png

在 demo.js 里调用到的 ReactiveElement 接口是 js 实现的,如上图最左侧代码, setState() 函数的实现就是把数据转成 buffer 塞到 wasm memory 里面,然后调用响应式框架导出的 _component_set_state() 接口设置组件状态。中间的 wasm 代码是由 C++ 编译而来的。在 C++ 的实现里,根据传入的 buffer 位置和大小初始化成 std::string 然后把字符串解析成状态数据,然后调用 C++ 对象的 SetState() 方法更新状态。

▐ 对接效果

代码编译好之后,准备一个 HTML 页面再启动一个 Web 服务就可以在浏览器里预览 wasm 的例子了。大部分浏览器都已经支持 WebAssembly 了,包括各大 App 里的 webview,下面是一个简单 demo 在微信扫码打开的效果(快看,我把一个 C++ 框架在微信里跑起来了):

image.png

图中 f 函数的计算是在 js 里实现的,点击事件也是在 js 里绑定的。首次渲染时 wasm 框架会生成一份 HTML 字符串塞到根节点的 innerHTML 里(比逐个加节点要快),过程中会绑定点击事件。当用户点击了按钮时,原生事件通过 DOM API 透到 js,js 再传给响应式框架的 wasm 包做处理,然后调用 js 绑定的回调函数,回调函数里调用了 setState() 把新状态传给 wasm 框架,wasm 里计算新的节点信息,期间会调用 js 的 calculate 函数,最后调用 DOM API 更新节点(并不是重新生成 HTML 再替换,而是可以精确更新特定的节点)。

wasm 文件理论上也可以调试,可以自己尝试一下,然后你就知道调试 WebAssembly 是多么坑的一件事了。另外 demo 也不一定非得用 JS 写,可以用其他语言写,然后编译成 wasm,也能够运行在响应式框架之上。

▐ 性能对比

下面到了大家喜闻乐道的性能测试环节。开头我也说了,把这个项目编译成 WebAssembly 并不是为了追求性能,现阶段 js + wasm 的运行链路大家也都看到了,整个链路跑下来性能未必有什么优势,但是并不代表 wasm 的性能差,未来可优化的潜力是比 js 要高得多的。

所以我并没有很认真的测性能…… 现阶段意义不大。下面是我用一个稍复杂的页面(大概 200+节点),在 Node.js v12 环境下渲染生成 HTML 字符串测出来的结果:

image.png

解释一下各个字段。第一列 n 是循环生成 HTML 字符串的次数,第二列和第三列都是使用 wasm 表示使用渲染 HTML 字符串的耗时,它两个的区别是 wasm 代码仅包含了 js api wrapper 和一个几乎为空的 js renderer (参考上文接口的调用链路),因为仅生成 HTML 字符串的话不需要 renderer;而 wasm+js 是包含了 js renderer 代码,这样在渲染过程中就会有比较频繁的 wasm <--> js 调用和传值。最后两列是前面三列数据的比值。

可以看到把 c++ 编译成 wasm,执行时间大概是原版 c++ 的 1.7~1.8 倍,这个基本上比的是执行 wasm 指令和执行原生指令的性能差距,也是符合预期的。而带上 wasm+js 的通信之后,性能变成了 C++ 的 4.4~4.5 倍,所以说大部分性能其实耗在了通信上,而不是指令的运行上。

使用 WebAssembly 调用 DOM API 并不是一个合适的使用场景,和 JS 进行频繁的调用和传值也不是 WebAssembly 的强项,这个测试用例放大了通信开销。

对 WebAssembly 的期待

现在 WebAssembly 虽然还存在很多问题,但它依然是一个很有潜力的技术,在 W3C 有标准化的规范,得到了主流浏览器的一致支持,技术社区也很活跃,大家的关注度也很高。从种种因素来看,它几乎必然是个会被大规模使用的技术,就看在什么时机爆发了。

现在关注 WebAssembly 技术的人,大部分都在思考两个问题:
• 我能用 WebAssembly 做点什么?
• 我能为 WebAssembly 做的什么?

第一个问题是 WebAssembly 的使用场景,但是不能为了用新技术而用新技术,得找到最适合使用 WebAssembly 而且具备不可替代性的场景,目前来看,客户端上用在视频、游戏、AR、AI 等领域比较合适。

第二个问题是促进 WebAssembly 的发展,解决实践中的问题帮助它落地。要实现 WebAssembly 在真实业务场景中落地,还需要继续完善基础设施,我很期待社区能够有人解决下面几个问题:

  1. 在工程层面解决 WebAssembly 研发链路的问题。现在无论是开发、编译还是调试都会遇到很多问题,开发体验和开发效率都比较低。目前我个人觉得比较靠谱的三种开发语言是 C++、Rust 和 AssemblyScript,分别面向不同类型的开发者。
  2. 在平台侧解决 WebAssembly 模块的管理问题。解决 wasm 在真正使用时的加载、分发、依赖管理、复用等问题,要是能构建出 npm 这样丰富的生态就好了。
  3. 在客户端/服务端解决 WebAssembly 独立运行时的问题。能够把丰富的平台原生能力,高效的、标准的透出到 wasm 模块中,并且解决性能、稳定性、安全性等问题。
  4. 性能优化!性能优化!性能优化! 无需多说,性能优化永无止境。

等上面的基础设施建设完成后,可以为 WebAssembly 的落地扫清大部分障碍。

最后结合本文的例子,设想在未来使用 WebAssembly 的更合理的架构:

image.png

左边是目前在浏览器里运行 WebAssembly 的层次结构,业务逻辑 JS 运行与框架之上,wasm 模块要裹上一层 js glue 才可以运行,浏览器是集 JS 脚本引擎、WebAssembly 运行时、渲染引擎与一体的运行环境,平台的原生能力透过浏览器(或 webview)的壳透出到 JS 环境中。这个架构里最关键的是浏览器,集中实现了各种引擎,功能稳定而且标准化,但是也增大了定制和改造的难度,要引入就都得引入。

右边是一个理想的运行 WebAssembly 的层次结构,在最底层的还是平台原生能力,再往上就不是简单的对接浏览器了,而是将 JS 引擎和 WebAssembly 运行时分开,这两个都可以算作脚本引擎,至于渲染引擎,它应该运行与脚本引擎的下方,属于平台原生能力的一部分(图中未画出来)。有了独立的 WebAssembly 运行时,平台原生能力就能够直接以 wasi 的形式透出,开发和运行 wasm 的时候就不再受 JS 的影响,也有助于实现标准化,向上透出的接口是语言无关的,依然可以被 JS 调用,也可以支持其他语言,也支持其他编译好的 WebAssembly 模块。

写在最后

文章主要讲的是我在响应式框架里的使用 WebAssembly 的经验,虽然未必是一个很合适的使用场景,但是大部分技术方案是通用的,给大家做个参考,写得不对的地方欢迎指正。如果有对 WebAssembly 感兴趣的同学欢迎加入淘宝技术部和我一起交流~

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
新零售淘系技术
使用钉钉扫一扫加入圈子
+ 订阅

淘系技术部隶旗下包含淘宝技术、天猫技术、农村淘宝技术、闲鱼、iHome等团队和业务,是一支是具有商业和技术双重基因的螺旋体。 我们致力于成为全球最懂商业的技术创新团队,打造消费者和商家一体化的新零售智能商业平台,创新商业赛道。随着新零售业务的持续探索与快速发展,我们不断吸引用户增长、机器学习、视觉算法、音视频通信、数字媒体、端侧智能等领域全球顶尖专业人才加入,让科技引领面向未来的商业创新和进步。欢迎投递简历至ruoqi.zlj@taobao.com

官方博客
淘系开源,欢迎star哟