移动端 JS 引擎哪家强?美国硅谷找......

开发 前端
一般的移动端开发场景中,每次更新应用功能都是通过 Native 语言开发并通过应用市场版本分发来实现的。

[[383972]]

本文转载自微信公众号「卤蛋实验室」,作者卤代烃。转载本文请联系卤蛋实验室公众号。   

在一般的移动端开发场景中,每次更新应用功能都是通过 Native 语言开发并通过应用市场版本分发来实现的。

但是市场瞬息万变,Native 语言在开发效率上存在一定不足,并且从 APP 版本更新 到 应用市场审核发布 再到 用户下载更新,总会存在一定的时间差,这样就导致新的功能无法及时覆盖全量用户。

为了解决这个问题,开发者们一般会在项目里引入一门脚本语言,提速 APP 的研发流程。

在移动端应用比较广泛的脚本语言有 Lua 和 JavaScript,前者在游戏领域用的比较多,后者在应用领域用的比较多。本篇文章主要是想探讨一下移动双端(iOS & Android)的 JavaScript 引擎选型。由于个人水平有限,文章总会有遗漏和不足的地方,还请各位大佬多多指教。

JS 引擎选型要点

JavaScript 作为世界上最热门的脚本语言,有着非常多的引擎实现:有 Apple 御用的 JavaScriptCore,有性能最强劲的 V8,还有最近热度很高的 QuickJS......如何从这些 JS 引擎里选出最适合的?我个人认为要有几个考量:

  • 性能:这个没话说,肯定是越快越好
  • 体积:JS 引擎会增加一定的包体积
  • 内存占用:内存占用越少越好
  • JavaScript 语法支持程度:支持的新语法越多越好
  • 调试的便捷性:是否直接支持 debug?还是需要自己编译实现调试工具链
  • 应用市场平台规范:主要是 iOS 平台,平台禁止应用集成带 JIT 功能的虚拟机

比较麻烦的是,上面的几个点都不是互相独立的:

比如说开启 JIT 的 V8 引擎,性能肯定是最好的,但它引擎体积就很大,内存占用也很高;在包体积上很占优势的 QuickJS,由于没有 JIT 加持,和有 JIT 的引擎比起来平均会有 5-10 倍的性能差距。

下面我会综合刚刚提到的几个点,并选择了 JavaScriptCore,V8,Hermes 和 QuickJS 这 4 个 JSVM,说说它们的优点和特点,再谈谈他们的不足。

JS 引擎功能大比拼

1.JavaScriptCore

[[383973]]

mobile_JSVM_JSC

 

JavaScriptCore 是 WebKit 默认的内嵌 JS 引擎,wikipedia 上都没有独立的词条,只在 WebKit 词条的三级目录[1]里介绍了一下,个人感觉还是有些不像话,毕竟也是老牌 JS 引擎了。

由于 WebKit 是 Apple 率先开源的,所以 WebKit 引擎运用在 Apple 自家的 Safari 浏览器和 WebView 上,尤其是 iOS 系统上,因为 Apple 的限制,所有的网页只能用 WebKit 加载,所以 WebKit 在 iOS 上达到了事实垄断,作为 WebKit 模块一部分的 JSC,顺着政策春风,也「基本」垄断了 iOS 平台的 JS 引擎份额。

垄断归垄断,其实 JSC 的性能还是可以的。

很多人不知道 JSC 的 JIT 功能其实比 V8 还要早,放在十几年前是最好的 JS 引擎,只不过后来被 V8 追了上来。而且 JSC 有个重大利好,在 iOS7 之后,JSC 作为一个系统级的 Framework 开放给开发者使用,也就是说,如果你的 APP 使用 JSC,只需要在项目里 import 一下,包体积是 0 开销的!这点在今天讨论的 JS 引擎中,JSC 是最能打的。

虽然开启 JIT 的 JSC 性能很好,但是只限于苹果御用的 Safari 浏览器和 WKWebView,只有这两个地方 JIT 功能才是默认开启的,如果在项目里直接引入 JSC,JIT 功能是关闭的。为什么这么做呢?RednaxelaFX 大佬[2] 给出过非常专业的解释[3]:

JIT 编译需要底层系统支持动态代码生成,对操作系统来说这意味着要支持动态分配带有“可写可执行”权限的内存页。当一个应用程序拥有请求分配可写可执行内存页的权限时,它会比较容易受到攻击从而允许任意代码动态生成并执行,这样就让恶意代码更容易有机可乘。

Apple 出于安全上的考虑,禁止了第三方 APP 使用 JSC 时开启 JIT,这些特点在 React Native 的 JS Runtime 页面[4]也有过相关的解释。不过在实际应用中,不做重 CPU 的运算只当胶水语言使用,JSC 还是绰绰有余了。

上面的讨论都是针对 iOS 系统的,在 Android 系统上,JSC 的表现就不尽人意了。

JSC 并没有对 Android 机型做很好的适配,虽然可以开启 JIT,但是性能表现并不好,这也是 Facebook 决心制作 Hermes 的一个原因,具体的性能对比分析可见本文的 Hermes 小节。

最后再说说 JSC 的调试支持情况。如果是 iOS 平台,我们可以直接用 Safari 的 debbuger 功能调试,如果是 Android 平台,目前我还没有找到一个很好的真机调试方法。

综合来看,JavaScriptCore 在 iOS 平台上有非常明显的主场优势,各个指标都是很优秀的,但在 Android 上因为缺乏优化,表现并不是很好。

2.V8

[[383974]]

mobile_JSVM_V8

 

V8,我想我不用过多解释了,JavaScript 能有如今的地位,V8 功不可没。性能没得说,开启 JIT 后就是业内最强(不止是 JS),有很多介绍 V8 的文章,我这里就不多描述了,我们这里说说 V8 在移动端的表现。

同样作为 Google 家的产品,每一台 Android 手机上都安装了基于 Chromium 的 WebView,V8 也一并捆绑了。但是 V8 和 Chromium 捆绑的太紧密了,不像 iOS 上的 JavaScriptCore 封装为系统库可以被所有 App 调用。这就导致你想在 Android 上用 V8 还得自己封装,社区比较出名的项目是 J2V8[5],提供了 V8 的 Java bindings 案例。

V8 性能没得说,Android 上可以开启 JIT,但这些优势都是有代价的:开启 JIT 后内存占用高,并且 V8 的包体积也不小(大概 7 MB 左右),如果作为只是画 UI 的 Hybrid 系统,还是有些奢侈了。

我们再说说 V8 在 iOS 上的集成。

V8 在 2019 年推出了 JIT-less V8[6],也就是关闭 JIT 只使用 Ignition interpreter 解释执行 JS 文件,那么我们在 iOS 上集成 V8 就成了可能,因为 Apple 还是支持接入只有解释器功能的虚拟机引擎的。但是个人认为关闭了 JIT 的 V8 接入 iOS 价值不大,因为只开启解释器的话,这时候的 V8 和 JSC 的性能其实是差不多的,引入反而会增加一定的体积开销。

V8 还有一个有意思的特性很少人提及,那就是——堆快照(Heap snapshots),这个是 V8 在 2015[7] 年就支持的功能,但是社区里很少有人讨论它。

堆快照是什么原理呢?一般来说 JSVM 启动后,第一步往往是解析 JS 文件,这个还是比较耗时的,V8 支持预先生成 Heap snapshots,然后直接加载到堆内存中,快速的获得 JS 的初始化上下文。跨平台框架 NativeScript[8] 就利用了这样的技术,可以让 JS 的加载速度提升 3 倍,技术细节可以看他们的博文[9]。

V8_heap_snapshots

 

V8 真机调试也需要引入第三方库,Android 端社区上有人对 J2V8 做了 Chrome 调试协议的扩展,即 J2V8-Debugger[10] 项目,iOS 我没有找到相关的项目,可能需要自己实现一套扩展。

综合来看 V8 的确是 JSVM 中的性能王者,Android 端使用时可以完全发挥它的威力,但是 iOS 平台因为主场劣势,并不是很推荐。

3.Hermes

[[383975]]

mobile_JSVM_hermes

 

Hermes 是 FaceBook 2019 年中旬开源的一款 JS 引擎,从 release[11] 记录可以看出,这个是专为 React Native 打造的 JS 引擎,可以说从设计之初就是为 Hybrid UI 系统打造。

Hermes 一开始推出就是要替代原来 RN Android 端的 JS 引擎,即 JavaScriptCore(因为 JSC 在 Android 端表现太拉垮了)。我们可以理一下时间线,FaceBook 自从 2019-07-12 宣布 Hermes 开源[12]后,jsc-android[13] 的维护信息就永远的停在了 2019-06-25[14],这个信号暗示得非常的明显:JavaScriptCore Android 我们不再维护啦,大家都去用我们做的 Hermes 啊。

最近 Hermes 已经计划伴随 React Native 0.64 版本登录 iOS 平台了,但是 RN 版本更新 blog 还没有出,大家可以看看我之前对 Apple 开发者协议的解读:Apple Agreement 3.3.2 规范解读,在这里我就不多说了。

Hermes 的特点主要是两个,一个是不支持 JIT,一个是支持直接生成/加载字节码,我们在下面分开讲一下。

Hermes 不支持 JIT 的主要原因有两个:加入 JIT 后,JS 引擎启动的预热时间会变长,一定程度上会加长首屏 TTI[15](页面首次加载可交互时间),现在的前端页面都讲究一个秒开,TTI 还是个挺重要的测量指标。另一个问题上 JIT 会增加包体积和内存占用,Chrome 内存占用高 V8 还是要承担一定责任的。

因为不支持 JIT,Hermes 在一些 CPU 密集计算的领域就不占优势了,所以在 Hybrid 系统里,最优的解决方案就是充分发挥 JavaScript 胶水语言的作用,CPU 密集的计算(例如矩阵变换,参数加密等)放在 Native 里做,算好了再传递给 JS 表现在 UI 上,这样可以兼顾性能和开发效率。

Hermes 最引人瞩目的就是支持生成字节码了,我在之前的博文《🎯 跨端框架的核心技术到底是什么?》也提到过,Hermes 加入 AOT 后,Babel、Minify、Parse 和 Compile 这些流程全部都在开发者电脑上完成,直接下发字节码让 Hermes 运行就行,我们直接用个 demo 演示一下。

Hermes

 

先写个 test.js 的文件,里面随便写点啥都行;然后编译一下 Hermes 的源码,编译过程直接按文档[16]来就行,我这里就略过了。

首先 Hermes 支持直接解释运行 JS 代码,就是正常的 JS 加载编译运行流程。

  1. hermes test.js 

我们可以加入 -emit-binary 参数尝试一下生成 Bytecode 的功能:

  1. hermes -emit-binary -out test.hbc test.js 

然后就会生成一份 test.hbc 字节码文件:

hermes_bytecode

 

最后我们可以让 Hermes 直接加载运行 test.hbc 文件:

  1. hermes test.hbc 

客观评价一下 Hermes 的字节码,首先省去了在 JS 引擎里解析编译的流程,JS 代码的加载速度将会大大加快,体现在 UI 上就是 TTI 时间会明显缩短;另一个优势 Hermes 的字节码在设计时就考虑了移动端的性能限制,支持增量加载而不是全量加载,对内存受限的中低端 Android 机更友好;不过字节码的体积会比原来的 JS 文件会大一些,但是考虑到 Hermes 引擎本身体积就不大,综合考虑下来这些体积增量还是可以接受的。

关于详细的 Hermes 性能测试情况,网上有两篇文章写的比较好:一篇是 React Native Memory profiling: JSC vs V8 vs Hermes[17],可以看到在 Android 设备上 Hermes 的表现还是很优异的,而 JSC 的表现非常拉垮:

JSCvsV8vsHermes

 

另一篇是携程的文章:携程对 RN 新一代 JS 引擎 Hermes 的调研,可以看出 Hermes 综合成绩最高(JSC 还是一样的拉垮):

JSVM_CPU_Performance

 

说完性能我们再说说 Hermes 的 JS 语法支持情况。

Hermes 主要支持的是 ES6 语法,刚开源时不支持 Proxy,不过 v0.7.0[18] 已经支持了。他们的团队也比较有想法,不支持 with eval() 等这种属于设计糟粕的 API,这种设计的权衡我个人还是比较认同的。

最后我们谈谈 Hermes 的调试功能。

目前 Hermes 已经支持了 Chrome 的调试协议,我们可以直接用 Chrome 的 debugging 工具直接调试 Hermes 引擎,具体的操作可见文档:Debugging JS on Hermes using Google Chrome's DevTools[19]

综合来看,Hermes 是一款专为移动端 Hybrid UI System 打造的 JS 引擎,如果要自建一套 Hybrid 系统,Hermes 是一个非常好的选择。

4.QuickJS

mobile_JSVM_quickjs

 

正式介绍 QuickJS 前我们先说说它的作者:Fabrice Bellard。

软件界一直有个说法,一个高级程序员创造的价值可以超过 20 个平庸的程序员,但 Fabrice Bellard 不是高级程序员,他是天才,在我看来他的创造力可以超过 20 个高级程序员,我们可以顺着时间轴[20]理一下他创造过些什么:

  • 1997年,发布了最快速的计算圆周率的算法,此算法是 Bailey-Borwein-Plouffe 公式的变体,前者的时间复杂度是O(n^3),他给优化成了O(n^2),使得计算速度提高了43%,这是他在数学上的成就
  • 2000 年,发布了 FFmpeg,这是他在音视频领域的一个成就
  • 2000,2001,2018 三年三度获得国际混淆 C 代码大赛
  • 2002 年,发布了TinyGL,这是他在图形学领域的成就
  • 2005 年,发布了 QEMU,这是他在虚拟化领域的成就
  • 2011 年,他用 JavaScript 写了一个 PC 虚拟机 Jslinux,一个跑在浏览器上的 Linux 操作系统
  • 2019 年,发布了 QuickJS,一个支持 ES2020 规范的 JS 虚拟机

当人和人之间的差距差了几个数量级后,羡慕嫉妒之类的情绪就会转变为崇拜了,Bellard 就是一个这样的人。

收复一下心情,我们来看一下 QuickJS 这个项目。QuickJS 继承了 Fabrice Bellard 作品的一贯特色——小巧而又强大。

QuickJS 体积非常小,只有几个 C 文件,没有乱七八糟的第三方依赖。但是他的功能又非常完善,JS 语法支持到 ES2020[21],Test262[22] 的测试显示,QuickJS 的语法支持度比 V8 还要高。

test262

 

那么 QuickJS 的性能如何呢?QuickJS 官上有个基准测试[23],综合比较了多款 JS 引擎对同一测试用例的跑分情况。下面是测试结果:

JSVM_Benchmark

 

结合上面的表格和个人的一些测试,可以简单的得出一些结论:

  • 开启 JIT 的 V8 综合评分差不多是 QuickJS 的 35 倍,但是在同等主打轻量的 JS 引擎中,QuickJS 的性能还是很耀眼的
  • 在内存占用上,QuickJS 远低于 V8,毕竟 JIT 是是吃内存的大户,而且 QuickJS 的设计对嵌入式系统很友好(Bellard 成就奖杯 🏆 再 +1)
  • QuickJS 和 Hermes 的跑分情况是差不多的,我私下做了一些性能测试,这两个引擎的表现也很相近

因为 QuickJS 的设计,我不经好奇他和 Lua 的性能对比如何。

Lua 是一门非常小巧精悍的语言,在游戏领域和 C/C++ 开发中一直充当胶水语言的作用。

我个人写了一些测试用例,发现 QuickJS 和 Lua 的执行效率也是差不多的,后来在网上找到一篇博文 Lua vs QuickJS[24],这个老哥也做了一些测试,结论也是它俩的性能差不多,在部分场景 Lua 会比 QuickJS 快一些。

官方文档里有提到,QuickJS 支持生成字节码[25],这样可以免去 JS 文件编译解析的过程。

我一开始以为 QuickJS 和 Hermes 一样,可以直接生成字节码,然后交给 QuickJS 解释执行。后来自己编译了一下才发现,QuickJS 的作用机制和 Hermes 还不太一样:qjsc 生成字节码的 -e 和 -c 选项,都是先把 js 文件生成一份字节码,然后拼到一个 .c 文件里,大概长下面的这个样子:

  1. #include <quickjs/quickjs-libc.h> 
  2.  
  3. const uint32_t qjsc_hello_size = 87; 
  4.  
  5. // JS 文件编译生成的字节码都在这个数组里 
  6. const uint8_t qjsc_hello[87] = { 
  7.  0x02, 0x04, 0x0e, 0x63, 0x6f, 0x6e, 0x73, 0x6f, 
  8.  0x6c, 0x65, 0x06, 0x6c, 0x6f, 0x67, 0x16, 0x48, 
  9.  0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f, 0x72, 
  10.  0x6c, 0x64, 0x22, 0x65, 0x78, 0x61, 0x6d, 0x70, 
  11.  0x6c, 0x65, 0x73, 0x2f, 0x68, 0x65, 0x6c, 0x6c, 
  12.  0x6f, 0x2e, 0x6a, 0x73, 0x0e, 0x00, 0x06, 0x00, 
  13.  0x9e, 0x01, 0x00, 0x01, 0x00, 0x03, 0x00, 0x00, 
  14.  0x14, 0x01, 0xa0, 0x01, 0x00, 0x00, 0x00, 0x39, 
  15.  0xf1, 0x00, 0x00, 0x00, 0x43, 0xf2, 0x00, 0x00, 
  16.  0x00, 0x04, 0xf3, 0x00, 0x00, 0x00, 0x24, 0x01, 
  17.  0x00, 0xd1, 0x28, 0xe8, 0x03, 0x01, 0x00, 
  18. }; 
  19.  
  20. int main(int argc, char **argv) 
  21.   JSRuntime *rt; 
  22.   JSContext *ctx; 
  23.   rt = JS_NewRuntime(); 
  24.   ctx = JS_NewContextRaw(rt); 
  25.   JS_AddIntrinsicBaseObjects(ctx); 
  26.   js_std_add_helpers(ctx, argc, argv); 
  27.   js_std_eval_binary(ctx, qjsc_hello, qjsc_hello_size, 0); 
  28.   js_std_loop(ctx); 
  29.   JS_FreeContext(ctx); 
  30.   JS_FreeRuntime(rt); 
  31.   return 0; 

因为这是个 .c 文件,想跑起来还得再编译一次生成二进制文件。

从字节码这个设计点来看,QuickJS 和 Hermes 的定位还是不太一样的。

虽然直接生成字节码可以大大减少 JS 文本文件的解析时间,但是 QuickJS 还是更偏嵌入式一些,生成的字节码放在一个 C 文件中,还需要进行编译才能运行;Hermes 为 React Native 而生,生成的字节码一开始就考虑到分发功能(热更新就是一个应用场景),支持字节码的直接加载运行,不需要再编译一次。

上面主要还是对性能的考量,下面我们看看开发体验。

首先是 QuickJS 的调试功能支持。到目前为止(2021-02-22),QuickJS 还没有官方的调试器,也就是说 debugger 语句会被忽略,社区有人实现了一套基于 VSCode 的调试器支持vscode-quickjs-debug[26],但是会对 QuickJS 做一些定制,个人还是蛮期待官方支持某个调试器协议的。

从 集成 的角度上看,社区上已经有了 iOS[27] 和 Android[28] 的示例项目,可以拿来用来参考接入到自己的工程中。

综合来看,QuickJS 是一款潜力非常大的 JS 引擎,在 JS 语法高度支持的前提下,还把性能和体积都优化到了极致。在移动端的 Hybrid UI 架构和游戏脚本系统都可以考虑接入。

选型思路

1.单引擎

单引擎的意思就是 iOS 端和 Android 端统一采用一个引擎,这样做的话在 JS 层差异可以抹平,不容易出现同一份 JS 代码在 iOS 上运行是好的,Android 上就出错的奇异 BUG。结合市面上的跨端方案,大概有下面三种选型:

  • 统一采用 JSC:这个是 React Native 0.60 之前的方案
  • 统一使用 Hermes:这个是 React Native 0.64 之后的设计方案
  • 统一采用 QuickJS:QuickJS 体积很小,可以用来制作非常轻量的 Hybrid 系统

上面看出没有统一采用 V8,这个就是我前面说的,V8 在 iOS 平台没有主场优势,关闭 JIT 后性能和 JSC 差不多,还会增大包体积,并不是很划算。

2.双引擎

双引擎也很好理解,就是 iOS 端和 Android 端各用各的,优点是可以发挥各自的主场优势,缺点是可能会因为平台不一致导致双端运行结果不统一,现在的方案有这么几种:

  • iOS 用 JSC,Android 用 V8:Weex,NativeScript 都是这样的,可以在包体积和性能上有较好的均衡
  • iOS 用 JSC,Android 用 Hermes:React Natvie 现如今的方案
  • iOS 用 JSC,Android 用 QuickJS:滴滴的跨端框架 hummer[29] 就是这样的设计

从选型上看,iOS 上都选择了 JSC,Android 各有各的选择,倒是充分发挥了两个平台的特色 : )

3.调试

无论是单引擎还是双引擎,集成后的业务开发体验也很重要。对于自带 debugger 功能的引擎来说一切都不在话下,但是对于没有实现调试协议的引擎来说,缺少 debugger 还是会影响体验的。

但不是也没有办法,一般来说我们可以曲线救国,类似于 React Native 的 Remote JS Debugging 的思路:

我们可以加个开关,把 JS 代码通过 websocket 传送到 Chrome 的 Web Worker,然后用 Chrome 的 V8 进行调试。这样做的优势是可以调整一些业务上的 BUG,劣势就是又会引入一个 JS 引擎,万一遇到一些引擎实现的 BUG,就很难 debug 了。不过好在这种情况非常非常少见,我们也不能因噎废食对吧。

总结

本文从性能、体积、调试便捷性等功能点出发,分析了 JavaScriptCore,V8,Hermes 和QuickJS 这 4 款 JS 引擎,分别分析了它们的缺点和弱点。如果大家有移动端 JS 引擎选型的困惑,我认为从本文出发,还是可以给不少人以灵感的,希望我的这篇文章能帮助到大家。

参考链接跨端框架的核心技术到底是什么?

如何隐藏你的热更新 bundle 文件?

深入理解JSCore[30]

 

QuickJS 引擎一年见闻录[31]

 

责任编辑:武晓燕 来源: 卤蛋实验室
相关推荐

2016-08-16 08:44:18

VRUnrealCryENGINE

2019-08-28 20:46:57

AI人工智能教育

2014-10-13 15:17:59

代码托管

2016-08-22 13:32:53

4G网络网络速度OpenSigna

2014-11-27 15:02:06

移动电源方案大赛

2014-11-12 13:37:57

可穿戴设备英特尔

2014-10-22 09:17:46

联想

2016-11-21 17:27:04

Android 推送

2015-03-03 11:12:45

云计算开源容器技术

2017-07-26 15:31:17

云计算 方案

2015-07-29 11:16:35

APM

2022-06-06 08:16:16

RedisJavaHaspM

2017-08-23 14:48:36

VBoxVMWare虚拟化

2009-06-26 09:15:53

硅谷人才流失

2016-09-22 15:05:01

BAT开发座椅

2021-04-09 09:00:00

框架工具Web

2018-01-24 11:05:38

华为云裸金属服务器

2014-10-23 17:36:19

百度

2021-05-26 15:00:27

存储NVMe over TSSD

2018-10-15 15:12:12

SpakrFlink大数据
点赞
收藏

51CTO技术栈公众号