跳至主要内容

React Native 在 Marketplace 中的性能

·阅读时间：5 分钟
Aaron Chiu
Facebook 软件工程师

React Native 用于 Facebook 家族中多个应用的多个位置，包括 Facebook 主应用中的顶级标签。本文重点介绍一个高度可见的产品，Marketplace。它在十几个国家/地区可用，使用户能够发现其他用户提供的产品和服务。

在 2017 年上半年，通过 Relay 团队、Marketplace 团队、移动 JS 平台团队和 React Native 团队的共同努力，我们使 Android 2010-11 年级设备 的 Marketplace 交互时间 (TTI) 减少了一半。Facebook 从历史上将这些设备视为低端 Android 设备，它们在任何平台或设备类型上都具有最慢的 TTI。

典型的 React Native 启动过程如下所示

免责声明：比率不具有代表性，并且会根据 React Native 的配置和使用方式而有所不同。

我们首先初始化 React Native 核心（又名“桥”），然后运行特定于产品的 JavaScript，该 JavaScript 确定 React Native 将在原生处理时间内呈现哪些原生视图。

不同的方法​

我们早期犯的一个错误是让 Systrace 和 CTScan 驱动我们的性能工作。这些工具帮助我们在 2016 年找到了很多唾手可得的成果，但我们发现 Systrace 和 CTScan **不能代表生产场景**，也不能模拟现实环境中发生的情况。时间在不同部分的占比通常是不正确的，有时甚至完全偏离目标。极端情况下，我们预计需要几毫秒才能完成的事情实际上需要数百或数千毫秒。也就是说，CTScan 很有用，我们发现它可以在错误进入生产环境之前捕获三分之一的错误。

在 Android 上，我们将这些工具的缺点归因于以下事实：1) React Native 是一个多线程框架，2) Marketplace 与众多复杂的视图（例如 Newsfeed 和其他顶级标签）共存，以及 3) 计算时间差异很大。因此，在本学期中，我们让生产测量和细分几乎驱动了我们所有的决策和优先级。

生产环境监控之路​

从表面上看，监控生产环境可能很简单，但事实证明这是一个相当复杂的过程。它经历了多个 2-3 周的迭代周期；由于将提交代码合并到主分支的延迟，到将应用推送到 Play 商店，再到收集足够的生产样本以对我们的工作充满信心。每个迭代周期都涉及发现我们的细分是否准确，它们是否具有合适的粒度，以及它们是否正确地加总到整个时间跨度。我们不能依赖 Alpha 和 Beta 版本，因为它们不能代表普通用户群体。从本质上讲，我们非常细致地构建了一个基于数百万个样本的聚合的非常准确的生产跟踪。

我们一丝不苟地验证细分中的每一毫秒都正确地加总到其父指标的原因之一是，我们很早就意识到我们的监控存在差距。事实证明，我们的初始细分没有考虑线程跳转导致的停顿。线程跳转本身并不昂贵，但跳转到已经繁忙且正在工作的线程上非常昂贵。我们最终通过在正确的时间点添加 Thread.sleep() 调用来在本地复制这些阻塞，并通过以下方式成功修复了这些问题：

  1. 取消对 AsyncTask 的依赖，
  2. 撤消在 UI 线程上强制初始化 ReactContext 和 NativeModules 的操作，以及
  3. 取消对在初始化时测量 ReactRootView 的依赖。

总而言之，消除这些线程阻塞问题将启动时间缩短了 25% 以上。

生产指标也挑战了我们之前的一些假设。例如，我们过去曾在启动路径上预加载许多 JavaScript 模块，假设将模块放在一个捆绑包中可以降低其初始化成本。但是，预加载和将这些模块放在一起的成本远远超过了收益。通过重新配置我们的内联 require 黑名单并从启动路径中删除 JavaScript 模块，我们能够避免加载不必要的模块，例如 Relay Classic（当只需要 Relay Modern 时）。如今，我们的 RUN_JS_BUNDLE 细分速度提高了 75% 以上。

我们还在调查特定于产品的原生模块时发现了成果。例如，通过延迟注入原生模块的依赖项，我们将该原生模块的成本降低了 98%。通过消除 Marketplace 启动与其他产品的竞争，我们将启动时间缩短了等效的时间段。

最棒的是，许多这些改进广泛适用于所有使用 React Native 构建的屏幕。

结论​

人们认为 React Native 启动性能问题是由 JavaScript 速度慢或网络时间过长造成的。虽然加快 JavaScript 等操作会使 TTI 下降一个不小的数字，但这些因素对 TTI 的贡献比例都远低于之前的预期。

到目前为止，教训是**测量、测量、再测量！**一些成果来自将运行时成本转移到构建时间，例如 Relay Modern 和 Lazy NativeModules。其他成果来自通过更智能地并行化代码或删除死代码来避免工作。还有一些成果来自对 React Native 进行大的架构更改，例如清理线程阻塞。性能没有万能的解决方案，长期性能提升将来自增量的监控和改进。不要让认知偏差影响您的决策。相反，要仔细收集和解释生产数据以指导未来的工作。

未来计划​

从长远来看，我们希望 Marketplace TTI 能够与使用原生构建的类似产品相媲美，并且总体上使 React Native 的性能与原生性能相当。此外，尽管在本季度我们通过桥接启动成本降低了约 80%，但我们计划通过 Prepack 等项目以及更多构建时处理来将 React Native 桥接的成本降至接近零。