Qking：跨端 JS 引擎的深度探索与突破

1. Qking：跨端 JS 引擎的深度探索与突破胥加成 (花名:平逸) 阿里巴巴无线开发专家

2. 目录 01 背景介绍 02 性能优化 03 功能增强 04 质量保障

3.

4. 背景介绍跨端JS引擎的前世今生

5. JS引擎的跨端应用场景前端开发 01 01 跨端UI框架 02 客户端开发 02 03 小程序逻辑需要动态性的各类场景

6. JS引擎的跨端应用场景前端开发 01 01 跨端UI框架启动速度快运行性能高 02 内存占用小小程序 JS可调试包体积小客户端开发 02 可调试 03 逻辑需要动态性的各类场景

7. JS引擎的跨端应用场景前端开发 01 01 谁能全部满足？客户端开发 02 03 跨端UI框架 02 小程序逻辑需要动态性的各类场景

8. JS引擎的选型常见方案 WebView V8 JSC JerryScript DukeTape • 资源开销大 • 资源开销大 • 性能较差 • 启动慢 • 启动慢 • JS 标准支持不全 • 使用不方便 • 双端一致性差 • 无法调试 JS • 一致性差 • 稳定性问题严重 • 无法调试JS

9. JS引擎的选型新生代引擎 QuickJS • 启动性能不够好 • 缺失调试功能 • 堆栈还原无法输出列号导致 JS minify 文件的线上报错无法定位 Hermes • ES 标准支持太低 • 字节码预编译优化和版本绑定，难以进行网络下发 • 缺少线上的 eval 支持

10. JS引擎的选型对比项目 V8 JSC JerryScript DukeTape WebView Hermes QuickJS 包体积 C A A B A 内存占用 C A C B B 启动性能 B C C A+ B- 执行性能 A C A B B JS 标准支持 A C B C A 双端一致性 B A C A A 稳定性 C B C B B 使用复杂度 B A C C A JS 调试支持无无有有无

11. 常见方案面临的问题前端业务开发问题客户端框架开发耗费开发时间进行优化性能问题耗费开发时间进行优化靠console.log进行调试浪费时间 JS不可调试更大的polyfill产物更多的适配耗时 ES标准支持不一致引擎JS行为不一致发布上线的风险更大资源占用大引擎不稳定容易crash 更多时间排查问题端上crash问题恶化

12. Qking 基于QuickJS的JS引擎低内存占用支持内存安全性检查高ES标准支持低包大小支持内存泄露检查高可用性质量毫秒级别启动性能支持Chrome调试性能执行性能提升 20%+ 功能支持JS minify后行列号还原

13. Qking 提升交付效率 & 质量前端业务开发特性客户端框架开发更好的性能表现更少时间用在优化上字节码预编译优化启动性能更好的性能表现更少时间用在优化上开发效率和线上问题排查效率都更高原生Chrome Debug Protocol调试支持更小的前端产物更少的适配用时高ES标准支持双端行为一致更稳定的框架低资源占用内存Checker检查稳定性有保障问题排查有手段

14. 性能优化

15. 性能的构成链路长，耗时长 AST分析 Token流分析 Bytecode生成 JS文件产物下载引擎创建时间轴 JS parse JS Execute Bytecode优化

16. 性能的构成 WebAssembly: bytecode生成被前置到离线流程里 Token流分析 AST分析 WASM Bytecode生成 Bytecode优化产物下载引擎创建时间轴 Wasm Execute

17. 性能的构成 1. 线上统计部分复杂业务的 Parse : Execute 耗时达到 3 : 1 2. QuickJS 的 parse 本身相对V8慢优化手段 • V8: bytecode cache • Hermes: 预编译bytecode • QuickJS: 预编译bytecode 缺陷 JS文件 • Bytecode 无法在引擎版本间兼容，就很难发布作为CDN的产物产物下载引擎创建 JS parse JS Execute • V8: 产物大小膨胀 • Hermes 阉割掉了在线 eval 的支持 • 没有利用离线parse更充裕的分析时间时间轴

18. 二进制预编译优化 • 实现了版本间字节码兼容 • 保留了原有 QuickJS 的在线 eval 支持 • 利用离线 parse 更充裕的分析时间提升字节码质量字节码分析优化 JS文件优化产物大小毫秒级解码预编译离线编译优化执行性能产物下载引擎创建解码时间轴 JS Execute 首屏时间大幅提升

19. 二进制预编译优化版本兼容的方案版本1产物编译 & 运行版本1引擎版本2产物运行编译 & 运行版本2引擎 • 字节码变动频率相对很低 • 保持运行时向前兼容只需要保持对老字节码的支持，代码膨胀较少

20. 二进制预编译优化版本兼容的方案 • Dispatch table切换 • 极低额外开销 1%

21. 二进制预编译优化字节码优化的思路 Token Parse Emit OPCode 优化后窥孔优化1 Token Parse Token Parse Emit OPCode Emit OPCode 窥孔优化1 窥孔优化1 Optimizer 窥孔优化2 QuickJS原版流程问题: 窥孔优化2 在线Parse不变保证速度 • 窥孔优化可优化的 case 不够泛化 (基于栈的字节码数据关系是隐含的) • 为了保障 parse 速度，不能做太复杂的分析窥孔优化2 离线 Parse 增加 Optimizer流程最大化优化

22. 功能: 1. 控制流分析 1. 数据溢出分析优化后 2. Deadcode删除 2. 数据流分析 1. 指令合并 2. 指令改写 3. 常量传播 3. 可视化控制流分析数据流分析指令数量减少

23. 二进制预编译优化得与失牺牲获得锁死JS引擎首屏性能提升一倍对产物发布链路有一定依赖执行性能提升10~20% 额外的功能优势

24. 其他优化手段内存分配池化 & 字符串Binding优化利用JS频繁分配释放 & QuickJS 的单线程设计，进行池化分配，减少 malloc / free 次数字符串内容分配池 String类数据结构共享指针直接引用上层框架 Qking 和JS引擎通过共享字符串结构和常量字符串表减少跨语言拷贝的开销系统malloc / free • 字符串的拷贝是JS binding中的主要内存 & 性能开销之一

25. 性能对比执行性能对比测试项目 QuickJS Qking Hermes V8 JIT V8 NOJIT JSC JIT JSC NOJIT cripto 153.772 126.4 91.904 4.3 160.64 4.7 84 deltablue earley- boyer navier- strokes raytrace 11.139 9.95 8.009 0.6 6.5 0.6 8.5 181.903 146.9 134.051 8.5 77.84 4.7 107.9 117.27 88.1 90.4 5.4 133.605 6.8 79.68 101.018 76.2 62.713 2.9 32.588 1.6 45.1 regexp 449.265 382.2 251.02 15.996 34 18.5 244.4 richards2 5.505 5 3.558 0.12 3.9 0.25 3.83 splay 4.951 2.26 2.266 0.31 1.535 0.18 2.34

26. 性能对比启动性能对比测试项目 QuickJS Qking (JS) 引擎启动 + Parse耗时 PC 62 40 2.5 引擎启动 + Parse耗时 Android低端机 241.6 160.2 8.4 • 以一个270KB的 JS 业务case为例 Qking Hermes (字节码) V8 JSC 2.6 17 18.2 - - 71.3

27. 性能对比内存对比 • 测试项目 QuickJS Qking 分配次数 242394 138913 (-40%) 分配量 18MB 13MB (-27%) 内存占用量 9.3MB 8.1MB (-13%) 以一个线上 JS 业务case为例

28. 功能增强

29. 调试功能传统方案的调试功能实现 V8 JSC • 比较难运行在IOS上 • 调试协议非chrome • 全功能的调试器代码较 • IOS上系统提供的JSC不多，包大小大包含debugger

30. 调试功能传统方案的调试功能实现: 虚拟环境上层跨端框架 JS Binding 注入 RPC • 维护投入多 • 和真实引擎环境有差异 • 不能在问题现场连入虚拟环境JS Binding 注入底层JS引擎 Node/Web虚拟环境运行时调试 WebSocket 调试器

31. 调试功能传统方案的调试功能实现: 替换引擎上层跨端框架 JS Binding 注入底层JS引擎(JSC) • 维护投入多 • 和真实引擎环境有差异 • 前端开发换包麻烦上层跨端框架 JS Binding 注入底层JS引擎(支持调试的引擎) 线上包调试专用包

32. 调试功能原生调试 vs 虚拟调试项目原生调试虚拟调试/专用包维护成本一次性投入，小持续投入，大可靠性非常高容易出现和真实环境不一致架构复杂性低高内存dump 和真实场景占用一致不一致线上问题现场可以接入调试无法接入，现场丢失正确好用的调试能降低成本，而错误的调试一定会大幅增加成本

33. 调试功能难点 & 问题 • • 需要修改 QuickJS 内部的实现，提部分非核心的CDP的功能无法实现，供一套Debug用的API出来比如代码自动提示 (需要无副作用的和CDP协议对齐需要大量的JSON协执行环境，较难实现) 议处理 & 类型转换 • • 断点的实现需要实现字节码OP offset 和行列号之间的双向映射能力，原生 QuickJS 只有行号的还原，没有列号也没有行列到offset的映射。

34. 预编译二进制行列号映射支持 QuickJS 没有列号映射原因: 1. 影响parse速度 2. 导致产生的bytecode映射 mapping过大 Qking的预编译二进制: 1. 离线parse可以不影响线上性能 2. 映射mapping可以抽离单独的文件发布预编译天生适合解决此问题

35. 预编译二进制行列号映射支持 QuickJS 仅行号支持 Token Parse Bytecode Emit OP_add OP_linenum 1 OP_get_field Bytecode Opt1 OP_add OP_get_field Bytecode Opt2 bytecode 行号映射 Linenum 信息收集 Qking 在线流程: 和 QuickJS 原版保持一致 Token Parse Bytecode Emit Bytecode Opt1 Bytecode Opt2 bytecode 行号映射

36. 预编译二进制行列号映射支持 QuickJS 仅行号支持 Token Parse Bytecode Emit Bytecode Opt1 Bytecode Opt2 行号映射 Qking 离线流程 Token Parse bytecode Bytecode Emit OP_add OP_linenum 1 2 OP_get_field Bytecode Opt1 Bytecode Opt2 OP_add OP_get_field OP_linenum增加列号参数 Parse期间分析并发射列号收集成单独的mapping文件减少产物大小二进制文件行列号映射文件

37. Debugger线程异步线程修改 debug 标记位 JS线程 JS引擎执行中发送CDP事件接收CDP指令 Debugger接入事件 JS引擎断点拦截模式 • console eval代码 • 设置断点 • 其他 Debug任务

38. 调试功能效果

39. 预编译二进制原生 JS 功能上的一些缺陷问题解决方案 JS文件有线上损坏的问题 (由于文件或网络的原因被截断) 二进制里增加checksum进行自校验 QuickJS 没有列号映射影响 JS minify 文件的报错监控改造离线的parser 在预编译二进制里支持列号映射

40. 预编译二进制 • 功能 JS文件 (QuickJS) Hermes 二进制 QuickJS 原版二进制 Qking 预编译二进制版本间兼容性无兼容问题不支持不支持支持搭建场景文件拼接支持不支持不支持支持行列号映射只支持行号支持只支持行号支持额外 Resource 打包不支持不支持不支持支持文件自校验不支持支持不支持支持预编译二进制的功能集是原生 JS 的超集

41. 预编译二进制和QuickJS 原版bytecode对比 QuickJS bytecode Strings 预编译二进制 Header • 版本号 magic number等 Checksum • 自校验功能 • 类似原版bytecode格式，存储 Strings function的方法体 Object Object Resource Sections • 额外Resource打包 Meta Section • 携带meta信息可继续扩展

42. 质量保障

43. 质量保障跨端 JS 引擎的常见问题问题建议需求内存泄露，内存占用高 App不要使用全局的JS 引擎，从业务维度多实例隔离。确保业务页面退出可以释放干净。 JS 引擎的创建销毁足够轻量保障对引擎的API的正确使用，防止泄露/野指针出现 API设计本身不容易出错使用出错的时候可排查定位 JS引擎内野指针造成 crash

44. 质量保障跨端 JS 引擎的常见问题 JSC V8 相对更重容易出错 API 设计不易出错 JerryScript QuickJS 需求轻量 JS 引擎的创建销毁足够轻量引用计数风格API 非常容易出错 API设计本身不容易出错使用出错的时候可排查定位

45. 质量保障跨端 JS 引擎的常见问题 1. 可能立刻crash 2. 可能不crash 3. 可能在很久之后不相关的函数里crash 多 Free 一次 Crash! Runtime释放时间轴少 Free 一次相关联的全部 JS 对象一直泄露到引擎释放为止 Runtime释放时间轴

46. 质量保障现实情况墨菲定律: 会出错的事总会出错问题的特点: 难以定位，出现具有随机性令人头痛的线上问题

47. LeakChecker 防止泄露操作堆栈记录: +1 hello.c:32 JS_NewObject 遍历未释放的对象，报告泄露根源 Leak at hello.c:32: ref count: 1 JS_FreeRuntime 时间轴效果泄露问题只知道发生了，不知道为什么泄露问题一定可以被发现 & 定位

48. PointerChecker 防止野指针 TAG Object TAG Object 操作堆栈记录: +1 hello.c:32 操作堆栈记录: -1 hello.c:42 JS_NewObject JS_FreeValue TAG Object 报告操作记录并abort: +1 at hello.c:32 -1 at hello.c:42 Use Value 时间轴效果问题指针的使用不一定会被发现有问题的使用一定会被发现并且报告出错的位置

49. Checker使用效果 • 发现了大批线上 Binding 代码的错误使用 case • 保障了 Qking 的上层框架在2w行 DOM binding代码中没有线上问题的产生 • 大幅提高了开发期间写 binding 的开发效率

50. 感谢大家观看

51. 扫码回复「D2」获取第十七届 D2 演讲 PDF 材料后续也将推送 D2 会后技术文章，敬请关注！！