共计 1446 个字符，预计需要花费 4 分钟才能阅读完成。
基于 Webassembly + QuickJS 的 Web 平安沙箱技术计划，面向 Web 端建设下一代凋谢技术
背景
Web 端侧的凋谢技术长期以来始终在寻找最好的解决方案，从晚期基于 Webview + API 管控 的凋谢模式，到目前基于小程序的重容器的架构计划。或多或少都无奈全面的解决开发者体验的问题，API 凋谢模式无奈做到平安管控，小程序凋谢模式的架构必然会给业务带来孤岛效应。如何给开发者带来更好的研发体验、给商家带来更好的产品体验始终是咱们淘宝凋谢技术前端团队的命题。
通过半年的技术演进和业务落地，咱们自研了一套基于 Webassembly + QuickJS 的架构计划，来解决上述的问题。
指标
三年的小程序模式凋谢根底曾经造成了规模化壁垒，落地新的技术计划必然思考到老本问题，所以本次架构降级的指标能够形容为“面向 Web 端建设下一代 PC 凋谢技术，建设基于 W3C 规范的 Web 技术三方凋谢计划，与小程序、小部件凋谢状态互补，构建电商域的残缺凋谢技术生态”。
思考
端侧凋谢到底解决什么问题，我了解凋谢技术在端侧次要围绕这 2 个点：如何让内部代码平安的可控的执行、用户数据的平安如何保障，做到无端不透；
- 对于第一个点落实到细节是 JavaScript/CSS/HTML 如何执行的问题。我的解法是：JavaScript 运行在 Webassembly+QuickJS 平安容器里，基于 Webassembly 的平安水位保障 JS 执行的隔离和可控；CSS 基于 Shadow DOM + iframe 做到款式隔离。
- 数据安全次要依靠浏览器容器环境对数据做加签验签加密操作，本文章不开展解说；
技术细节
工欲其事必先利器，咱们先对技术底层细节做一个理解
WebAssembly
图起源地址（https://medium.com/jspoint/th…）
这里重点提到 2 个事件：
- WebAssembly 二进制码会通过 Liftoff 生成未优化的 ByteCode，再给到 TurboFan 优化代码编译为机器码
- WebAssembly 和 JavaScript 的编译后端是共享的，WebAssembly 的止境是和架构相干的机器码，这里是一个关键点也是 VM 和 HOST 同步调用的关键点。
WebContainer 架构
实质上咱们会以 App 级别的思维来架构计划（多页面、路由、通信），底层运行时基于 QuickJS，波及到多页面治理、鉴权、内存剖析等等。
Binding 细节
内部代码的 Runtime 会运行到 Quickjs 里，执行环境须要仿真和浏览器环境统一，这个时候波及到 API Binding 设计，在 HOST JavaScript Runtime 定义 W3C 标准，通过 WebAssembly 的内存 Binding 到 Quickjs Runtime 中，当内部代码调用对应办法时，会映射到 HOST 实现，通过平安管控策略再执行到 HOST 环境中。
研发模式
WebContainer 的实质要解决开发者体验问题，做到下层框架无关，所以在平安的水位上咱们不会束缚明天开发者的框架体系。然而咱们须要定义 App Export 的接口。
Benchmark
绝对于纯小程序的通信效率晋升 355 倍，然而受到平安容器的限度 JS 执行绝对于底层 V8 引擎升高到 1%，然而也是足够用于生产环境的。
业务落地
在商家私域场景，咱们曾经在旺铺装修表单落地，目前 ISV 反馈十分不错，业务平台将来会全量替换到新凋谢容器中。
将来
持续基于 WebContainer 能力做下层凋谢体系的建设，解决插件体系。解决启动耗时的问题。技术底层欠缺 Quickjs Debug 能力。
