让 Hermes 成为默认引擎

自 我们于 2019 年宣布 Hermes 以来，它在社区中的采用率不断提高。维护着 React Native 应用热门元框架的 Expo 团队，最近在 Hermes 成为 Expo 最受请求的功能之一 后，宣布 实验性支持 Hermes。流行的移动数据库 Realm 团队也于最近发布了对 Hermes 的 alpha 支持。在这篇文章中，我们想强调我们在过去两年中取得的一些最令人兴奋的进展，以推动 Hermes 成为 React Native 的*最佳* JavaScript 引擎。展望未来，我们相信通过这些改进以及即将到来的更多改进，我们可以让 Hermes 成为所有平台上 React Native 的默认 JavaScript 引擎。

为 React Native 优化

Hermes 的显著特点是它如何提前执行编译工作，这意味着启用 Hermes 的 React Native 应用会附带预编译的优化字节码，而不是普通的 JavaScript 源代码。这大大减少了为用户启动产品所需的工作量。Facebook 和社区应用的测量结果表明，启用 Hermes 通常能将产品的 TTI（或 可交互时间）指标减少近一半。

话虽如此，我们一直在努力改进 Hermes 的许多其他方面，使其作为专为 React Native 设计的 JavaScript 引擎变得更好。

为 Fabric 构建新的垃圾回收器

随着新 React Native 架构中即将到来的 Fabric 渲染器，将有可能在 UI 线程上同步调用 JavaScript。然而，这意味着如果 JavaScript 线程执行时间过长，可能会导致明显的 UI 帧丢失并阻塞用户输入。React Fiber 启用的 并发渲染 将通过将渲染工作分成块来避免调度长时间的 JavaScript 任务。然而，JavaScript 线程的另一个常见延迟来源是——当 JavaScript 引擎必须“停止世界”以执行垃圾回收（GC）时。

Hermes 中之前默认的垃圾回收器 GenGC 是一个单线程分代垃圾回收器。新一代使用典型的半空间复制策略，而老一代使用标记-整理策略，这使得它在积极地将内存返回给操作系统方面表现出色。由于是单线程，GenGC 的缺点是会导致长时间的 GC 暂停。在像 Android 版 Facebook 这样复杂的应用上，我们观察到平均暂停时间为 200 毫秒，p99 时为 1.4 秒。考虑到 Android 版 Facebook 庞大且多样的用户群，我们甚至看到过长达 7 秒的暂停。

为了缓解这个问题，我们实现了一个全新的*大部分并发* GC，名为 Hades。Hades 收集其年轻一代的方式与 GenGC 完全相同，但它通过快照式标记-清除回收器管理其老一代，这可以通过在后台线程中执行大部分工作而不会阻塞引擎主线程执行 JavaScript 代码来显著减少 GC 暂停时间。我们的统计数据显示，在 64 位设备上，Hades 在 p99.9 时仅暂停 48 毫秒（比 GenGC 快 34 倍！），在 32 位设备上（作为单线程*增量* GC 运行）在 p99.9 时约为 88 毫秒。这些暂停时间的改进可能会以整体吞吐量为代价，因为需要更昂贵的写屏障、基于空闲列表的较慢分配（而不是碰撞指针分配器）以及增加的堆碎片。我们认为这些是正确的权衡，并且我们能够通过合并和我们将在后面讨论的其他内存优化来实现整体更低的内存消耗。

解决性能痛点

应用程序的启动时间对于许多应用的成功至关重要，我们正在不断推动 React Native 的边界。对于我们在 Hermes 中实现的任何新的 JavaScript 功能，我们都会仔细监控它们对生产性能的影响，并确保它们不会导致指标下降。在 Facebook，我们目前正在试验 Metro 中 专门针对 Hermes 的 Babel 转换配置文件，以用 Hermes 的原生 ESNext 实现替换十几个 Babel 转换。我们观察到在许多界面上 TTI 改进了 18-25%，并且整体字节码大小减小，我们预计在开源版本中也会看到类似的结果。

除了启动性能，我们还发现内存占用是 React Native 应用的一个改进机会，尤其是在 虚拟现实领域。由于我们作为 JavaScript 引擎拥有的低级别控制权，我们能够通过挤压比特和字节来提供一系列内存优化

1. 以前，所有 JavaScript 值都表示为 64 位 NaN-boxing 编码的带标签值，以在 64 位架构上表示浮点双精度数和指针。然而，这在实践中是浪费的，因为大多数数字是小整数（SMI），并且客户端应用程序的 JavaScript 堆通常不期望超过 4GiB。为了解决这个问题，我们引入了一种新的 32 位编码，其中 SMI 和指针以 29 位编码（因为指针是 8 字节对齐的，我们可以假设最低 3 位始终为零），而其余的 JS 数字则装箱到堆中。这使得 JavaScript 堆大小减少了约 30%。
2. 不同类型的 JavaScript 对象在 JavaScript 堆中表示为不同类型的 GC 管理单元。通过积极优化这些单元头的内存布局，我们能够将内存使用量再减少约 15%。

我们对 Hermes 做出的一个关键决定是：不实现 即时 (JIT) 编译器，因为我们相信对于大多数 React Native 应用程序来说，额外的预热成本以及二进制和内存上额外的占用实际上是不值得的。多年来，我们投入了大量精力来优化解释器性能和编译器优化，以使 Hermes 的吞吐量在 React Native 工作负载方面具有竞争力。我们将继续专注于通过识别所有地方（解释器调度循环、堆栈布局、对象模型、GC 等）的性能瓶颈来提高吞吐量。期待在即将发布的版本中看到更多数据！

垂直集成领域的开创者

在 Facebook，我们更喜欢将项目放在一个大型 monorepo 中。通过让引擎（Hermes）和宿主（React Native）紧密协作迭代，我们为垂直集成留下了很大的空间。举几个例子：

• Hermes 支持通过使用 Chrome DevTools 协议 来实现 Chrome 调试器进行设备上 JavaScript 调试。它优于传统的“远程 JS 调试”（它使用应用内代理在桌面 Chrome 中运行 JS），因为它支持调试同步原生调用并保证一致的运行时环境。结合 React DevTools、Metro、Inspector 等，Hermes 调试器现在是 Flipper 的一部分，提供一站式的开发者体验。
• 在 React Native 应用初始化路径期间分配的对象通常是长期存在的，并且不遵循分代 GC 利用的*分代假设*。因此，我们 在 React Native 中配置 Hermes，将前 32MB 直接分配到老一代（称为*预分代*）中，以避免触发 GC 暂停并延迟 TTI。
• 新的 React Native 架构大量基于 JSI（或 JavaScript Interface），这是一个轻量级、通用目的的 API，用于将 JavaScript 引擎嵌入 C++ 程序。通过让维护 JS 引擎的团队也维护 JSI API 实现，我们有信心提供最佳的集成，该集成在 Facebook 的规模下是可靠、高性能且经过实战考验的。
• 使 JavaScript 并发原语（例如 promise）和平台并发原语（例如 微任务）在语义上和性能上都正确，对于 React 并发渲染和 React Native 应用的未来至关重要。历史上，React Native 中的 promise 是使用非标准化的 setImmediate API polyfill 的。我们正在努力通过 JSI 提供 JS 引擎的原生 promise 和微任务，并向平台引入 queueMicrotask（Web 标准中最近新增的功能），以更好地支持现代异步 JavaScript 代码。

带动整个社区

Hermes 在 Facebook 表现非常出色。但我们的工作尚未完成，直到我们的社区能够使用 Hermes 来支持整个生态系统中的体验，这样每个人都可以利用其所有功能并充分发挥其潜力。

扩展到新平台

Hermes 最初只针对 Android 上的 React Native 开源。从那时起，我们很高兴看到社区成员将 Hermes 的支持扩展到 React Native 生态系统已扩展到的许多其他平台。

Callstack 牵头将 Hermes 引入 React Native 0.64 的 iOS 版本。他们撰写了 一系列文章 并主持了一期 播客，讲述了他们是如何实现这一目标的。根据他们的基准测试，对于 Mattermost 应用，与 JSC 相比，Hermes 能够在 iOS 上持续将启动时间提高约 40%，内存使用量减少约 18%，而应用大小开销仅为 2.4 MiB。我鼓励您亲眼看看。

Microsoft 一直在将 Hermes 引入 React Native for Windows 和 macOS。在 Microsoft Build 2020 上，Microsoft 分享说，在 React Native for Windows 上，Hermes 的内存影响（工作集）比 Chakra 引擎低 13%。最近，在一些合成基准测试中，他们发现 Hermes 0.8（随 Hades 和上述 SMI 以及指针压缩优化一起发布）比其他引擎内存使用少 30%-40%。不出所料，基于 React Native 构建的 桌面版 Messenger 视频通话体验也由 Hermes 提供支持。

最后但同样重要的是，Hermes 也一直为所有使用 Oculus 上的 React 技术系列构建的虚拟现实体验提供支持，包括 Oculus Home。

支持我们的社区

我们承认仍然存在阻碍部分社区采用 Hermes 的因素，我们致力于为这些缺失的功能提供支持。我们的目标是功能齐全，以便 Hermes 成为大多数 React Native 应用的正确选择。以下是社区已经塑造 Hermes 路线图的方式：

• Proxy 和 Reflect 最初被排除在 Hermes 之外，因为 Facebook 不使用它们。我们也担心添加 Proxy 会损害属性查找性能，即使不使用 Proxy 也会如此。但 Proxy 很快成为 Hermes 最受请求的功能，这得益于 MobX 和 Immer 等流行库。我们仔细评估并决定仅为社区构建它，并且我们设法以非常低的成本实现了它。由于这是一个我们不使用的功能，我们依赖社区来证明其稳定性。我们首先在标志后面测试 Proxy，并为 v0.4 版本 和 v0.5 版本 创建了选择性 npm 包，并且从 v0.7 版本开始默认启用。
• ECMAScript 国际化 API 规范 (ECMA-402, 或 Intl) 是 第二大最受请求的功能。Intl 是一组庞大的 API，通常需要实现包含 6MB 的 Unicode CLDR 数据。这就是为什么像 FormatJS (又名 react-intl) 这样的 polyfills 和像 社区 JSC 的国际化变体构建 这样的 JS 引擎如此巨大的原因。为了避免大幅增加 Hermes 的二进制大小，我们决定采用另一种策略来实现它，即使用并映射操作系统中包含的库提供的 ICU 功能，代价是在不同平台上的行为会有些（通常是微小的）差异。
  • 微软合作在 Android 上构建了支持。它几乎涵盖了 ECMA-402 直到 ES2020 的所有内容，而大小影响仅为 3% (每个 ABI 57-62K)。我们在 Twitter 上进行了一项民意调查，结果强烈支持默认包含 Intl，所以我们照做了，它从 v0.8 版本开始可用。
  • Facebook 赞助了 Major League Hacking，启动了一个 远程开源奖学金项目。去年，我们发布了 Hermes 采样分析器。今年，我们的研究员将与 Hermes、React Native 和 Callstack 的成员合作，为 iOS 上的 Hermes Intl 添加支持。敬请期待！
• 我们感谢那些与我们合作发现影响社区问题的人。
  • 人们帮助我们发现了关键的规范差异，例如 Array.prototype.sort 的稳定性，这在 ES2019 中得到了修正。此问题已修复，并将在下一版本中提供。
  • 人们发现我们默认的堆大小限制太小，导致许多不熟悉自定义 Hermes GC 配置的用户出现 不必要的 GC 压力 和 OOM 崩溃。因此，我们将其从 512MiB 增加到 3GiB，以默认满足大多数用户的需求。
  • 人们还报告说，我们专门的 Function.prototype.toString 实现 导致不当功能检测的库性能下降，并 阻止用户进行源代码注入。这有助于我们坚定立场，即 Hermes 在可能的情况下不应妨碍开发人员，并应尊重事实上的实践。

总结

总而言之，我们的愿景是让 Hermes 准备好成为所有 React Native 平台的默认 JavaScript 引擎。我们已经开始朝着这个方向努力，我们希望听到大家对此方向的意见。

为生态系统做好平稳过渡的准备对我们来说极其重要。我们鼓励您尝试 Hermes，并在我们的 GitHub 仓库 上提交任何反馈、问题、功能请求和不兼容性问题。

致谢

我们衷心感谢 Hermes 团队、React Native 团队以及 React Native 社区的众多贡献者为改进 Hermes 所做的工作。

我还要特别感谢（按字母顺序）Eli White、Luna Wei、Neil Dhar、Tim Yung、Tzvetan Mikov 以及许多其他在写作过程中提供帮助的人。