如果你喜爱我的文章，心愿点赞???? 珍藏 ???? 评论 ???? 三连一下，谢谢你，这对我真的很重要！
在个别的挪动端开发场景中，每次更新利用性能都是通过 Native 语言开发并通过利用市场版本散发来实现的。然而市场瞬息万变，Native 语言在开发效率上存在肯定有余，并且从 APP 版本更新 到 利用市场审核公布 再到 用户下载更新，总会存在肯定的时间差，这样就导致新的性能无奈及时笼罩全量用户。
为了解决这个问题，开发者们个别会在我的项目里引入一门脚本语言，提速 APP 的研发流程。在挪动端利用比拟宽泛的脚本语言有 Lua 和 JavaScript，前者在游戏畛域用的比拟多，后者在应用领域用的比拟多。本篇文章次要是想探讨一下挪动双端（iOS & Android）的 JavaScript 引擎选型。因为集体程度无限，文章总会有脱漏和有余的中央，还请各位大佬多多指教。
<!–truncate–>
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
JavaScriptCore 是 WebKit 默认的内嵌 JS 引擎，wikipedia 上都没有独立的词条，只在 WebKit 词条的三级目录里介绍了一下，个人感觉还是有些不像话，毕竟也是老牌 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 大佬 给出过十分业余的解释：
JIT 编译须要底层零碎反对动静代码生成，对操作系统来说这意味着要反对动态分配带有“可写可执行”权限的内存页。当一个应用程序领有申请调配可写可执行内存页的权限时，它会比拟容易受到攻打从而容许任意代码动静生成并执行，这样就让恶意代码更容易无隙可乘。
Apple 出于平安上的思考，禁止了第三方 APP 应用 JSC 时开启 JIT，这些特点在 React Native 的 JS Runtime 页面也有过相干的解释。不过在理论利用中，不做重 CPU 的运算只当胶水语言应用，JSC 还是入不敷出了。
下面的探讨都是针对 iOS 零碎的，在 Android 零碎上，JSC 的体现就不尽人意了。JSC 并没有对 Android 机型做很好的适配，尽管能够开启 JIT，然而性能体现并不好，这也是 Facebook 信心制作 Hermes 的一个起因，具体的性能比照剖析可见本文的 Hermes 大节。
最初再说说 JSC 的调试反对状况。如果是 iOS 平台，咱们能够间接用 Safari 的 debbuger 性能调试，如果是 Android 平台，目前我还没有找到一个很好的真机调试办法。
综合来看，JavaScriptCore 在 iOS 平台上有非常明显的主场优势，各个指标都是很优良的，但在 Android 上因为不足优化，体现并不是很好。
2.V8
V8，我想我不必过多解释了，JavaScript 能有现在的位置，V8 功不可没。性能没得说，开启 JIT 后就是业内最强（不止是 JS），有很多介绍 V8 的文章，我这里就不多形容了，咱们这里说说 V8 在挪动端的体现。
同样作为 Google 家的产品，每一台 Android 手机上都装置了基于 Chromium 的 WebView，V8 也一并捆绑了。然而 V8 和 Chromium 捆绑的太严密了，不像 iOS 上的 JavaScriptCore 封装为零碎库能够被所有 App 调用。这就导致你想在 Android 上用 V8 还得本人封装，社区比拟闻名的我的项目是 J2V8，提供了 V8 的 Java bindings 案例。
V8 性能没得说，Android 上能够开启 JIT，但这些劣势都是有代价的：开启 JIT 后内存占用高，并且 V8 的包体积也不小（大略 7 MB 左右），如果作为只是画 UI 的 Hybrid 零碎，还是有些侈靡了。
咱们再说说 V8 在 iOS 上的集成。V8 在 2019 年推出了 JIT-less V8，也就是敞开 JIT 只应用 Ignition interpreter 解释执行 JS 文件，那么咱们在 iOS 上集成 V8 就成了可能，因为 Apple 还是反对接入只有解释器性能的虚拟机引擎的。然而集体认为敞开了 JIT 的 V8 接入 iOS 价值不大，因为只开启解释器的话，这时候的 V8 和 JSC 的性能其实是差不多的，引入反而会减少肯定的体积开销。
V8 还有一个有意思的个性很少人提及，那就是——堆快照（Heap snapshots），这个是 V8 在 2015 年就反对的性能，然而社区里很少有人探讨它。
堆快照是什么原理呢？一般来说 JSVM 启动后，第一步往往是解析 JS 文件，这个还是比拟耗时的，V8 反对事后生成 Heap snapshots，而后间接加载到堆内存中，疾速的取得 JS 的初始化上下文。跨平台框架 NativeScript 就利用了这样的技术，能够让 JS 的加载速度晋升 3 倍，技术细节能够看他们的博文。
V8 真机调试也须要引入第三方库，Android 端社区上有人对 J2V8 做了 Chrome 调试协定的扩大，即 J2V8-Debugger 我的项目，iOS 我没有找到相干的我的项目，可能须要本人实现一套扩大。
综合来看 V8 确实是 JSVM 中的性能王者，Android 端应用时能够齐全施展它的威力，然而 iOS 平台因为主场劣势，并不是很举荐。
3.Hermes
Hermes 是 FaceBook 2019 年中旬开源的一款 JS 引擎，从 release 记录能够看出，这个是专为 React Native 打造的 JS 引擎，能够说从设计之初就是为 Hybrid UI 零碎打造。
Hermes 一开始推出就是要代替原来 RN Android 端的 JS 引擎，即 JavaScriptCore（因为 JSC 在 Android 端体现太拉垮了）。咱们能够理一下工夫线，FaceBook 自从 2019-07-12 发表 Hermes 开源后，jsc-android 的保护信息就永远的停在了 2019-06-25，这个信号暗示得十分的显著：JavaScriptCore Android 咱们不再保护啦，大家都去用咱们做的 Hermes 啊。
最近 Hermes 曾经打算随同 React Native 0.64 版本登录 iOS 平台了，然而 RN 版本更新 blog 还没有出，大家能够看看我之前对 Apple 开发者协定的解读：Apple Agreement 3.3.2 标准解读，在这里我就不多说了。
Hermes 的特点次要是两个，一个是不反对 JIT，一个是反对间接生成/加载字节码，咱们在上面离开讲一下。
Hermes 不反对 JIT 的次要起因有两个：退出 JIT 后，JS 引擎启动的预热工夫会变长，肯定水平上会加长首屏 TTI（页面首次加载可交互工夫），当初的前端页面都考究一个秒开，TTI 还是个挺重要的测量指标。另一个问题上 JIT 会减少包体积和内存占用，Chrome 内存占用高 V8 还是要承当肯定责任的。
因为不反对 JIT，Hermes 在一些 CPU 密集计算的畛域就不占优势了，所以在 Hybrid 零碎里，最优的解决方案就是充分发挥 JavaScript 胶水语言的作用，CPU 密集的计算（例如矩阵变换，参数加密等）放在 Native 里做，算好了再传递给 JS 体现在 UI 上，这样能够兼顾性能和开发效率。
Hermes 最引人瞩目的就是反对生成字节码了，我在之前的博文《???? 跨端框架的核心技术到底是什么？》也提到过，Hermes 退出 AOT 后，Babel、Minify、Parse 和 Compile 这些流程全副都在开发者电脑上实现，间接下发字节码让 Hermes 运行就行，咱们间接用个 demo 演示一下。
先写个 test.js 的文件，外面轻易写点啥都行；而后编译一下 Hermes 的源码，编译过程间接按文档来就行，我这里就略过了。
首先 Hermes 反对间接解释运行 JS 代码，就是失常的 JS 加载编译运行流程。
hermes test.js咱们能够退出 -emit-binary 参数尝试一下生成 Bytecode 的性能：
hermes -emit-binary -out test.hbc test.js而后就会生成一份 test.hbc 字节码文件：
最初咱们能够让 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，能够看到在 Android 设施上 Hermes 的体现还是很优异的，而 JSC 的体现十分拉垮：
另一篇是携程的文章：携程对 RN 新一代 JS 引擎 Hermes 的调研，能够看出 Hermes 综合问题最高（JSC 还是一样的拉垮）：
说完性能咱们再说说 Hermes 的 JS 语法反对状况。Hermes 次要反对的是 ES6 语法，刚开源时不反对 Proxy，不过 v0.7.0 曾经反对了。他们的团队也比拟有想法，不反对 with eval() 等这种属于设计糟粕的 API，这种设计的衡量我集体还是比拟认同的。
最初咱们谈谈 Hermes 的调试性能。目前 Hermes 曾经反对了 Chrome 的调试协定，咱们能够间接用 Chrome 的 debugging 工具间接调试 Hermes 引擎，具体的操作可见文档：Debugging JS on Hermes using Google Chrome’s DevTools
综合来看，Hermes 是一款专为挪动端 Hybrid UI System 打造的 JS 引擎，如果要自建一套 Hybrid 零碎，Hermes 是一个十分好的抉择。
4.QuickJS
正式介绍 QuickJS 前咱们先说说它的作者：Fabrice Bellard。
软件界始终有个说法，一个高级程序员发明的价值能够超过 20 个平庸的程序员，但 Fabrice Bellard 不是高级程序员，他是蠢才，在我看来他的创造力能够超过 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，Test262 的测试显示，QuickJS 的语法反对度比 V8 还要高。
那么 QuickJS 的性能如何呢？QuickJS 官上有个基准测试，综合比拟了多款 JS 引擎对同一测试用例的跑分状况。上面是测试后果：
联合下面的表格和集体的一些测试，能够简略的得出一些论断：
- 开启 JIT 的 V8 综合评分差不多是 QuickJS 的 35 倍，然而在等同主打轻量的 JS 引擎中，QuickJS 的性能还是很夺目的
- 在内存占用上，QuickJS 远低于 V8，毕竟 JIT 是是吃内存的小户，而且 QuickJS 的设计对嵌入式零碎很敌对（Bellard 成就奖杯 ???? 再 +1）
- QuickJS 和 Hermes 的跑分状况是差不多的，我私下做了一些性能测试，这两个引擎的体现也很相近
因为 QuickJS 的设计，我不经好奇他和 Lua 的性能比照如何。Lua 是一门十分玲珑精悍的语言，在游戏畛域和 C/C++ 开发中始终充当胶水语言的作用，我集体写了一些测试用例，发现 QuickJS 和 Lua 的执行效率也是差不多的，起初在网上找到一篇博文 Lua vs QuickJS，这个老哥也做了一些测试，论断也是它俩的性能差不多，在局部场景 Lua 会比 QuickJS 快一些。
官网文档里有提到，QuickJS 反对生成字节码，这样能够免去 JS 文件编译解析的过程。我一开始认为 QuickJS 和 Hermes 一样，能够间接生成字节码，而后交给 QuickJS 解释执行。起初本人编译了一下才发现，QuickJS 的作用机制和 Hermes 还不太一样：qjsc 生成字节码的 -e 和 -c 选项，都是先把 js 文件生成一份字节码，而后拼到一个 .c 文件里，大略长上面的这个样子：
#include <quickjs/quickjs-libc.h>
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，然而会对 QuickJS 做一些定制，集体还是蛮期待官网反对某个调试器协定的。
从 集成 的角度上看，社区上曾经有了 iOS 和 Android 的示例我的项目，能够拿来用来参考接入到本人的工程中。
综合来看，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 就是这样的设计
从选型上看，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
QuickJS 引擎一年见闻录
如果你喜爱我的文章，心愿点赞???? 珍藏 ???? 在看 ???? 三连一下，谢谢你，这对我真的很重要！
欢送大家关注我的微信公众号：卤蛋实验室，目前专一前端技术，对图形学也有一些渺小钻研。
原文链接 ???? ???? 挪动端 JS 引擎哪家强？美国硅谷找……：更新更及时，浏览体验更佳
发表回复