自 2019 年首次公布以来，玲珑轻便的 JavaScript 引擎 Hermes 在社区中的名气越来越高，很多的框架也开始反对 Hermes。作为 React Native 畛域高人气元框架的缔造者，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 线程当中还有另一大常见提早起源——垃圾收集（GC）机制。因为一旦开始垃圾收集，整个 JavaScript 引擎必须放下手头的所有工作去执行垃圾收集。

Hermes 当中的原有默认垃圾收集器 GenGC 属于单线程分代垃圾收集计划。其中会对新生代采纳典型的半空间复制策略，而对老年代则应用 mark-compact 策略、从而更被动将内存返还至操作系统。

在像 Facebook for Android 这样的简单利用上，咱们察看到的均匀暂停时长为 200 毫秒，而第 99 百分位暂停则为 1.4 秒。思考到 Facebook for Android 宏大且多样化的用户群体，最极其的暂停工夫甚至长达 7 秒。

为了缓解这种状况，咱们建设起全新的、以并发为次要取向的垃圾回收计划，即 Hades。Hades 同样采纳分代设计，其新生代回收形式与 GenGC 完全相同，而老年代回收形式则通过快照式标记扫描收集器进行治理。

Hades 可能将大部分工作负载交由后盾线程执行，从而显著缩短垃圾回收暂停时长，同时不会阻止引擎主线程继续执行 JavaScript 代码。咱们的统计数据显示，Hades 在 64 位设施上第 99.9 百分位上的提早为 48 毫秒（比 GenGC 快 34 倍！），而在 32 位设施上第 99.9 百分位上的提早约 88 毫秒（以单线程增量 GC 的模式运行）。

但因为须要资源老本更高的写屏障、速度更慢的基于闲暇列表的分配机制（与碰撞指针分配器相同）以及更多的堆碎片，Hades 理论是在用整体吞吐量来换取更短的暂停工夫。咱们认为这样的取舍合乎用户习惯，也将通过合并与接下来将要探讨的其余内存优化机制，实现更低的整体内存占用量。

改善性能问题

应用程序的启动时长对很多利用产品来说至关重要，咱们也心愿一直晋升 React Native 的性能下限。对于在 Hermes 当中实现的所有 JavaScript 性能，咱们都会认真监测它们对生产性能造成的影响，并确保它们不会拉低性能指标。

在 Facebook，咱们目前正在为 Metro 中的 Hermes 试验一个专用的 Babel transform profile，心愿用 Hermes 中的原生 ESNext 实现替换掉本来的十余种 Babel transform。通过这种形式，咱们曾经在间接察看中将 TTI 改良了 18% 至 25%，整体字节码取得显著瘦身；心愿接下来也能在 OSS 中失去相似的后果。

除了启动性能之外，咱们还将内存占用量视为改良 React Native 应用程序的重要机会，这也是成就良好虚拟现实体验的前提。因而在 JavaScript 引擎的底层管制当中，咱们利用压缩位与字节实现了多轮内存优化：

1. 此前，所有 JavaScript 值都被示意为 64 位 NaN 装箱编码的标记值模式，用以示意 64
   位架构上的双精度浮点值与指针。但这种形式在实践中属于微小节约，因为大多数数字理论都属于小整数（SMI），而且客户端应用程序的 JavaScript 堆通常不会大于 4 GiB。为了解决这个问题，咱们引入了一种新的 32 位编码，其中 SMI 与指针以 29 位编码（因为指针为 8 字节对齐，能够假如底部 3 位始终为零），其余的 JS 数字则装箱在堆上。如此一来，JavaScript 的堆大小就缩减了约 30%。
2. 不同类别的 JavaScript 对象在 JS 堆上示意为不同的 GC 治理单元。通过被动优化这些单元头的内存布局，咱们得以将内存占用量进一步削减约 15%。

对此，咱们在 Hermes 中还做出一项要害决定，即不再采纳即时（JIT）编译器。因为咱们认为对于大多数 React Native 应用程序来说，额定的预热老本与额定的二进制文件乃至内存占用量并没有实际意义。

多年以来，咱们在解释器性能与编译器的优化方面投入了大量精力，也让 Hermes 取得了远超其余引擎的 React Native 工作负载吞吐量劣势。咱们将持续关注宽泛存在的性能瓶颈（解释器调度循环、堆栈布局、对象模型、垃圾回收等）以进步吞吐量。

垂直整合畛域

在 Facebook，咱们习惯于应用大型 monorepo 托管我的项目。通过将引擎（Hermes）与 host（React Native）严密迭代在一起，当初咱们为垂直整合开拓出广大空间。以下是几个具体的例子：

• Hermes 应用 Chrome DevTools 协定反对应用 Chrome 调试器在设施上执行 JavaScript 调试。这种办法比传统“近程 JS 调试”（应用利用内代理在桌面 Chrome 上运行 JS）成果更好，因为它反对调试同步本机调用并能保障对立的运行时环境。与 React DevTools、Metro 以及 Inspector 等一道，Hermes 调试器现已成为 Flipper 中的组成部分，独特提供良好的一站式开发者体验。
• 在 React Native 利用的初始化门路中调配的对象往往长期存在，而且并不合乎分代 GC 所提出的分代假如。因而，咱们在 React Native 中配置 Hermes 时，会将前 32 MiB 间接调配至老年代（即 pre-tenuring）以防止触发 GC 暂停与提早 TTI。
• 新的 React Native 架构在很大水平上基于 JSI（即 JavaScript Interface），这是一种轻量级通用 API，用于将 JavaScript 引擎嵌入至 C++ 程序当中。通过让保护 JS 引擎的团队同时保护 JSI API 实现，咱们有信念提供最佳集成成果。而且这套集成计划曾经在 Facebook 的大规模业务之上通过实战测试，领有良好的可靠性与运行效率。
• 领有语义正确且性能良好的 JavaScript 并发原语（例如 promises）及平台并发原语（例如 microtasks），对于 React 并发渲染以及 React Native 应用程序的将来倒退堪称至关重要。从历史上看，React Native 中的 promise 是应用非标准化 setImmediate API 作为腻子脚本。咱们正致力通过 JSI 实现来自 JS 引擎的原生 promises 和 microtasks，并将 queueMicrotask（Web 规范中的新增我的项目）引入平台，从而更好地反对古代异步 JavaScript 代码。

社区倒退

Facebook 公司非常重视 Hermes 我的项目，但只有为 Hermes 建设起残缺的生态系统、特地是技术社区，开发工作才算真正告一段落。也只有这样，每个人才能充分运用 Hermes 的性能并施展其后劲。

扩大至更多新平台

Hermes 最后仅面向 React Native on Android 开源。在此之后，咱们很快乐看到社区成员们逐步拓展 Hermes 的反对范畴，目前曾经将其扩大到 React Native 生态系统所笼罩的多种其余平台。

Callstack 率先在 React Native 0.64 当中将 Hermes 引入 iOS。他们还公布了系列专题文章，并发动播客向用户们介绍他们如何实现这一指标。依据基准测试，与 Mattermost 利用的 JSC 相比，Hermes 在 iOS 上的启动性能可稳固晋升约 40%、内存占用量减少约 18%、利用程序运行期间的内存用量仅为 2.4 MiB。

微软则一直将 Hermes 引入 Windows 与 MacOS 上的 React Native。在微软 Build 2020 大会上，软件巨头示意相较于本来的 Chakra 引擎，Hermes 可能将 React Native for Windows 的内存占用量升高 13%。而在最近的一些综合基准测试中，微软发现 Hermes 0.8（蕴含 Hades 及之前提到的 SMI 与指针压缩优化性能）占用的内存量比其余引擎少 30% 至 40%。毫无疑问，基于 React Native 的桌面版 Messenger 视频通话体验也在 Hermes 的反对下失去显著改善。

更重要的是，Hermes 还始终在为 Oculus 上应用 React 系列技术构建的各类虚拟现实体验提供反对，其中也包含 Oculus Home。

社区反对

咱们抵赖，目前 Hermes 身上仍有一些问题妨碍着更多社区的顺畅染指，咱们也在致力为这些缺失的性能建设反对。咱们的指标是尽快实现性能齐备，让 Hermes 成为大多数 React Native 应用程序的最佳抉择。以下是社区正在策划的 Hermes 倒退路线图：

• 因为 Facebook 并不应用，所以 Proxy 与 Reflect 最后被排除在 Hermes 之外。咱们过后放心即便不真正应用，贸然增加 Proxy 也会侵害属性查找性能。但随着 MobX 与 Immer 等库的风行，Proxy 很快成为 Hermes 当中最受欢迎的性能。通过认真评估，咱们决定针对社区提供专用 Proxy，而且设法以极低的老本实现实现。因为 Facebook 并不应用此性能，所以只能依附技术社区证实其稳定性。咱们首先在 0.4 与 0.5 版本中以标记和创立 opt-in npm 包的模式启动了 Proxy 测试，并从 0.7 版本开始将其默认启用。
• ECMAScript 国际化 API 标准（简称 ECMA-402 或 Intl）同样是用户呼声中的焦点。Intl 代表一组宏大的 API，通常须要蕴含 6 MB 大小的 Unicode CLDR 数据能力实现。正因为如此，FormatJS（又名 react-intl）等腻子脚本以及社区 JSC 的国内变体 build 等 JS 引擎才如此臃肿蠢笨。为了防止 Hermes 二进制文件体积的不必要收缩，咱们决定间接应用并映射操作系统内置库所提供的 ICU facilities 来实现，相应的代价就是给某些跨平台行为引入一些（通常较为渺小的）差别。
• 微软单干实现了 Android 上的 build 反对工作。其中简直涵盖从 ECMA-402 到 ES2020 的所有内容，而对体积的影响仅有 3%（每个 ABI 仅为 57 K 到 62 K）。咱们在 Twitter 上发动的民意调查发现，用户们强烈反对默认蕴含 Intl，所以咱们决定从 0.8 版本开始引入这项性能。
• Facebook 曾经资助 Major League Hacking 发动近程开源奖学金打算。去年，咱们推出了 Hermes 采样分析器；往年，咱们的研究员将与 Hermes、React Native 以及 Callstack 的成员们单干，在 iOS 上实现对 Hermes Intl 的反对。
• 感激大家反馈中提到的默认堆大小下限太低问题，导致很多不相熟自定义 Hermes GC 配置的用户会产生不必要的 GC 压力乃至 OOM 解体。因而在默认状况下，咱们将下限由 512 MiB 减少到 3 GiB，这样的配置对大多数用户来说应该入不敷出。
• 有报告称，咱们专用的 Function.prototype.toString 实现会导致库执行不正确的特色检测并导致性能降落，而且令用户无奈执行源代码注入。在解决问题的同时，咱们也更加动摇了 Hermes 应该尊重事实、尽量避免障碍开发者顺畅应用的信心。

总结

总之，咱们的愿景是让 Hermes 成为所有 React Native 平台上的默认 JavaScript 引擎。咱们正在朝着这个方向致力，也心愿充沛听取大家来自不同角度的反馈意见。

只有做好万全筹备，咱们能力为生态系统宽泛接收 Hermes 奠定松软的根底。在这里，咱们诚邀大家体验 Hermes，并将您发现的所有倡议、意见、性能申请与不兼容性谬误提交给咱们的 GitHub repo。

原文链接：Toward Hermes being the Default