跳到主要内容

Hermes 迈向默认引擎

·14 分钟阅读
Xuan Huang
黄轩
Meta 软件工程师

自从我们于 2019 年宣布推出 Hermes以来，它在社区中的采用率不断提高。Expo 团队维护着一个流行的 React Native 应用程序元框架，他们最近宣布实验性地支持 Hermes，此前它一直是Expo 最受请求的功能之一。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 暂停。在像 Facebook for Android 这样复杂的应用程序上，我们观察到平均暂停时间为 200 毫秒，在 P99 时为 1.4 秒。考虑到 Facebook for Android 庞大而多样化的用户群，我们甚至看到它长达 7 秒。

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

解决性能痛点​

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

除了启动性能，我们还发现内存占用是 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，我们倾向于将项目放在一个大型单一仓库中。通过让引擎 (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 接口），它是一种轻量级、通用 API，用于将 JavaScript 引擎嵌入到 C++ 程序中。通过让维护 JS 引擎的团队也维护 JSI API 实现，我们有信心提供最佳的集成，该集成在 Facebook 的规模下是可靠、高性能且经过实战考验的。
  • 正确且高性能地实现 JavaScript 并发原语（例如Promise）和平台并发原语（例如微任务）对于 React 并发渲染和未来 React Native 应用程序至关重要。历史上，React Native 中的 Promise 是使用非标准化的 `setImmediate` API 进行Polyfill的。我们正在努力通过 JSI 提供 JS 引擎的原生 Promise 和微任务，并将最近添加到 Web 标准中的 `queueMicrotask` 引入平台，以更好地支持现代异步 JavaScript 代码。

携手整个社区​

Hermes 对我们 Facebook 来说一直非常棒。但只有当我们的社区能够使用 Hermes 来驱动整个生态系统的体验，让每个人都能利用其所有功能并充分发挥其潜力时，我们的工作才算完成。

扩展到新平台​

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

Callstack 牵头将 Hermes 带到 React Native 0.64 的 iOS 版本。他们撰写了一系列文章并主持了播客，讲述他们是如何实现这一目标的。根据他们的基准测试，Hermes 能够为 Mattermost 应用程序持续提供约 40% 的启动性能提升和约 18% 的 iOS 内存占用减少，而应用程序大小开销仅为 2.4 MiB。我鼓励您亲眼看看。

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

最后但同样重要的是，Hermes 也一直为 Oculus 上所有使用 React 技术系列构建的虚拟现实体验提供支持，包括 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 以及其他许多人在写作过程中提供的帮助。