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

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

在一般的移动端开发场景中，每次更新应用功能都是通过 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 加载编译运行流程。

hermes test.js 

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

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

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

hermes_bytecode

 

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

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 文件里，大概长下面的这个样子：

#include  
 
const uint32_t qjsc_hello_size = 87; 
 
// JS 文件编译生成的字节码都在这个数组里 
const uint8_t qjsc_hello[87] = { 
 0x02, 0x04, 0x0e, 0x63, 0x6f, 0x6e, 0x73, 0x6f, 
 0x6c, 0x65, 0x06, 0x6c, 0x6f, 0x67, 0x16, 0x48, 
 0x65, 0x6c, 0x6c, 0x6f, 0x20, 0x57, 0x6f, 0x72, 
 0x6c, 0x64, 0x22, 0x65, 0x78, 0x61, 0x6d, 0x70, 
 0x6c, 0x65, 0x73, 0x2f, 0x68, 0x65, 0x6c, 0x6c, 
 0x6f, 0x2e, 0x6a, 0x73, 0x0e, 0x00, 0x06, 0x00, 
 0x9e, 0x01, 0x00, 0x01, 0x00, 0x03, 0x00, 0x00, 
 0x14, 0x01, 0xa0, 0x01, 0x00, 0x00, 0x00, 0x39, 
 0xf1, 0x00, 0x00, 0x00, 0x43, 0xf2, 0x00, 0x00, 
 0x00, 0x04, 0xf3, 0x00, 0x00, 0x00, 0x24, 0x01, 
 0x00, 0xd1, 0x28, 0xe8, 0x03, 0x01, 0x00, 
}; 
 
int main(int argc, char **argv) 
{ 
  JSRuntime *rt; 
  JSContext *ctx; 
  rt = JS_NewRuntime(); 
  ctx = JS_NewContextRaw(rt); 
  JS_AddIntrinsicBaseObjects(ctx); 
  js_std_add_helpers(ctx, argc, argv); 
  js_std_eval_binary(ctx, qjsc_hello, qjsc_hello_size, 0); 
  js_std_loop(ctx); 
  JS_FreeContext(ctx); 
  JS_FreeRuntime(rt); 
  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]