跳到主要内容

市场中的 React Native 性能

·6 分钟阅读
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 核心（即“Bridge”），然后运行特定于产品的 JavaScript，它决定了 React Native 将在原生处理时间中渲染哪些原生视图。

一种不同的方法​

我们早期犯的一个错误是让 Systrace 和 CTScan 驱动我们的性能工作。这些工具在2016年帮助我们找到了许多唾手可得的成果，但我们发现 Systrace 和 CTScan 都不代表生产场景，无法模拟实际发生的情况。细分的时间比例通常是不正确的，有时甚至离谱。在极端情况下，我们预期只需几毫秒的事情实际上却需要数百或数千毫秒。即便如此，CTScan 仍然有用，我们发现它能在三分之一的回归进入生产环境之前捕获它们。

在 Android 上，我们将这些工具的缺点归因于以下事实：1) React Native 是一个多线程框架；2) Marketplace 与新闻源和其他顶级标签页等多种复杂视图并存；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 和 惰性原生模块。另一些成功来自于通过更智能地并行化代码或删除死代码来避免工作。还有一些成功来自于 React Native 的重大架构更改，例如清理线程阻塞。性能没有万能的解决方案，长期的性能提升将来自于渐进式的检测和改进。不要让认知偏见影响您的决策。相反，仔细收集和解释生产数据，以指导未来的工作。

未来计划​

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