前不久，Facebook在ChainReact 2019大会上正式推出了新一代JavaScript执行引擎Hermes。

Hermes 是一款小巧轻便的 JavaScript 引擎，专门针对在 Android 上运行 React Native 进行了优化。对于许多应用程序，只需启用 Hermes 即可缩短启动时间、减少内存使用量并缩小应用程序大小，此外因为它采用 JavaScript 标准实现，所以很容易在 React Native 应用中集成。

Hermes简介

自ReactNative推出以来，有大量的APP接入并使用，其中也包括大型应用的主流程业务。随着业务复杂度不断上升，性能问题变得无法忽视。 在分析性能数据时，Facebook团队发现 JavaScript 引擎是影响启动性能和应用包体积的重要因素。由于JavaScriptCore最初是为桌面浏览器端设计，相较于桌面端，移动端能力有太多的限制，为了能从底层对移动端进行性能优化，Facebook团队选择自建JavaScrip引擎，设计了Hermes，限于iOS AppStore审核限制，目前仅用于Android平台。 Chain React大会上官方给出了Hermes引擎的一组测试数据：‘

从页面启动到用户可操作的时间长短（Time To Interact：TTI），从4.3s减少到2.01s App的下载大小，从41MB减少到22MB 内存占用，从185MB减少到136MB

可以发现，切换到Hermes后，加载时长，App大小和内存占有三个关键指标都有了显著的提高。

由于 Hermes 是针对移动应用优化的，因此我们没有计划将其集成到任何浏览器或 Node.js 等服务端基础架构中。在这些环境中现有的 JavaScript 引擎仍然是首选。

Hermes优化方案

在移动应用开发中，首次加载启动，内存大小和应用大小都是衡量应用好坏的重要指标，因此Hermes也是从这些方面还对React Native应用进行优化。

字节码预编译

通常来说，JavaScript 引擎会在加载后才解析 JavaScript 源代码并生成字节码，JavaScript 代码需要在生成字节码后才开始执行。为了跳过这一步，Hermes 引入了一个预编译器，在移动应用构建过程中运行。这样一来优化字节码的时间可以更长，使字节码更小、效率更高。现在还可以针对整个程序做优化，例如删除重复数据和打包字符串表等。

字节码的设计使其在运行时可以映射到内存中并解释，而无需急切地读取整个文件。许多中低端移动设备上性能较差的闪存 I/O 显著增加了延迟，因此按需从闪存加载体积经过优化的字节码会显著提升 TTI。此外，由于内存以只读方式映射并由文件支持，因此不使用虚拟内存的移动操作系统（如 Android）可以在内存不足时清除这些页面，进而减少了内存较少的设备上杀掉进程的现象。

尽管压缩后的字节码比压缩后的 JavaScript 源代码略大，但由于 Hermes 的原生代码体积较小，因此 Hermes 从整体上减少了 React Native 项目Android 应用的体积。

无 JIT

为了加快执行速度，流行的 JavaScript 引擎可以将频繁解释的代码编译为机器码，这项工作由即时（JIT）编译器执行。

Hermes 现在并没有 JIT 编译器。这意味着 Hermes 在某些基准测试中表现不会很出色，特别是那些依赖于 CPU 性能的基准测试。这一设计是有意为之：这些基准很难反映移动应用程序的实际工作负载。我们也对 JIT 做过一些实验，但我们认为想要获得真正的速度提升还是要关注上述现实指标。因为 JIT 必须在应用程序启动时预热，所以它们难以改善 TTI，甚至可能会损害 TTI。此外，JIT 会增加原生代码体积和内存消耗，这会对我们的主要指标产生负面影响。JIT 可能会拖累我们最关心的指标，因此我们选择不实现 JIT。

垃圾回收策略

在移动设备中内存的高效利用是非常重要的。一般来说，低端设备的内存往往是有限的，因此操作系统会强制杀掉使用过多内存的应用程序。当应用被杀后再次使用时需要缓慢地重启，后台功能也会受到影响。在早期测试中我们了解到，在 32 位设备上运行大型应用时虚拟地址（VA）空间，尤其是连续的 VA 空间都能是一种有限的资源，就算用了物理页面懒惰分配都没多大帮助。 因此，为了尽量优化引擎使用的内存和 VA 空间，我们构建了一个具有以下功能的垃圾回收器，主要的措施有：

• 按需分配：仅在需要时以块的形式分配 VA 空间。
• 非连续：VA 空间不必在单个内存范围内，这避免了 32 位设备上的资源限制。
• 移动：能够移动对象意味着可以对内存进行碎片整理，并将不再需要的块返回给操作系统。
• 分代：每次 GC 时不扫描整个 JavaScript 堆，减少 GC 时间。