52 篇带“announcement”标签的帖子

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 提高开发效率的唯一方式。团队可以利用快速增长的高质量开源包生态系统。团队还可以在 Android、iOS 和 Web 之间共享业务逻辑。这有助于他们更快地发布更新，并减少平台团队之间的组织孤岛。

所有平台​

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

React Native 针对非常不同的平台，包括移动设备、桌面设备、网络、电视、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 中经过完全重新设计的 redbox、yellowbox 和日志体验。在 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，它现在是我们目标版本。如果您仍在将 Node 8 用于 React Native 应用程序的开发，我们鼓励您升级以获取所有最新的安全修复和更新。

其他值得注意的改进​

• 支持在 <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 拉取插件的市场，因此您可以发布和安装特定于您的工作流的自定义插件。在此处查看可用插件：此处。

有关更多信息，请查看 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。升级助手提供了从您当前版本到您目标版本的更改差异，允许您查看特定升级所需的更改。

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

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

其他改进​

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

重大更改​

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

弃用​

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

致谢​

感谢数百位贡献者，他们的努力使 0.62 版本成为可能！

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

在 React Native 社区 6 位贡献者的 20 多个拉取请求之后，我们很高兴地推出了 react-native doctor，这是一个新命令，可以帮助您入门、故障排除并自动修复开发环境中的错误。doctor 命令深受 Expo 和 Homebrew 自己的 doctor 命令的启发，并带有一丝 Jest 启发的用户界面。

我们很高兴地宣布 React Native 0.61 发布，其中包含我们称之为 Fast Refresh 的全新重载体验。

Fast Refresh​

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

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

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

要查看 Fast Refresh 的实际效果，请观看此视频：

试试看，并告诉我们你的想法！如果你愿意，可以在开发菜单（iOS 上按 Cmd+D，Android 上按 Cmd+M 或 Ctrl+M）中将其关闭。开启和关闭是即时的，因此你可以随时进行操作。

以下是一些 Fast Refresh 的提示：

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

请在 GitHub 上报告 Fast Refresh 的任何问题，我们会进行调查。

其他改进​

• 修复了 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 在讨论和提案中

虽然您自己的原生代码需要您自己迁移，但 @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 的团队对原生模块链接进行了重大改进，称为 autolinking！大多数情况下不再需要使用 react-native link。同时，该团队全面修订了链接过程。请务必 react-native unlink 任何现有的依赖项，如上述文档所述。

升级助手​

@lucasbento、@pvinis、@kelset 和 @watadarkstar 构建了一个名为 Upgrade Helper 的出色工具，以简化升级过程。它帮助 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 属性和一个 onClick 回调，用于通过键盘导航调用操作（注：这很快将被重命名为 focusable）。
  • 使用CALayers绘制文本。修复了导致放大文本在iOS上消失的问题。
• 新应用启动页： 社区为 0.60 中实现的新应用启动页提出了一个设计。这个启动页是大多数人第一次使用 React Native 时看到的东西。它现在将初次使用者链接到文档，并且外观与我们即将进行的网站重新设计相符🌟。非常感谢 Orta、Adam Shurson、Glauber Castro、Karan Singh、Eli Perkins、Lucas Bento 和 Eric Lewis 的所有工作和协作！
  • 在“React Native Show”视频系列中查看新的应用程序屏幕。
• 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 片段： John Shelley 提出的通过 Android 片段使 React Native 工作的提案已合并，并将在 0.61 版本中提供。在此处阅读有关 Android 片段的更多信息。

精益核心​

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

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

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

在我们结束精简核心的第一次迭代时，我们将努力更有意地对待添加到 React Native 的新 API，我们将不断评估使 React Native 更小、更快的方法，并寻找方法赋能社区拥有各种组件的所有权。

用户反馈​

六个月前，我们问社区：“您不喜欢 React Native 的什么？”这很好地概述了人们面临的问题。我们几个月前回复了该帖子，现在是时候总结一下在主要问题上取得的进展了。

• 升级： React Native 社区齐心协力，对升级体验进行了多项改进：自动链接，通过 rn-diff-purge 改进升级命令，以及一个升级助手网站（即将推出）。我们还将通过为每个主要版本发布博客文章来确保沟通破坏性更改和令人兴奋的新功能。这些改进中的许多都将使 0.60 版本之后的未来升级显著更容易。
• 支持/不确定性： 许多人对拉取请求缺乏活动以及 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 的核心。
• Microsoft 支持并使用 React Native for Windows，使人们能够利用其专业知识和代码库渲染到 Microsoft 的通用 Windows 平台。下周请关注 Microsoft Build，听他们详细介绍。

关于开源的 React Radio 播客​

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

播客重点：​

• 我们讨论了 Facebook 的 React Native 团队如何看待开源，以及我们如何为 React Native 规模的项目构建一个可持续发展的社区。
• 我们正在按计划删除多个模块，作为精简核心工作的一部分。许多模块，如 WebView 和 React Native CLI，自提取以来已收到 100 多个拉取请求。
• 接下来，我们将专注于彻底改造 React Native 网站和文档。敬请期待！

您很快就能在您喜欢的播客应用程序中找到该集，或者您可以在此处收听录音

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

🎣 Hooks 来了​

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

• Hooks 简介解释了我们为什么要在 React 中添加 Hooks。
• 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 及更高版本。

🔨 破坏性变更​

Android 在 0.59 中的支持已根据 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 核心团队