在过去的一年里，我们的世界发生了如此多的变化，React Native 也不例外。我们欢迎了团队新成员（我们很高兴最终能与他们亲自见面！），我们的项目已经成熟，新的机遇也随之出现。我们很高兴在这篇文章和即将到来的其他文章中与您分享这一切！
在 Facebook，我们的团队以半年为周期工作。每个半年，我们都会回顾我们的战略、制定计划并在内部分享。今天，我们想与您，我们的社区，分享我们下半年的计划。
2021 年下半年对 React Native 来说是激动人心的半年。我们的重点领域包括培育社区、开始向开源社区推广新架构以及推动技术向前发展。
今天我们发布了 React Native 0.65 版本，其中包含新版本的 Hermes、无障碍功能改进、软件包升级等。
Hermes，Facebook 为 React Native 优化的开源 JavaScript VM，已升级到 0.8.1 版本。此版本中一些突出的功能是
Intl) 现在内置于 Android 版 Hermes 中，并默认启用，每个 API 大小开销仅为 57-62K（相比于 JSC 的 6MiB）。通过此更改，Hermes 用户不再需要区域设置 polyfill。非常感谢 @mganandraj 和 Microsoft 的其他合作伙伴推动实施以实现这一点！Function.prototype.toString 的更改，修复了由于不正确的特性检测导致的性能下降，并 支持源代码注入用例。您可以在此处找到完整的 Hermes 更新日志。
按照此处的步骤将您的应用选择加入 Hermes，如果您尚未这样做，以利用这些新功能和收益！
去年，Facebook 承诺遵守 GAAD 承诺，以改进 React Native 中的无障碍功能。0.65 分享了此承诺的结果和其他无障碍功能的成果！一些值得注意的更改包括
getRecommendedTimeoutMillis API。这公开了用户在 Android 无障碍选项中设置的首选默认超时值，适用于可能需要额外时间来查看或访问控件等的用户。disabled 和 unselected。您可以在此处关注或贡献我们的未解决的无障碍功能问题！
package.json 中使用 react-native-codegen 版本 0.0.7 作为 devDependency。此版本包含来自 61 位贡献者的超过 1100 次提交。感谢每位为此版本做出贡献和支持的人！您可以在此处找到完整的更新日志。
自 Facebook 承诺遵守 GAAD 承诺，使 React Native 具有无障碍功能以来已经一年了，该项目超出了我们的预期。我们很高兴地宣布，该项目将在 2021 年全年继续进行，并希望向大家更新我们目前的进展。在去年对 React Native 中的无障碍功能差距进行全面分析之后，开始着手填补这些差距。
我们从 90 个未解决的差距分析问题开始，从 2021 年 3 月项目在 GitHub 上启动至今
社区已关闭 11 个问题。
React Native 团队评估并关闭了 19 个问题。
合并了 9 个拉取请求。
1 个拉取请求已合并到 React Native 文档中。
我们要感谢 React Native 社区在过去一年中为实现更易于访问的 React Native 所做的重大进展。每位贡献者的努力都在为改进 React Native 无障碍功能做出贡献。
自从我们与 GitHub 社区联系，提供经过全面审查的差距分析和问题列表以改进 React Native 的无障碍功能以来，已经过去了四周。在 React Native 社区的帮助下，我们在改进无障碍功能方面已经取得了巨大进展。社区成员一直在帮助贡献者、审查测试并关注之前的无障碍功能问题。自 3 月 8 日以来，社区已关闭六个问题，其中四个拉取请求，另有七个拉取请求正在等待审查。
在这项工作继续进行的同时，Facebook 的 React Native 和无障碍功能团队正在评估在此倡议之前提交的无障碍功能错误和问题，以确定它们是否已包含在我们当前的差距分析中，或者是否需要将其他问题纳入项目中。已经发现了一个新问题并已移至项目中，其他四个问题直接映射到现有问题，预计其他两个问题将通过解决解决其根本原因的现有问题来关闭。
感谢所有参与的社区成员。你们真的在推动使 React Native 对每个人都更易于访问！
今天我们发布了 React Native 0.64，其中附带了对 iOS 上 Hermes 的支持。
Hermes 是一个开源 JavaScript 引擎，针对运行 React Native 进行了优化。它通过减少内存使用量、减少下载大小和减少应用变得可用或“可交互时间”（TTI）所需的时间来提高性能。
在此版本中，我们很高兴地宣布，您现在也可以使用 Hermes 在 iOS 上进行构建。要在 iOS 上启用 Hermes，请在您的 Podfile 中将 hermes_enabled 设置为 true，然后运行 pod install。
use_react_native!(
:path => config[:reactNativePath],
# to enable hermes on iOS, change `false` to `true` and then install pods
:hermes_enabled => true
)
请记住，iOS 上对 Hermes 的支持仍处于早期阶段。我们将其保留为选择加入，因为我们正在进行进一步的基准测试。我们鼓励您在自己的应用程序上试用它，并告知我们它的运行情况！
内联 require 是一个 Metro 配置选项，它通过延迟 JavaScript 模块的执行直到使用它们时而不是在启动时来提高启动时间。
作为文档的性能部分中列出的选择加入配置选项，此功能已经存在并被推荐了几年。我们现在为新应用程序默认启用此选项，以帮助人们拥有快速的 React Native 应用程序，而无需额外的配置。
内联 require 是一个 Babel 转换，它接受模块导入并将它们转换为内联。例如，内联 require 将此模块导入调用从文件顶部转换为其使用位置。
之前
import {MyFunction} from 'my-module';
const MyComponent = props => {
const result = MyFunction();
return <Text>{result}</Text>;
};
之后
const MyComponent = props => {
const result = require('my-module').MyFunction();
return <Text>{result}</Text>;
};
有关内联 require 的更多信息，请参见性能文档。
在过去的一年中，Facebook 赞助了 Major League Hacking fellowship，以支持对 React Native 的贡献。Jessie Nguyen 和 Saphal Patro 添加了使用 Chrome DevTools 上的 Performance 选项卡来可视化您的应用程序在使用 Hermes 时的执行情况的功能。
有关更多信息，请查看新的文档页面。
我们已将 Proxy 支持添加到 Hermes，从而实现了与流行的社区项目（如 react-native-firebase 和 mobx）的兼容性。如果您一直在使用这些软件包，您现在可以将您的项目迁移到 Hermes。
我们计划在即将发布的版本中将 Hermes 作为 Android 的默认 JavaScript 引擎，因此我们正在努力解决人们在使用 Hermes 时遇到的剩余问题。如果还有其他问题阻碍您的应用采用 Hermes，请在 Hermes GitHub 仓库上打开一个问题。
React 17 不包含面向开发人员的新功能或重大突破性更改。对于 React Native 应用程序，主要更改是新的 JSX 转换，使文件不再需要导入 React 即可使用 JSX。
有关 React 17 的更多信息，请访问React 博客。
感谢数百位贡献者帮助实现了 0.64！0.64 更新日志包括此版本中包含的所有更改。
2020 年 5 月，Facebook 是第一家遵守 GAAD 承诺的公司，通过这样做，他们承诺使无障碍功能成为 React Native 开源项目的核心部分。自 5 月以来，Facebook 花费了时间认真审查和记录 React Native 中的无障碍功能差距。到目前为止，差距分析已发现 90 个问题，所有问题都已转换为 GitHub 问题。
总的来说，我们发现 React Native API 为无障碍功能提供了强大的支持。但是，我们也发现许多核心组件尚未完全利用平台无障碍功能 API，并且缺少对某些平台特定功能的支持。
贡献者的热情和多样性一直在 React Native 的开发中发挥着关键作用，而这些无障碍功能差距是当前和新贡献者的绝佳机会。如果您一直对贡献 React Native 感兴趣，我们鼓励您加入我们，使 React Native 更加易于访问。
为了表彰贡献者的努力，当无障碍功能问题被关闭并附加到拉取请求时，贡献者将从我们的社区经理那里获得 Twitter 上的致谢。拉取请求被接受到代码库中的贡献者将在我们的 React Native 博客上的每月问题更新中突出显示。
请加入我们，使 React Native 对每个人都更易于访问。
对需要更多努力的问题感兴趣的贡献者应访问 改进 React Native 无障碍功能项目页面，以查看需要他们 React Native 知识的 GitHub 问题。
对更新 React Native 文档以反映正在关闭的无障碍功能差距的技术文档编写者应访问 React Native 文档。
与可能提供帮助的任何人分享此倡议！
在 Twitter 或 Facebook 上关注 React Native GAAD 承诺开源无障碍功能社区经理，以随时了解最新进展。
去年，我们进行了用户访谈并发送了调查，以了解更多关于人们如何以及何时使用 React Native 文档的信息。通过从 24 次访谈和 3000 多份调查回复中收集的数据和指导，我们已经能够努力改进 React Native 的文档，我们很高兴今天分享这一进展
Pressable 和 React Native 组件介绍 文档非常感谢每位参与访谈、调查和我们的文档工作的人！您的合作使这一切成为可能。
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。
我们不相信在每个平台上部署完全相同的用户界面，我们相信 使用相同的声明式编程模型公开每个平台的独特功能。我们的声明式编程模型是 React。
根据我们的经验，React 推广的单向数据流使应用程序更容易理解。我们更喜欢将屏幕表达为声明式组件的组合，而不是命令式管理的视图。React 在 Web 上的成功以及新的原生 Android 和 iOS 框架的方向表明，行业也已接受声明式 UI。
React 普及了声明式用户界面。但是，仍然存在许多 React 独特定位可以解决的未解决问题。React Native 将继续建立在 React 的创新之上，并继续走在声明式用户界面运动的最前沿。
今天我们发布了 React Native 0.63，其中 LogBox 默认开启。
我们经常从社区收到反馈，称 React Native 中的错误和警告难以调试。为了解决这些问题，我们审视了 React Native 中整个错误、警告和日志系统，并从头开始重新设计了它。
LogBox 是 React Native 中一个完全重新设计的 redbox、yellowbox 和日志记录体验。在 0.62 版本中，我们引入了 LogBox 作为可选项。在这个版本中，我们将 LogBox 作为 React Native 中所有情况下的默认体验推出。
LogBox 旨在解决关于错误和警告过于冗长、格式不佳或无法操作的抱怨，它专注于三个主要目标：
为了实现这些目标，LogBox 包括：
我们将所有这些功能都封装在一个改进的视觉设计中，该设计在错误和警告之间保持一致，并允许在一个令人愉悦的 UI 中分页浏览所有日志。
随着此更改，我们还将弃用 YellowBox，转而支持 LogBox API。
LogBox.ignoreLogs()：此函数取代了 YellowBox.ignoreLogs([])，作为一种静默任何与给定字符串或正则表达式匹配的日志的方法。LogBox.ignoreAllLogs()：此函数取代了 console.disableYellowBox，作为一种关闭错误或警告通知的方法。注意：这仅禁用通知，未捕获的错误仍将打开全屏 LogBox。在 0.63 版本中，当使用这些已弃用的模块或方法时，我们将发出警告。请在 0.64 版本中删除这些 API 之前，更新您的调用站点，使其不再使用这些 API。
有关 LogBox 和调试 react native 的更多信息，请参阅此处的文档。
构建 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 组件的实际应用示例：
您可以从文档中了解更多信息。
每个原生平台都有系统定义的颜色的概念。这些颜色会自动响应系统主题设置，例如浅色或深色模式、辅助功能设置（例如高对比度模式），甚至在应用中的上下文，例如包含视图或窗口的特征。
虽然可以通过 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 的支持。此更改将使我们能够通过减少需要在本机代码中放置的兼容性检查数量来更快地行动，从而检测给定功能是否在特定 iOS 版本上受支持。凭借其 1% 的市场份额，它不应对您的客户产生太大的负面影响。
与此同时，我们正在放弃对 Node 8 的支持。其 LTS 维护周期已于 2019 年 12 月到期。当前的 LTS 是 Node 10，现在这是我们正在针对的版本。如果您仍在使用 Node 8 开发 React Native 应用程序，我们鼓励您升级，以便接收所有最新的安全修复和更新。
<Text /> 中渲染 <View /> 而无需显式大小：您现在可以在任何 <Text /> 组件内渲染任何 <View />，而无需显式设置其宽度和高度，这在以前的版本中并非总是可能的。在以前版本的 React Native 中，这将导致 RedBox。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。
此版本发布于全球疫情期间。我们今天发布此版本是为了尊重数百位使此版本成为可能的贡献者的工作，并防止该版本落后于 master 分支太远。请注意贡献者帮助解决问题的能力有所下降，并准备好在必要时推迟升级。
Flipper 是一款用于调试移动应用的开发者工具。它在 Android 和 iOS 社区中很受欢迎，在此版本中，我们默认为新的和现有的 React Native 应用启用了支持。
Flipper 开箱即用地提供了以下功能：
此外，由于 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 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 问题跟踪器，用户可以在其中提交特定于升级其项目的问题，以获得社区的帮助。
我们一直在努力改进升级体验，我们希望这些工具为用户提供他们在我们尚未涵盖的边缘情况下所需的支持。
require('react-native').unstable_enableLogBox() 添加到您的 index.js 文件中。onSlidingComplete 辅助功能事件，以及将 Switch 组件的默认角色从 "button" 更改为 "switch"。propTypes，以减少 React Native 核心对应用程序大小的影响，并倾向于在编译时而不是运行时检查的静态类型系统。accessibilityStates 属性，转而使用新的 accessibilityState prop，后者是一种语义更丰富的方式，供组件向辅助功能服务描述有关其状态的信息。onTextInput from TextInput，因为它不常见，不符合 W3C 标准，并且难以在 Fabric 中实现。我们还移除了未记录的 inputView prop 和 selectionState。AccessibilityInfo.fetch 已经弃用，但在此版本中，我们添加了警告。useNativeDriver，以便将来支持切换默认值。Animated 组件的 ref 现在是内部组件，并且 弃用了 getNode。感谢数百位贡献者使 0.62 版本成为可能！
要查看所有更新，请查看 0.62 更新日志。