Facebook 的 React Native 团队遵循一些原则，这些原则有助于确定我们在 React Native 上的工作优先级。这些原则仅代表我们团队，不一定代表 React Native 社区中的所有利益相关者。我们在此分享这些原则，以便更透明地说明驱动我们的因素、我们如何做决策以及我们如何集中精力。

原生体验​

我们对 React Native 的首要任务是匹配人们对每个平台的期望。这就是 React Native 渲染到平台原生控件的原因。我们更看重原生外观和感觉，而不是跨平台一致性。

例如，React Native 中的 TextInput 在 iOS 上渲染为 UITextField。这确保了与密码管理器和键盘控件的集成开箱即用。通过使用平台原生控件，React Native 应用也能够及时更新 Android 和 iOS 新版本的设计和行为变化。

为了匹配原生应用的外观和感觉，我们也必须匹配它们的性能。这是我们最雄心勃勃的努力重点。例如，Facebook 创建了 Hermes，一个从头开始为 Android 上的 React Native 构建的新 JavaScript 引擎。Hermes 显著改善了 React Native 应用的启动时间。我们还在进行重大的架构更改，以优化线程模型并使 React Native 更容易与原生代码互操作。

大规模应用​

Facebook 应用中的数百个屏幕都是用 React Native 实现的。Facebook 应用被数十亿人使用在各种各样的设备上。这就是为什么我们投资于最具挑战性的大规模问题。

在我们的应用中部署 React Native 让我们能够发现小规模下不会出现的问题。例如，Facebook 专注于提高从最新 iPhone 到许多老一代 Android 设备等各种设备的性能。这种关注促成了我们的架构项目，如 Hermes、Fabric 和 TurboModules。

我们已经证明 React Native 也可以扩展到大型组织。当数百名开发人员在同一个应用上工作时，渐进式采用是必须的。这就是为什么我们确保 React Native 可以一次采用一个屏幕。很快，我们将更进一步，使现有原生屏幕的单个原生视图能够迁移到 React Native。

专注于大规模意味着我们团队目前没有在许多事情上投入工作。例如，我们的团队不推动 React Native 在行业中的采用。我们也不积极为我们没有大规模看到的问题构建解决方案。我们很自豪我们有许多合作伙伴和核心贡献者能够专注于社区的这些重要领域。

开发人员效率​

出色的用户体验是迭代创建的。在运行中的应用中看到代码更改的结果应该只需要几秒钟。 React Native 的架构使其能够在开发过程中提供近乎即时的反馈。

我们经常从团队那里听说，采用 React Native 显著提高了他们的开发效率。这些团队发现，开发过程中的即时反馈使得尝试不同的想法和添加额外优化变得容易得多，因为他们不必为了每一个小小的更改而中断他们的编码会话。当我们对 React Native 进行更改时，我们确保保留这种开发人员体验的质量。

即时反馈并不是 React Native 提高开发人员效率的唯一方式。团队可以利用快速增长的高质量开源包生态系统。团队还可以在 Android、iOS 和 Web 之间共享业务逻辑。这有助于他们更快地发布更新并减少平台团队之间的组织孤岛。

每个平台​

当我们于 2014 年推出 React Native 时，我们提出了我们的座右铭“一次学习，随处编写”——我们指的是任何地方。开发者应该能够接触到尽可能多的人，而不受设备型号或操作系统的限制。

React Native 针对非常不同的平台，包括移动、桌面、Web、电视、VR、游戏机等。我们希望在每个平台上实现丰富的体验，而不是要求开发者为最低共同点构建。为了实现这一点，我们专注于支持每个平台的独特功能。这包括不同的输入机制（例如触摸、笔、鼠标）到 VR 中根本不同的消费体验（例如 3D 环境）。

这一原则促使我们决定用跨平台 C++ 实现 React Native 的新核心架构，以促进跨平台的一致性。我们还在完善面向其他平台维护者（如 Microsoft 的 Windows 和 macOS）的公共接口。我们努力使任何平台都能支持 React Native。

声明式 UI​

我们不相信在每个平台上都部署完全相同的用户界面，我们相信以相同的声明式编程模型暴露每个平台的独特功能。我们的声明式编程模型就是 React。

根据我们的经验，React 普及的单向数据流使应用程序更易于理解。我们倾向于将屏幕表达为声明式组件的组合，而不是命令式管理的视图。React 在 Web 上的成功以及新的原生 Android 和 iOS 框架的发展方向表明，行业也已接受声明式 UI。

React 普及了声明式用户界面。然而，仍然有许多未解决的问题是 React 独特地能够解决的。React Native 将继续在 React 的创新基础上发展，并保持在声明式用户界面运动的前沿。

今天我们发布了 React Native 0.63，默认启用了 LogBox。

LogBox​

我们经常收到社区反馈，称 React Native 中的错误和警告难以调试。为了解决这些问题，我们审查了 React Native 中的整个错误、警告和日志系统，并从头开始重新设计了它。

LogBox 是 React Native 中完全重新设计的红框、黄框和日志体验。在 0.62 版本中，我们引入了 LogBox 作为可选功能。在这个版本中，我们正式将 LogBox 作为 React Native 中所有体验的默认设置。

LogBox 通过关注三个主要目标，解决了错误和警告过于冗长、格式不佳或无法操作的抱怨

• 简洁：日志应提供调试问题所需的最小信息量。
• 格式化：日志应格式化，以便您可以快速找到所需信息。
• 可操作：日志应可操作，以便您可以修复问题并继续。

为了实现这些目标，LogBox 包含

• 日志通知：我们重新设计了警告通知并增加了对错误的支持，因此所有 console.warn 和 console.log 消息都显示为通知，而不是覆盖您的应用。
• 代码帧：每个错误和警告现在都包含一个代码帧，在应用内直接显示日志的源代码，让您快速识别问题的来源。
• 组件栈：所有组件栈现在都从错误消息中剥离出来，并放入其自己的部分，只显示前三帧。这为您提供了一个单一、一致的空间来查看栈帧信息，而不会使日志消息混乱。
• 栈帧折叠：默认情况下，我们现在折叠与您的应用程序代码无关的调用栈帧，以便您可以快速查看应用程序中的问题，而无需筛选 React Native 内部信息。
• 语法错误格式化：我们改进了语法错误的格式化，并添加了带有语法高亮的代码帧，以便您可以查看错误的来源，修复它，并继续编码，而 React Native 不会妨碍您。

我们将所有这些功能封装在一个改进的视觉设计中，该设计在错误和警告之间保持一致，并允许在愉快的 UI 中分页浏览所有日志。

通过此更改，我们还将弃用 YellowBox，转而使用 LogBox API。

• LogBox.ignoreLogs()：此函数取代了 YellowBox.ignoreLogs([])，用于静默匹配给定字符串或正则表达式的任何日志。
• LogBox.ignoreAllLogs()：此函数取代了 console.disableYellowBox，用于关闭错误或警告通知。注意：这仅禁用通知，未捕获的错误仍将打开全屏 LogBox。

在 0.63 版本中，我们将在使用这些已弃用的模块或方法时发出警告。请在 0.64 版本中删除这些 API 之前更新您的调用站点。

有关 LogBox 和调试 React Native 的更多信息，请参阅此处的文档。

Pressable​

React Native 的构建旨在使应用程序满足用户对平台的期望。这包括避免“痕迹”——那些透露体验是用 React Native 构建的小细节。这些痕迹的主要来源一直是 Touchable 组件：Button、TouchableWithoutFeedback、TouchableHighlight、TouchableOpacity、TouchableNativeFeedback 和 TouchableBounce。这些组件通过允许您向用户交互提供视觉反馈来使您的应用程序具有交互性。然而，由于它们包含内置样式和效果，与平台交互不匹配，用户可以判断体验是否是用 React Native 编写的。

此外，随着 React Native 的发展和我们对高质量应用程序的要求提高，这些组件并没有随之发展。React Native 现在支持 Web、桌面和电视等平台，但对附加输入方式的支持一直不足。React Native 需要在所有平台上支持高质量的交互体验。

为了解决这些问题，我们正在推出一个新的核心组件，名为 Pressable。这个组件可以用于检测各种类型的交互。API 的设计旨在直接访问当前的交互状态，而无需在父组件中手动维护状态。它还旨在使平台能够扩展其功能，包括悬停、失焦、聚焦等。我们预计大多数人会构建和共享利用 Pressable 的底层组件，而不是依赖于像 TouchableOpacity 这样的默认体验。

import {Pressable, Text} from 'react-native';

<Pressable
  onPress={() => {
    console.log('pressed');
  }}
  style={({pressed}) => ({
    backgroundColor: pressed ? 'lightskyblue' : 'white',
  })}>
  <Text style={styles.text}>Press Me!</Text>
</Pressable>;

一个 Pressable 组件的简单示例

您可以从文档中了解更多信息。

原生颜色 (PlatformColor, DynamicColorIOS)​

每个原生平台都有系统定义的颜色概念。这些颜色会自动响应系统主题设置，例如浅色或深色模式，辅助功能设置，例如高对比度模式，甚至其在应用程序中的上下文，例如包含视图或窗口的特征。

虽然可以通过 Appearance API 和/或 AccessibilityInfo 检测其中一些设置并相应地设置样式，但此类抽象不仅开发成本高昂，而且只是近似原生颜色外观。当在混合应用程序中工作时，这些不一致之处尤其明显，React Native 元素与原生元素并存。

React Native 现在提供了一个开箱即用的解决方案来使用这些系统颜色。PlatformColor() 是一个新的 API，可以像 React Native 中的任何其他颜色一样使用。

例如，在 iOS 上，系统提供了一种名为 labelColor 的颜色。它可以在 React Native 中与 PlatformColor 结合使用，如下所示

import {Text, PlatformColor} from 'react-native';

<Text style={{color: PlatformColor('labelColor')}}>
  This is a label
</Text>;

将 Text 组件的颜色设置为 iOS 定义的 labelColor。

另一方面，Android 提供了像 colorButtonNormal 这样的颜色。您可以在 React Native 中使用这种颜色

import {View, Text, PlatformColor} from 'react-native';

<View
  style={{
    backgroundColor: PlatformColor('?attr/colorButtonNormal'),
  }}>
  <Text>This is colored like a button!</Text>
</View>;

将 View 组件的背景颜色设置为 Android 定义的 colorButtonNormal。

您可以从文档中了解更多关于 PlatformColor 的信息。您也可以查看 RNTester 中存在的实际代码示例。

DynamicColorIOS 是一个仅限 iOS 的 API，允许您定义在浅色和深色模式下使用的颜色。类似于 PlatformColor，这可以在任何可以使用颜色的地方使用。DynamicColorIOS 底层使用 iOS 的 colorWithDynamicProvider。

import {Text, DynamicColorIOS} from 'react-native';

const customDynamicTextColor = DynamicColorIOS({
  dark: 'lightskyblue',
  light: 'midnightblue',
});

<Text style={{color: customDynamicTextColor}}>
  This color changes automatically based on the system theme!
</Text>;

根据系统主题改变文本颜色

您可以从文档中了解更多关于 DynamicColorIOS 的信息。

放弃对 iOS 9 和 Node.js 8 的支持​

发布四年多后，我们放弃了对 iOS 9 的支持。这一变化将使我们能够更快地前进，因为可以减少在原生代码中放置的兼容性检查数量，以检测给定功能是否在特定 iOS 版本上受支持。鉴于其 1% 的市场份额，它对您的客户不会产生太大负面影响。

同时，我们放弃了对 Node 8 的支持。其 LTS 维护周期已于 2019 年 12 月到期。目前的 LTS 版本是 Node 10，这也是我们现在正在瞄准的版本。如果您仍在为 React Native 应用程序的开发使用 Node 8，我们鼓励您升级以接收所有最新的安全修复和更新。

其他值得注意的改进​

• 支持在 <Text /> 中渲染 <View /> 而无需明确大小：您现在可以在任何 <Text /> 组件内渲染任何 <View />，而无需明确设置其宽度和高度，这以前并非总是可能的。在之前的 React Native 版本中，这会导致 RedBox。
• 将 iOS LaunchScreen 从 xib 更改为 storyboard：从 2020 年 4 月 30 日起，所有提交到 App Store 的应用程序都必须使用 Xcode storyboard 提供应用程序的启动屏幕，并且所有 iPhone 应用程序都必须支持所有 iPhone 屏幕。此提交调整了默认的 React Native 模板，使其与此要求兼容。

致谢​

感谢数百名贡献者帮助 0.63 版本成为可能！

特别感谢 Rick Hanlon 撰写了 LogBox 部分，以及 Eli White 撰写了本文的 Pressable 部分。

要查看所有更新，请查阅 0.63 更新日志。

今天我们发布了 React Native 0.62 版本，其中默认包含对 Flipper 的支持。

此次发布正值全球大流行之际。我们今天发布此版本是为了尊重数百名贡献者的辛勤工作，他们使此版本成为可能，并防止发布落后主分支太远。请注意贡献者协助解决问题的能力有限，并在必要时准备延迟升级。

默认启用 Flipper​

Flipper 是一款用于调试移动应用的开发工具。它在 Android 和 iOS 社区中广受欢迎，在此版本中，我们为新的和现有的 React Native 应用默认启用了支持。

Flipper 开箱即用，提供以下功能

• Metro 操作：直接从工具栏重新加载应用程序并触发开发菜单。
• 崩溃报告器：查看 Android 和 iOS 设备的崩溃报告。
• React DevTools：将最新版本的 React DevTools 与您的所有其他工具一起使用。
• 网络检查器：查看设备应用程序发出的所有网络请求。
• Metro 和设备日志：查看、搜索和过滤来自 Metro 和设备的所有日志。
• 原生布局检查器：查看和编辑 React Native 渲染器输出的原生布局。
• 数据库和偏好设置检查器：查看和编辑设备数据库和偏好设置。

此外，由于 Flipper 是一个可扩展的平台，它提供了一个从 NPM 拉取插件的市场，因此您可以发布和安装特定于您的工作流程的自定义插件。在此处查看可用的插件：https://npmjs.net.cn/search?q=flipper-plugin。

更多信息，请查阅 Flipper 文档。

新的深色模式功能​

我们添加了一个新的 Appearance 模块，以提供对用户外观偏好设置的访问，例如他们首选的配色方案（浅色或深色）。

const colorScheme = Appearance.getColorScheme();
if (colorScheme === 'dark') {
  // Use dark color scheme
}

我们还添加了一个 Hook 来订阅用户偏好设置的状态更新

import {Text, useColorScheme} from 'react-native';

const MyComponent = () => {
  const colorScheme = useColorScheme();
  return <Text>useColorScheme(): {colorScheme}</Text>;
};

更多信息请参见 Appearance 和 useColorScheme 的文档。

将 Apple TV 移至 react-native-tvos​

作为我们瘦核心工作的一部分，并使 Apple TV 与 React Native Windows 和 React Native macOS 等其他平台保持一致，我们已开始从核心中删除 Apple TV 特定代码。

今后，React Native 的 Apple TV 支持将由 react-native-community/react-native-tvos 和相应的 react-native-tvos NPM 包维护。这是主仓库的一个完整分支，仅包含支持 Apple TV 所需的更改。

react-native-tvos 的发布将基于 React Native 的公开版本。对于 react-native 的 0.62 版本，请将 Apple TV 项目升级到使用 react-native-tvos 0.62。

更多升级支持​

当 0.61 发布时，社区引入了一个新的升级助手工具，以支持开发人员升级到新版本的 React Native。升级助手提供了从您当前版本到目标版本的更改差异，让您可以看到特定升级所需进行的更改。

即使有了这个工具，升级时仍然会出现问题。今天，我们通过宣布 Upgrade-Support 来提供更专业的升级支持。Upgrade Support 是一个 GitHub 问题跟踪器，用户可以在其中提交与其项目升级相关的特定问题，以获得社区的帮助。

我们一直在努力改进升级体验，我们希望这些工具能为用户提供他们尚未覆盖的边缘情况所需的支持。

其他改进​

• LogBox：我们正在添加新的 LogBox 错误和警告体验作为可选功能；要启用它，请将 require('react-native').unstable_enableLogBox() 添加到您的 index.js 文件中。
• React DevTools v4：此更改包括升级到最新版 React DevTools，它提供了显著的性能提升、改进的导航体验以及对 React Hooks 的全面支持。
• 可访问性改进：我们对可访问性进行了改进，包括添加了 accessibilityValue，在 Touchable 组件上缺失的 prop，onSlidingComplete 的 可访问性事件，以及将 Switch 组件的默认角色从 "button" 更改为 "switch"。

重大变更​

• 移除 PropTypes：我们正在从核心组件中移除 propTypes，以减少 React Native 核心对应用大小的影响，并倾向于在编译时而非运行时进行检查的静态类型系统。
• 移除 accessibilityStates：我们已经移除了已弃用的 accessibilityStates 属性，转而使用新的 accessibilityState prop，这是一种更具语义性的方式，用于组件向可访问性服务描述其状态信息。
• TextInput 变更：我们从 TextInput 中移除了 onTextInput，因为它不常见，不符合 W3C 标准，并且难以在 Fabric 中实现。我们还移除了未文档化的 inputView prop 和 selectionState。

弃用​

• AccessibilityInfo.fetch 已经弃用，但在此版本中我们添加了警告。
• 现在需要设置 useNativeDriver 以支持将来切换默认值。
• Animated 组件的 ref 现在是内部组件，并且弃用了 getNode。

致谢​

感谢数百名贡献者，他们共同促成了 0.62 版本的发布！

要查看所有更新，请查阅 0.62 更新日志。

经过 React Native 社区 6 位贡献者 20 多个拉取请求的辛勤工作，我们很高兴推出 react-native doctor，一个新命令，帮助您入门、排除故障并自动修复开发环境中的错误。doctor 命令深受 Expo 和 Homebrew 自己的 doctor 命令的启发，并带有 Jest 启发的一点 UI。

我们很高兴地宣布 React Native 0.61 版本，其中包含我们称之为“快速刷新”（Fast Refresh）的全新重载体验。

快速刷新​

当我们向 React Native 社区询问常见痛点时，最主要的答案之一是“热重载”功能已损坏。它对函数组件不可靠，经常无法更新屏幕，并且对拼写错误和失误不具备弹性。我们听说大多数人因为其不可靠而将其关闭。

在 React Native 0.61 中，我们将现有的“实时重载”（保存时重载）和“热重载”功能统一为一个名为“快速刷新”的新功能。快速刷新是从头开始实现的，遵循以下原则

• 快速刷新完全支持现代 React，包括函数组件和 Hooks。
• 快速刷新在出现拼写错误和其他失误后能优雅恢复，并在需要时回退到完全重载。
• 快速刷新不执行侵入性代码转换，因此它足够可靠，可以默认开启。

要查看快速刷新的实际效果，请观看此视频

试一试，告诉我们你的想法！如果你愿意，可以在开发菜单（iOS 上 Cmd+D，Android 上 Cmd+M 或 Ctrl+M）中关闭它。开启和关闭都是即时的，所以你可以随时操作。

以下是一些快速刷新提示

• 快速刷新默认情况下保留函数组件（和 Hooks！）中的 React 本地状态。
• 如果需要每次编辑时都重置 React 状态，可以在包含该组件的文件中添加特殊的 // @refresh reset 注释。
• 快速刷新总是重新挂载类组件，而不保留状态。这确保了其可靠性。
• 我们都会在代码中犯错！快速刷新会在您保存文件后自动重试渲染。修复语法或运行时错误后，您无需手动重新加载应用程序。
• 在编辑过程中添加 console.log 或 debugger 语句是一种简洁的调试技术。

请在 GitHub 上报告快速刷新的任何问题，我们会调查。

其他改进​

• 修复了 use_frameworks! CocoaPods 支持。 在 0.60 版本中，我们进行了一些更新，默认集成了 CocoaPods。不幸的是，这破坏了使用 use_frameworks! 的构建。这在 0.61 版本中得到修复，使得将 React Native 集成到需要使用动态框架构建的 iOS 项目中变得更加容易。
• 添加 useWindowDimensions Hook。 这个新的 Hook 自动提供并订阅尺寸更新，在大多数情况下可以替代 Dimensions API。
• React 升级到 16.9。 此版本弃用了 UNSAFE_ 生命周期方法的旧名称，包含对 act 的改进等。有关自动迁移脚本和更多信息，请参阅 React 16.9 博客文章。

重大变更​

• 移除 React .xcodeproj。 在 0.60 版本中，我们通过 CocoaPods 引入了自动链接支持。我们还将 CocoaPods 集成到 e2e 测试运行中，因此从现在开始，我们有了一个统一的标准方式将 RN 集成到 iOS 应用程序中。这实际上弃用了 React .xcodeproj 的支持，并且该文件已从 0.61 版本开始移除。注意：如果您已经使用 0.60 自动链接，则不应受到影响。

致谢​

感谢所有为 0.61 版本作出贡献的开发者！

要查看所有更新，请查阅 0.61 更新日志。

上周在 Chain React 大会上，我们宣布了 Hermes，一个我们 Facebook 一直在开发的开源 JavaScript 引擎。它是一个小型轻量级的 JavaScript 引擎，专门为在 Android 上运行 React Native 进行优化。快去看看吧！

Hermes 通过减少内存使用、缩小下载大小和缩短应用程序可用时间（即“交互时间”TTI）来提高 React Native 性能。

“在分析性能数据时，我们注意到 JavaScript 引擎本身是启动性能和下载大小的一个重要因素。掌握这些数据后，我们知道必须在移动设备（与台式机或笔记本电脑相比，资源更受限）上优化 JavaScript 性能。在探索其他选项后，我们构建了一个新的 JavaScript 引擎，我们称之为 Hermes。它旨在提高应用程序性能，重点关注我们的 React Native 应用程序，即使是在内存有限、存储缓慢且计算能力降低的大众市场设备上。”——Hermes：一个为移动应用程序优化的开源 JavaScript 引擎，从 React Native 开始

想立即开始？务必查阅我们关于如何在现有 React Native 应用中启用 Hermes 的新指南！

插图由 Rachel Nabors 绘制

经过数百名贡献者数月的辛勤工作，React Native 核心团队自豪地宣布发布 0.60 版本。此版本处理了 Android 和 iOS 平台的重大迁移，并解决了许多问题。此博客文章涵盖了发布亮点。然而，一如既往，请查阅更新日志以获取更详细的信息。最后，感谢贡献者们帮助我们实现了这一里程碑！

关注可访问性​

可访问性 API 方面有很多改进，例如 announceForAccessibility，以及对角色、操作支持、标志等的改进。可访问性是一门复杂的科学，但我们希望这些改进能让 A11Y（可访问性）更容易一些。务必查阅 2019 年 6 月 React Native 开源更新以获取这些更改的更多详细信息。

全新开始​

React Native 的启动界面已更新！感谢众多贡献者帮助创建了新的 UI。这个新的“Hello World”将以更友好、更具吸引力的方式欢迎用户进入生态系统。

AndroidX 支持​

AndroidX 是 Android 生态系统向前迈出的重要一步，旧的支持库构件正在被弃用。对于 0.60 版本，React Native 已迁移到 AndroidX。这是一个重大变更，您的原生代码和依赖项也需要迁移。

随着这一变化，React Native 应用程序将需要开始自己使用 AndroidX。它们不能在一个应用程序中并排使用，因此所有应用程序代码和依赖代码都需要使用其中一个。

matt-oakes 在 discussions-and-proposals

虽然您自己的原生代码需要您手动迁移，但 @mikehardy、@cawfree 和 @m4tt72 构建了一个名为“jetifier”的巧妙工具来修补您的 node_modules。库维护者需要升级，但此工具为您提供了一个临时解决方案，同时给他们时间发布 AndroidX 版本。因此，如果您发现与 AndroidX 迁移相关的错误，请尝试一下。

默认使用 CocoaPods​

CocoaPods 现在是 React Native 的 iOS 项目的一部分。如果您还没有这样做，请务必从现在开始使用 xcworkspace 文件打开 iOS 平台代码（提示：尝试从项目根目录运行 xed ios）。此外，内部包的 podspec 已更改，使其与 Xcode 项目兼容，这将有助于故障排除和调试。作为升级到 0.60 的一部分，您需要对 Podfile 进行一些简单的更改，以实现这一令人兴奋的支持。请注意，我们已意识到与 use_frameworks! 的兼容性问题，我们正在跟踪一个问题，其中包含解决方法和未来的补丁。

瘦核心移除​

WebView 和 NetInfo 之前已被提取到单独的仓库中，在 0.60 版本中，我们已完成将其从 React Native 仓库中迁移出来。此外，为了响应社区对新 App Store 政策的反馈，Geolocation 也已被提取。如果您还没有，请通过添加对 react-native-webview、@react-native-community/netinfo 和 @react-native-community/geolocation 的依赖来完成迁移。如果您想要自动化解决方案，请考虑使用 rn-upgrade-deprecated-modules。自提取以来，维护者已向这些仓库提交了 100 多个提交，我们很高兴看到社区的支持！

原生模块现在支持自动链接​

负责 React Native CLI 的团队对原生模块链接引入了重大改进，称为 自动链接！大多数情况下，将不再需要使用 react-native link。同时，该团队全面修改了链接过程。请务必 react-native unlink 任何已存在的依赖项，如上述文档中所述。

升级助手​

@lucasbento、@pvinis、@kelset 和 @watadarkstar 构建了一个名为 升级助手 的强大工具，以简化升级过程。它帮助使用 brownfield 应用或复杂自定义的 React Native 用户查看版本之间的变化。请查阅更新后的升级文档，并立即尝试升级您的项目！

致库维护者的一封信​

AndroidX 的变更几乎肯定需要您的库进行更新，因此请务必尽快包含支持。如果您暂时无法升级，请考虑使用 jetifier 检查您的库，以确认用户能够在构建时修补您的库。

查阅自动链接文档以更新您的配置和自述文件。根据您之前集成库的方式，您可能还需要进行一些额外的更改。请查阅 CLI 的依赖项指南，了解如何定义您的依赖项接口。

致谢​

虽然这些是我们注意到的亮点，但还有许多其他令人兴奋的更新。要查看所有更新，请查阅 更新日志。一如既往，请继续关注更多新闻。同时，享受 0.60 版本吧！

代码与社区健康​

在过去的六个月中，React Native 共收到 2800 次提交，来自 550 多名贡献者。来自社区的 400 名贡献者创建了超过 1,150 个拉取请求，其中 820 个拉取请求被合并。

尽管我们通过精简核心工作将网站、CLI 和许多模块从 React Native 中分离出来，但在过去六个月中，平均每天的拉取请求数量从三个增加到大约六个。目前，开放的拉取请求平均数量低于 25 个，我们通常在几小时或几天内回复建议和评论。

有意义的社区贡献​

我们想强调一些我们认为很棒的近期贡献

• 可访问性： React Native 0.60 将在 Android 和 iOS 上带来许多可访问性 API 的改进。所有新功能都直接使用底层平台提供的 API，因此它们将与 Android 和 iOS 上的原生辅助技术集成。我们感谢 Marc Mulcahy、Alan Kenyon、Estevão Lucas、Sam Mathias Weggersen 和 Janic Duplessis 的贡献
  • 附加可访问性角色 + 状态和新的可访问性状态 API。为各种组件添加了许多缺失的可访问性角色，并为未来更好的 Web 支持提供了一个新的 API。
  • AccessibilityInfo.announceForAccessibility。增加了对 Android 的支持，以前仅限 iOS。
  • 扩展可访问性操作支持。增加了处理用户定义操作周围可访问性的回调。
  • 支持 iOS 可访问性标志和支持“减少动画”。
  • Android 键盘可访问性改进。添加了 clickable prop 和 onClick 回调，用于通过键盘导航调用操作（注意：此功能很快将重命名为 focusable）。
  • 使用 CALayers 绘制文本。修复了 iOS 上放大文本消失的问题。
• 新应用屏幕： 社区提出了新应用屏幕的设计，该设计已在 0.60 中实现。这个屏幕是大多数人初次使用 React Native 时看到的内容。它现在将首次用户链接到文档，并且外观与我们即将推出的网站重新设计保持一致🌟。非常感谢 Orta、Adam Shurson、Glauber Castro、Karan Singh、Eli Perkins、Lucas Bento 和 Eric Lewis 的所有工作和协作！
  • 在“React Native 秀”视频系列中查看新应用屏幕。
• TurboModule 类型： 新的 TurboModules 系统要求所有原生模块都有类型，以保证原生操作的类型安全。在短短两周内，社区发送了大约 40 个拉取请求，以完成 Flow 类型原生模块的工作。除了上面已经提到的人员之外，我们还要感谢 Michał Chudziak、Michał Pierzchała、Wojtek Szafraniec 和 Jean Regisser 以及所有发送了一个或多个拉取请求的其他人。
• Haste： 自 2015 年以来，React Native 一直使用 “haste”模块系统，该系统允许仅通过全局 ID 而不是相对路径导入模块，这很方便，但许多工具不支持。 James Ide 提议移除 haste，类似于 React 几年前移除 haste 的方式。他通过一个总任务规划了所有工作，并发送了 18 个拉取请求来完成它！查看他的 Twitter 线程以了解更多信息。
• Android Fragments： John Shelley 提出的通过 Android Fragments 使 React Native 工作的提案已合并，并将在 0.61 中提供。 在此处阅读有关 Android Fragments 的更多信息。

瘦核心​

瘦核心的主要动机是将模块从 React Native 中拆分到单独的仓库中，以便它们能够获得更好的维护。仅仅六个月，像 WebView、NetInfo、AsyncStorage、网站和 CLI 等项目总共收到了 800 多个拉取请求。除了更好的维护之外，这些项目还可以比 React Native 本身更频繁地独立发布。

我们还借此机会从 React Native 本身中删除了过时的 polyfill 和遗留组件。过去，polyfill 是必要的，以支持旧版本 JavaScriptCore (JSC) 中的语言特性，如 Map 和 Set。现在 React Native 附带了新版本，这些 polyfill 已被删除。

这项工作仍在进行中，原生和 JavaScript 方面还有许多东西需要拆分或移除，但早期迹象表明，我们成功扭转了表面积和应用大小增加的趋势：例如，查看 JavaScript 包，大约一年前的 0.54 版本中，React Native JavaScript 包大小为 530kb，在短短 6 个月内增长到 0.57 版本的 607kb（+77kb）。现在我们看到 master 分支上的包大小减少了 28kb，降至 579kb，差异超过 100kb！

在完成精简核心的第一次迭代后，我们将努力更有意识地将新的 API 添加到 React Native 中，并将持续评估使 React Native 更小、更快的方法，以及寻找让社区对各种组件拥有所有权的方法。

用户反馈​

六个月前，我们向社区询问“您不喜欢 React Native 的哪些地方？”，这很好地概述了人们面临的问题。我们几个月前回复了该帖子，现在是时候总结主要问题的进展了

• 升级： React Native 社区围绕升级体验进行了多项改进：自动链接，通过 rn-diff-purge 改进了升级命令，以及一个升级助手网站（即将推出）。我们还将通过发布每个主要版本的博客文章来确保沟通重大更改和令人兴奋的新功能。这些改进中的许多将使 0.60 版本之后的未来升级显著更容易。
• 支持 / 不确定性：许多人对拉取请求（Pull Requests）缺乏活动以及对 Facebook 在 React Native 投资的普遍不确定性感到沮丧。如上所示，我们可以自信地说，我们已准备好接受更多拉取请求，并热切期待您的提议和贡献！
• 性能：React Native 0.59 附带了一个全新的、速度更快的 JavaScriptCore (JSC) 版本。此外，我们一直在努力使 内联 require 默认启用变得更容易，并在接下来的几个月里为您带来更多令人兴奋的更新。
• 文档：我们最近开始努力大修并重写所有 React Native 文档。如果您希望贡献，我们很乐意得到您的帮助！
• Xcode 中的警告：我们清除了所有现有警告，并正在努力避免引入新的警告。
• 热重载：React 团队正在构建一个新的热重载系统，该系统将很快集成到 React Native 中。

遗憾的是，我们还未能改进所有方面

• 调试：我们修复了许多每天都会遇到的不便的错误和问题，但遗憾的是，我们在这方面没有取得我们希望的那么大的进展。我们认识到使用 React Native 进行调试并不理想，未来我们将优先改进这一点。
• Metro 符号链接：遗憾的是，我们尚未能为此实现一个简单直接的解决方案。然而，React Native 用户分享了各种可能对您有效的变通方案。

鉴于过去六个月的大量变化，我们想再次向您提出同样的问题。如果您正在使用最新版本的 React Native 并有任何希望提供反馈的方面，请在我们的新版“您不喜欢 React Native 的哪些方面？”中评论。

持续集成​

Facebook 首先将所有拉取请求和内部更改直接合并到 Facebook 的仓库中，然后将所有提交同步回 GitHub。Facebook 的基础设施与常见的持续集成服务不同，并非所有开源测试都在 Facebook 内部运行。这意味着同步到 GitHub 的提交经常会破坏开源中的测试，而这需要大量时间来修复。

来自 React Native 团队的 Héctor Ramos 在过去两个月里改进了 React Native 在 Facebook 和 GitHub 上的持续集成系统。现在，大部分开源测试在更改提交到 Facebook 的 React Native 之前运行，这将在提交同步时保持 GitHub 上的 CI 稳定。

下一步​

请务必查看我们关于 React Native 未来的演讲！在接下来的几个月里，Facebook 的 React Native 团队成员将在 Chain React 和 React Native EU 发表演讲。此外，请关注我们的下一个版本 0.60，它即将发布。这将是令人兴奋的 ✨

本周，Eli White 在 F8 2019 上发表了关于 React Native 在 Facebook Android 和 iOS 应用程序中应用的演讲。我们很高兴分享过去两年我们所做的一切以及接下来的计划。

在Facebook 开发者网站上查看视频

演讲亮点：​

• 2017 年和 2018 年，我们专注于 React Native 最大的产品——Facebook 的 Marketplace。我们与 Marketplace 团队合作，以提高产品质量并增加用户体验。目前，Marketplace 是 Facebook 应用中在 Android 和 iOS 上质量最高的产品之一。
• Marketplace 的性能也是一个巨大的挑战，尤其是在中端 Android 设备上。在过去一年中，我们将其启动时间缩短了 50% 以上，并且还有更多改进正在进行中！最大的改进正在内置到 React Native 中，并将在今年晚些时候向社区推出。
• 我们有信心能够使用 React Native 构建 Facebook 所需的高质量、高性能应用程序。这种信心使我们能够进行更大的投入，例如重新思考 React Native 的核心。
• 微软支持并使用 React Native for Windows，使人们能够利用其专业知识和代码库渲染到微软的通用 Windows 平台。下周请关注 Microsoft Build，听他们详细介绍。

React Radio 播客谈开源​

Eli 的演讲最后谈到了我们最近的开源工作。我们在三月份提供了最新进展，最近 Nader Dabit 和 Gant Laborde 邀请 Christoph 参加他们的播客 React Native Radio，聊聊 React Native 在开源方面的情况。

播客亮点：​

• 我们讨论了 Facebook 的 React Native 团队如何看待开源，以及我们如何为 React Native 这样规模的项目构建一个可持续发展的社区。
• 作为 精简核心 (Lean Core) 工作的一部分，我们正在按计划移除多个模块。WebView 和 React Native CLI 等许多模块在被提取后已收到超过 100 个拉取请求。
• 接下来，我们将重点关注 React Native 网站和文档的全面改进。敬请期待！

您很快就能在您喜爱的播客应用中找到这一集，或者您也可以在这里收听录音

欢迎来到 React Native 0.59 版本！这是又一个重要版本，包含 88 位贡献者的 644 次提交。贡献也以其他形式存在，因此感谢您维护问题、培养社区以及向人们介绍 React Native。本月带来了一些备受期待的更改，我们希望您会喜欢它们。

🎣 Hooks 来了​

React Hooks 是此版本的一部分，它允许您在组件之间重用有状态逻辑。关于 Hooks 有很多热议，但如果您还没有听说过，请查看下面的一些精彩资源

• Hooks 介绍 解释了我们为什么将 Hooks 添加到 React 中。
• Hooks 概览 是对内置 Hooks 的快速介绍。
• 构建自己的 Hooks 演示了使用自定义 Hooks 进行代码重用。
• 理解 React Hooks 探索了 Hooks 开启的新可能性。
• useHooks.com 展示了社区维护的 Hooks 示例和演示。

请务必在您的应用中尝试一下。我们希望您会像我们一样对这种重用感到兴奋。

📱 更新 JSC 意味着 Android 性能提升和 64 位支持​

React Native 使用 JSC (JavaScriptCore) 为您的应用程序提供动力。Android 上的 JSC 已经有几年历史了，这意味着许多现代 JavaScript 特性都不受支持。更糟糕的是，与 iOS 的现代 JSC 相比，它的性能很差。随着此版本的发布，这一切都改变了。

感谢 @DanielZlotin、@dulmandakh、@gengjiawen、@kmagiera 和 @kudo 的出色工作，JSC 已经赶上了过去几年的进度。这带来了 64 位支持、现代 JavaScript 支持以及巨大的性能改进。此外，感谢你们使其成为一个可维护的过程，这样我们就可以在未来利用 WebKit 的改进而无需太多额外工作，并感谢 Software Mansion 和 Expo 使这项工作成为可能。

💨 使用内联 require 加快应用启动速度​

我们希望帮助人们默认拥有高性能的 React Native 应用程序，并正在努力将 Facebook 的优化带给社区。应用程序按需加载资源，而不是减慢启动速度。此功能称为“内联 require”，因为它允许 Metro 识别要延迟加载的组件。具有深层且多样化组件架构的应用程序将看到最大的改进。

我们需要社区告诉我们它如何工作，然后我们才能默认启用它。当您升级到 0.59 时，将有一个新的 metro.config.js 文件；将选项设置为 true 并向我们提供您的反馈！阅读更多关于内联 require 的信息，请查看性能文档以对您的应用进行基准测试。

🚅 精简核心正在进行中​

React Native 是一个庞大而复杂的项目，拥有一个复杂的代码库。这使得代码库对贡献者来说难以接触，难以测试，并且作为一个开发依赖项而言过于臃肿。精简核心 (Lean Core) 是我们通过将代码迁移到单独的库以更好地管理来解决这些问题的努力。过去几个版本已经看到了这一举措的第一步，但让我们认真起来。

您可能会注意到，更多组件现在已正式弃用。这是个好消息，因为现在这些功能都有了积极维护它们的所有者。请留意警告消息并迁移到这些功能的新库，因为它们将在未来的版本中被移除。下面是一个表格，指示组件、其状态以及您可以迁移使用到何处。

在接下来的几个月里，将有更多组件遵循这条路径，实现更精简的核心。我们正在为此寻求帮助——请前往精简核心计划总揽贡献一份力量。

👩🏽‍💻 CLI 改进​

React Native 的命令行工具是开发者进入生态系统的入口，但它们长期存在问题，并且缺乏官方支持。CLI 工具已迁移到新的仓库，并且专门的维护者团队已经取得了一些令人兴奋的改进。

日志现在格式化得好多了。命令现在几乎瞬间运行——您会立即注意到不同

🚀 升级到 0.59​

我们听取了您关于React Native 升级过程的反馈，我们正在采取措施改进未来版本的体验。要升级到 0.59，我们建议使用 rn-diff-purge 来确定您当前 React Native 版本和 0.59 之间有哪些变化，然后手动应用这些更改。一旦您的项目升级到 0.59，您将能够使用新改进的 react-native upgrade 命令（基于 rn-diff-purge！）来升级到 0.60 及更高版本，随着新版本的发布。

🔨 破坏性更改​

0.59 中对 Android 的支持已根据 Google 的最新建议进行了清理，这可能导致现有应用程序的潜在损坏。此问题可能表现为运行时崩溃和一条消息：“您需要将 Theme.AppCompat 主题（或其子主题）与此活动一起使用”。我们建议更新您项目的 AndroidManifest.xml 文件，确保 android:theme 值为 AppCompat 主题（例如 @style/Theme.AppCompat.Light.NoActionBar）。

react-native-git-upgrade 命令已在 0.59 中移除，取而代之的是新改进的 react-native upgrade 命令。

🤗 感谢​

许多新贡献者帮助从 flow 类型生成原生代码以及解决 Xcode 警告——这些是学习 React Native 如何工作并为更大范围的利益做出贡献的好方法。谢谢您！未来请留意类似的问题。

虽然这些是我们注意到的亮点，但还有许多其他值得兴奋的地方。要查看所有更新，请查看更新日志。0.59 是一个巨大的版本——我们迫不及待地想让您尝试一下。

今年余下的时间里，我们将有更多改进。敬请期待！

Ryan 和整个 React Native 核心团队