52 篇标记为“公告”的帖子

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 中经过完全重新设计的红框 (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 拉取插件的市场，因此您可以发布和安装特定于您的工作流程的自定义插件。在此处查看可用插件：here。

欲了解更多信息，请查看 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 的公开发布版本。对于此 0.62 版本的 react-native，请将 Apple TV 项目升级到使用 react-native-tvos 0.62。

更多升级支持​

0.61 发布时，社区推出了一款新的升级助手工具，以支持开发者升级到新版本的 React Native。升级助手提供了从当前版本到目标版本之间变化的差异，让您可以看到特定升级所需进行的更改。

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

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

其他改进​

• LogBox：我们正在添加新的 LogBox 错误和警告体验作为可选功能；要启用它，请在您的 index.js 文件中添加 require('react-native').unstable_enableLogBox()。
• React DevTools v4：此更改包括升级到最新版 React DevTools，它提供了显著的性能提升、改进的导航体验以及对 React Hooks 的完全支持。
• 可访问性改进：我们对可访问性进行了改进，包括添加了 accessibilityValue、Touchables 上缺失的属性、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 启发的一点 UI。

我们很高兴地宣布 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：一个为移动应用程序（从 React Native 开始）优化的开源 JavaScript 引擎

想立即开始吗？务必查看我们文档中关于在现有 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 构建了一个名为 升级助手 的出色工具，使升级过程更简单。它帮助 React Native 用户通过棕色地带应用程序或复杂自定义来查看版本之间的变化。今天就查看更新的升级文档并尝试您的升级路径吧！

致库维护者的一封信​

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

请查看自动链接文档以更新您的配置和 README。根据您的库以前的集成方式，您可能还需要进行一些额外的更改。请查看 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。为各种组件添加了许多缺失的可访问性角色，以及一个新的 API，以支持未来更好的 Web 支持。
  • 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 Fragments： John Shelley 提出的使 React Native 通过 Android Fragments 工作的方法已合并，并将在 0.61 中提供。在此处阅读有关 Android Fragments 的更多信息。

精简核心​

精简核心 的主要动机是将模块从 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）。现在我们看到主分支上的包大小减少了 28kb，降至 579kb，差异超过 100kb！

随着我们完成精简核心的第一次迭代，我们将努力更有意识地对待添加到 React Native 的新 API，我们将不断评估使 React Native 更小更快的各种方法，以及寻找 empowering 社区对各种组件拥有所有权的方式。

用户反馈​

六个月前，我们向社区提出了“您不喜欢 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的核心。
• 微软支持并使用适用于Windows的React Native，这使得人们能够利用他们的专业知识和代码库来渲染到微软的通用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个Pull Request。
• 接下来，我们将专注于彻底改造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（inline requires）”，因为它允许Metro识别需要延迟加载的组件。具有深度和多样化组件架构的应用程序将看到最大的改进。

在默认开启此功能之前，我们需要社区告知我们它的效果。当您升级到0.59版本时，会有一个新的metro.config.js文件；将选项设置为true，并向我们提供您的反馈！在性能文档中阅读更多关于内联 require 的内容，以对您的应用进行基准测试。

🚅 精简核心进行中​

React Native 是一个庞大而复杂的项目，拥有一个复杂的代码仓库。这使得代码库对贡献者而言不够友好，难以测试，并且作为开发依赖项过于臃肿。精简核心（Lean Core）是我们的努力方向，旨在通过将代码迁移到单独的库以更好地管理来解决这些问题。过去几个版本已经迈出了第一步，但让我们认真对待。

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

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

👩🏽‍💻 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 核心团队