跳至主要内容

将 Hermes 作为默认引擎

·12 分钟阅读
Xuan Huang
Xuan Huang
Meta 软件工程师

自从 我们在 2019 年宣布 Hermes 以来，它在社区中的采用率越来越高。Expo 团队维护着一个流行的 React Native 应用元框架，他们最近宣布实验性 支持 Hermes，此前 Hermes 一直是 Expo 最受请求的功能之一。Realm 团队是一个流行的移动数据库，最近也发布了其对 Hermes 的 alpha 支持。在这篇文章中，我们想重点介绍过去两年中我们在推动 Hermes 成为 React Native 最佳 JavaScript 引擎方面取得的一些最令人兴奋的进展。展望未来，我们相信，通过这些改进以及未来更多的改进，我们可以使 Hermes 成为所有平台上 React Native 的默认 JavaScript 引擎。

为 React Native 优化​

Hermes 的决定性特征在于它如何提前执行编译工作，这意味着启用 Hermes 的 React Native 应用会附带预编译的优化字节码，而不是纯 JavaScript 源代码。这大大减少了为用户启动产品所需的工作量。来自 Facebook 和社区应用的测量表明，启用 Hermes 通常可以将产品的 TTI（或 Time-To-Interactive）指标缩短近一半。

话虽如此，我们一直在努力改进 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 位设备上，p99.9 时约为 88 毫秒（它在 32 位设备上作为单线程增量 GC 运行）。这些暂停时间的改进可能会以整体吞吐量为代价，因为需要更昂贵的写入屏障、更慢的基于空闲列表的分配（而不是 bump 指针分配器）以及堆碎片增加。我们认为这些是正确的权衡，并且我们能够通过合并和我们稍后将讨论的其他内存优化来实现整体更低的内存消耗。

解决性能痛点​

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

除了启动性能之外，我们还发现内存占用是 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）更好，因为它支持调试同步原生调用并保证一致的运行时环境。Hermes 调试器与 React DevTools、Metro、Inspector 等一起，现在是 Flipper 的一部分，以提供一站式开发者体验。
  • 在 React Native 应用的初始化路径期间分配的对象通常是长寿命的，并且不遵循分代 GC 利用的分代假设。因此，我们 在 React Native 中配置 Hermes，将前 32MiB 直接分配到老年代（称为预先分配），以避免触发 GC 暂停并延迟 TTI。
  • 新的 React Native 架构很大程度上基于 JSI（或 JavaScript 接口），这是一个轻量级、通用 API，用于将 JavaScript 引擎嵌入到 C++ 程序中。通过让维护 JS 引擎的团队也维护 JSI API 实现，我们有信心提供最佳的集成，该集成在 Facebook 的规模下是可靠、高性能且经过实战检验的。
  • 使 JavaScript 并发原语（例如 Promise）和平台并发原语（例如 微任务）在语义上正确且性能良好，对于 React 并发渲染和 React Native 应用的未来至关重要。从历史上看，React Native 中的 Promise 是使用非标准的 setImmediate API 进行 polyfill 的。我们正在努力使来自 JS 引擎的本机 Promise 和微任务通过 JSI 可用，并向平台引入 queueMicrotask，这是 Web 标准的最新补充，以更好地支持现代异步 JavaScript 代码。

携手整个社区​

Hermes 对我们在 Facebook 来说非常棒。但在我们的社区能够使用 Hermes 为整个生态系统中的体验提供动力之前，我们的工作尚未完成，以便每个人都能利用其所有功能并充分发挥其潜力。

扩展到新平台​

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

Callstack 领导了将 Hermes 引入 React Native 0.64 中的 iOS 的工作。他们撰写了 一系列文章 并主持了一个 播客，讲述了他们是如何实现这一目标的。根据他们的基准测试，与 JSC 相比，Hermes 能够在 iOS 上的 Mattermost 应用中 持续提供约 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 还为所有使用 React 技术家族在 Oculus 上构建的虚拟现实体验提供支持，包括 Oculus Home。

支持我们的社区​

我们承认仍然存在一些障碍阻止社区的部分成员采用 Hermes，并且我们致力于构建对这些缺失功能的支持。我们的目标是功能齐全，以便 Hermes 成为大多数 React Native 应用的正确选择。以下是社区如何塑造 Hermes 路线图的：

总结​

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

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

感谢​

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

我也想亲自感谢（按字母顺序排列）Eli White、Luna Wei、Neil Dhar、Tim Yung、Tzvetan Mikov 和许多其他人在写作过程中的帮助。