在数百位贡献者数月的辛勤工作之后，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 项目兼容，这将有助于故障排除和调试。预计您需要对 Podfile 进行 一些简单的更改 作为升级到 0.60 的一部分，以实现此激动人心的支持。请注意，我们已知 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 检查您的库，以确认用户是否能够在构建时修补您的库。

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

感谢​

虽然这些是我们注意到的亮点，但还有很多其他令人兴奋的更新。要查看所有更新，请查看变更日志。一如既往，敬请关注更多新闻。在此期间，尽情享受 0.60 版本吧！

代码与社区健康​

在过去的六个月中，React Native 共收到了 2800 次提交，由 550 多位贡献者完成。社区中的 400 位贡献者创建了超过1150 个 Pull Request，其中820 个 Pull Request 已合并。

在过去的六个月中，每天的平均 Pull Request 数量从 3 个增加到大约 6 个，即使我们通过精简核心工作将网站、CLI 和许多模块从 React Native 中分离出来。平均未解决的 Pull Request 数量现在低于 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 个 Pull Request 来完成此工作以流式输入原生模块的类型。除了上面已经提到的人之外，我们还要感谢Michał Chudziak、Michał Pierzchała、Wojtek Szafraniec和Jean Regisser以及所有发送了一个或多个 Pull Request 的其他人。
• Haste：自 2015 年以来，React Native 使用了“haste”模块系统，该系统允许仅通过全局 ID 而不是相对路径导入模块，这很方便，但许多工具都不支持。 James Ide建议移除 haste，类似于 React 多年前移除 haste 的方式。他通过伞形任务计划了所有工作，并发送了 18 个 Pull Request 来实现它！查看他的 Twitter 线程以了解更多信息。
• Android 片段：John Shelley提出的使 React Native 通过Android 片段工作的提案已合并，并将出现在 0.61 中。在此处详细了解 Android 片段。

精简核心​

精简核心的主要动机是将模块从 React Native 分离到单独的存储库中，以便它们能够获得更好的维护。在短短六个月内，像WebView、NetInfo、AsyncStorage、网站和CLI这样的存储库共收到了 800 多个 Pull Request。除了更好的维护之外，这些项目还可以比 React Native 本身更频繁地独立发布。

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

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

随着我们完成精简核心工作的第一次迭代，我们将努力更加注重添加到 React Native 的新 API，并将持续评估使 React Native 更小更快的方法，以及赋予社区拥有各种组件所有权的方法。

用户反馈​

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

• 升级：React Native 社区围绕升级体验进行了多项改进：自动链接、通过rn-diff-purge提供更好的升级命令、升级助手网站（即将推出）。我们还将确保通过为每个主要版本发布博文来传达重大更改和令人兴奋的新功能。这些改进中的许多将使未来 0.60 版本之后的升级变得更加容易。
• 支持/不确定性：许多人对 Pull Request 活动的缺乏以及对 Facebook 对 React Native 投资的不确定性感到沮丧。如上所示，我们可以自信地说，我们已准备好处理更多 Pull Request，并且我们热切期待您的建议和贡献！
• 性能：React Native 0.59 附带了一个新的、速度更快的 JavaScriptCore (JSC) 版本。另外，我们一直在努力使默认情况下启用内联 require变得更容易，并且在接下来的几个月里，我们还将为您提供更多令人兴奋的更新。
• 文档：我们最近开始努力彻底检修和重写所有 React Native 的文档。如果您想贡献，我们非常乐意得到您的帮助！

• Xcode 中的警告： 我们已 消除所有现有的警告，并正在努力避免引入新的警告。
• 热重载： React 团队正在构建一个 新的热重载系统，该系统很快将集成到 React Native 中。

不幸的是，我们还没有能够改进所有内容。

• 调试： 我们修复了许多人们每天都会遇到的不便的错误和问题，但不幸的是，我们在调试方面取得的进展并不如我们希望的那么大。我们认识到使用 React Native 进行调试并不是很好，并且我们将在未来优先考虑改进这一点。
• Metro 符号链接： 不幸的是，我们还没有能够为此找到一个简单直接的解决方案。但是，React Native 用户 分享了各种解决方法，这些方法可能对您有用。

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

持续集成​

Facebook 首先将所有 Pull Request 和内部更改直接合并到 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 上发表了关于 Facebook 的 Android 和 iOS 应用程序中 React Native 的演讲。我们很高兴分享我们在过去两年里取得的成果以及我们下一步的计划。

在 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 Podcast​

Eli 的演讲最后谈到了我们最近的开源工作。我们在 3 月份 发布了我们进展的更新，最近 Nader Dabit 和 Gant Laborde 邀请 Christoph 参加了他们的播客 React Native Radio，讨论了 React Native 的开源方面。

播客要点：​

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

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

欢迎使用 React Native 的 0.59 版本！这是一个包含 88 位贡献者提交的 644 次提交的另一个重大版本。贡献也以其他形式出现，因此感谢您维护问题、培养社区并向人们传授 React Native 的知识。本月带来了许多备受期待的变化，我们希望您喜欢它们。

🎣 Hook 已上线​

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

• Hook 简介 解释了我们向 React 添加 Hook 的原因。
• Hook 概览 是对内置 Hook 的快速概述。
• 构建您自己的 Hook 演示了使用自定义 Hook 进行代码重用。
• 理解 React Hook 探讨了 Hook 开启的新可能性。
• useHooks.com 展示了社区维护的 Hook 食谱和演示。

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

📱 更新的 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 是一个庞大而复杂的项目，拥有一个复杂的存储库。这使得代码库对贡献者来说不太容易理解，难以测试，并且作为开发依赖项变得臃肿。精简核心 是我们努力解决这些问题的方法，方法是将代码迁移到单独的库以进行更好的管理。过去几个版本已经看到了第一步，但 让我们认真对待。

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

在未来几个月里，会有更多组件遵循这条路径，使核心更加精简。我们希望得到您的帮助 - 前往精简核心总览贡献您的力量。

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

我们在 2018 年第四季度宣布了我们的React Native 开源路线图，此前我们决定在 React Native 开源社区投入更多资源。

对于我们的第一个里程碑，我们专注于识别和改进我们社区中最显着的部分。我们的目标是减少未完成的拉取请求、减少项目的表面积、识别主要的用户问题，并制定社区管理指南。

在过去的两个月里，我们取得的进展超出了预期。继续阅读以了解更多详细信息。

拉取请求​

为了构建一个健康的社区，我们必须快速响应代码贡献。在过去的几年里，我们降低了审查社区贡献的优先级，并积累了 280 个拉取请求（2018 年 12 月）。在第一个里程碑中，我们将未完成的拉取请求数量减少到约 65 个。同时，每天打开的拉取请求平均数量从 3.5 个增加到 7 个，这意味着我们在过去三个月处理了大约600 个拉取请求。

我们合并了近三分之二并关闭了三分之一的拉取请求。如果它们已过时或质量低下，或者如果它们不必要地增加了项目的表面积，则会在未合并的情况下关闭它们。大多数合并的拉取请求修复了错误、改进了跨平台一致性或引入了新功能。值得注意的贡献包括改进类型安全性以及支持 AndroidX 的持续工作。

在 Facebook，我们从 master 运行 React Native，因此我们在更改进入 React Native 版本之前首先对其进行测试。在所有合并的拉取请求中，只有六个导致了问题：四个仅影响内部开发，两个在发布候选版本状态中被捕获。

社区贡献中更显着的一个是更新的“RedBox”屏幕。这是一个很好的例子，说明社区如何使开发人员体验更加友好。

精简核心​

React Native 目前拥有非常广泛的表面积，其中包含许多我们不常在 Facebook 中使用的未维护的抽象。我们正在努力减少表面积，以使 React Native 更小，并允许社区更好地维护在 Facebook 中大部分未使用的抽象。

在第一个里程碑中，我们请求社区在精简核心项目中提供帮助。反响热烈，我们几乎无法跟上所有进展。查看不到一个月内完成的所有工作！

我们最兴奋的是，维护者已经开始着手修复长期存在的问题、添加测试并支持长期以来请求的功能。这些模块获得的支持比它们在 React Native 中获得的更多，这表明这对社区来说是一个巨大的进步。此类项目的示例包括WebView，自提取以来收到了许多拉取请求，以及现在由社区成员维护的 CLI，并收到了急需的改进和修复。

主要用户问题​

在 12 月，我们询问社区他们不喜欢 React Native 的哪些方面。我们汇总了回复并回复了每一个问题。幸运的是，我们社区面临的许多问题也是 Facebook 遇到的问题。在我们接下来的里程碑中，我们计划解决一些主要问题。

投票数最高的问题之一是将 React Native 升级到较新版本时的开发人员体验。不幸的是，这不是我们自己遇到的问题，因为我们从 master 运行 React Native。值得庆幸的是，社区成员已经开始着手解决这个问题。

• Michał Pierzchała 来自 Callstack 改进了 react-native upgrade，方法是在后台使用rn-diff-purge。我们还更新了网站以删除过时的升级说明。
• 我们计划默认推荐使用 CocoaPods 用于 iOS 项目，这将减少升级 React Native 时项目文件中的变化。这将使人们更容易安装和链接第三方模块，这在精简核心上下文中更为重要，因为我们预计项目默认会链接更多模块。

0.59 版本​

如果没有 React Native 社区的帮助，特别是Mike Grabowski 和Lorenzo Sciandra，我们将无法发布版本。我们希望改进发布管理流程，并计划从现在开始更多地参与其中。

• 我们将与社区成员合作，为每个主要版本创建一篇博文。
• 当人们升级到新版本时，我们将在 CLI 中直接显示更改说明。
• 我们将缩短发布所需的时间。我们正在探索增加自动化测试的方法，并创建改进的手动测试计划。

许多这些计划将包含在即将发布的React Native 0.59 版本中。0.59 将附带 React Hooks、Android 的新 64 位 JavaScriptCore 版本以及许多性能和功能改进。它目前已发布为发布候选版本，预计在未来两周内将稳定下来。

后续步骤​

在未来两个月里，我们将继续管理拉取请求以保持正轨，同时开始减少未完成的 GitHub 问题数量。我们将通过精简核心项目继续减少 React Native 的表面积。我们计划解决 5 个社区首要问题。随着我们最终确定社区指南，我们将把注意力转向我们的网站和文档。

我们非常高兴能够在 3 月份在 Facebook 伦敦接待来自我们社区的十多位贡献者，以帮助推动这些工作的开展。我们很高兴您正在使用 React Native，并希望您能看到和感受到我们在 2019 年正在努力改进的地方。我们将在几个月后再次更新，并在 此期间合并您的拉取请求！ ⚛️✌️

2018 年，React Native 社区对我们开发和沟通 React Native 的方式进行了一些更改。我们相信，几年后，我们会回顾过去，并发现这种转变是 React Native 的一个转折点。

许多人对 React Native 架构的重写感到兴奋，它通常被称为 Fabric。其中，这将修复 React Native 架构中的基本限制，并与 JSI 和 TurboModules 一起为 React Native 的未来发展奠定基础。

2018 年最大的变化是赋予 React Native 社区力量。从一开始，Facebook 就鼓励来自世界各地的开发者参与 React Native 的开源项目。从那时起，一些核心贡献者开始出现，负责处理发布流程等事宜。

这些成员采取了一些实质性措施，通过以下资源让整个社区更有能力塑造项目的未来

react-native-releases 📬​

这个仓库于 1 月份创建，旨在以更协作的方式让每个人都能跟上新的发布，并向任何想要建议 cherry-pick 的人开放了关于某个版本中包含内容的讨论（例如 0.57.8 及其之前的所有版本）。

这推动了 React Native 远离每月发布周期，并采用当前用于 0.57.x 版本的“长期支持”方法。

达成这些决定的功劳有一半归于今年创建的另一个仓库

discussions-and-proposals 🗣​

这个仓库于 7 月份创建，扩展了在 React Native 上进行更开放环境的讨论的想法。以前，这种需求通过在主仓库中标记为 For Discussion 的问题来处理，但我们希望将这种策略扩展到其他库（例如 React）使用的 RFC 方法。

这项实验立即在 React Native 的生命周期中找到了自己的角色。Facebook 团队现在正在使用社区 RFC 流程来讨论 React Native 中哪些方面可以改进，并协调围绕 精简核心项目 的工作——以及其他有趣的讨论。

@ReactNativeComm 🐣​

我们意识到，我们沟通这些工作的方式并没有像我们希望的那样有效，为了让大家更容易了解 React Native 社区中发生的一切（从发布到活跃的讨论），我们创建了一个新的 Twitter 账号 @ReactNativeComm，大家可以关注它。

如果您没有使用这个社交网络，请记住，您始终可以通过 GitHub 关注仓库；这项功能在过去几个月得到了改进，现在可以仅针对发布进行通知，因此无论如何您都应该考虑使用它。

未来展望 🎓​

在过去的 7-8 个月里，核心贡献者增强了 React Native 社区 GitHub 组织，以对 React Native 的开发承担更多责任，并加强与 Facebook 的协作。但一直以来都缺乏类似项目可能已有的正式结构。

该组织可以通过为其托管的所有包/仓库实施一组标准，为维护人员提供一个互相帮助并贡献符合社区商定标准的优质代码的场所，从而为大型开发者社区中的每个人树立榜样。

2019 年初，我们将制定这套新的指南。请在 专门的讨论 中告诉我们您的想法。

我们相信，通过这些变化，社区将变得更加协作，这样当我们达到 1.0 版本时，我们都将继续利用这种共同努力编写（更多）很棒的应用程序 🤗

我希望您对这个社区的未来与我们一样充满期待。我们很高兴看到大家参与到上面列出的仓库中的讨论或通过你们编写的优秀代码中。

编码愉快！

今年，React Native 团队专注于对 React Native 进行大规模 重新架构。正如 Sophie 在她的 React Native 状态文章 中提到的，我们已经制定了一个计划，以更好地支持蓬勃发展的 React Native 用户和 Facebook 外部的协作者群体。现在是时候分享更多关于我们一直在努力的事情的细节了。在这样做之前，我想阐明我们对 React Native 开源的长期愿景。

我们对 React Native 的愿景是……

• 一个健康的 GitHub 仓库。问题和拉取请求在合理的时间内得到处理。
  • 提高测试覆盖率。
  • 从 Facebook 代码仓库同步的提交不应破坏开源测试。
  • 更高水平的有意义的社区贡献。
• 稳定的 API，使与开源依赖项的交互更容易。
  • Facebook 使用与开源相同的公共 API
  • 遵循语义版本控制的 React Native 版本。
• 充满活力的生态系统。由社区维护的高质量 ViewManagers、原生模块和多平台支持。
• 优秀的文档。专注于帮助用户创建高质量体验，以及最新的 API 参考文档。

我们已经确定了以下重点领域，以帮助我们实现这一愿景。

✂️ 精简核心​

我们的目标是 减少 React Native 的表面积，方法是移除非核心和未使用的组件。我们将把非核心组件转移到社区，以使其能够更快地发展。减少的表面积将使管理对 React Native 的贡献变得更容易。

WebView 是我们转移到社区的一个组件示例。我们正在开发一个工作流程，允许内部团队在我们从仓库中移除这些组件后继续使用它们。我们已经确定了 数十个其他组件，我们将把它们的拥有权交给社区。

🎁 开源内部组件和 🛠更新工具​

Facebook 产品团队的 React Native 开发体验可能与开源体验大不相同。开源社区中可能流行的工具在 Facebook 中未使用。可能存在一个内部工具可以实现相同的目的。在某些情况下，Facebook 团队已经习惯了 Facebook 外部不存在的工具。当我们开源即将推出的架构工作时，这些差异可能会带来挑战。

我们将努力发布其中一些内部工具。我们还将改进对开源社区流行工具的支持。以下是我们将解决的项目清单（非详尽）：

• 开源 JSI 并使社区能够引入自己的 JavaScript VM，替换 RN 初始版本中现有的 JavaScriptCore。我们将在未来的文章中介绍 JSI 是什么，在此期间，您可以从 Parashuram 在 React Conf 上的演讲 中了解更多关于 JSI 的信息。
• 支持 Android 上的 64 位库。
• 在新架构下启用调试。
• 改进对 CocoaPods、Gradle、Maven 和新的 Xcode 构建系统的支持。

✅ 测试基础设施​

当 Facebook 工程师发布代码时，如果通过所有测试，则认为该代码可以安全地合并。这些测试可以识别更改是否可能破坏我们自己的 React Native 表面。然而，Facebook 使用 React Native 的方式存在差异。这使得我们不知不觉地在开源中破坏了 React Native。

我们将加强内部测试，以确保它们在尽可能接近开源的环境中运行。这将有助于防止破坏这些测试的代码进入开源。我们还将致力于基础设施，以在 GitHub 上更好地测试核心仓库，使未来的拉取请求能够轻松包含测试。

结合减少的表面积，这将使贡献者能够更快、更有信心地合并拉取请求。

📜 公共 API​

Facebook 将通过公共 API 使用 React Native，就像开源一样，以减少意外的破坏性更改。我们已经开始转换内部调用站点以解决此问题。我们的目标是融合到一个稳定的公共 API，从而在 1.0 版本中采用语义版本控制。

📣 沟通​

React Native 是 GitHub 上最受欢迎的开源项目之一（按贡献者数量计算）。这让我们非常高兴，我们希望继续保持这种势头。我们将继续开展有助于吸引贡献者的举措，例如提高透明度和开放讨论。文档是 React Native 新手遇到的第一件事之一，但它一直不是重点。我们希望解决这个问题，首先是恢复自动生成的 API 参考文档，创建更多内容，专注于创建 高质量的用户体验，并改进我们的 发行说明。

时间线​

我们计划在未来一年左右的时间内完成这些项目。其中一些工作已经开始，例如 JSI 已经合并到开源中。其他一些工作需要更长的时间才能完成，例如减少表面积。我们将尽最大努力让社区了解我们的进展。请加入 讨论和建议 仓库，这是一个 React Native 社区的倡议，它促成了本路线图中讨论的多个举措的创建。

长期以来，苹果一直建议开发者使用 WKWebView 而不是 UIWebViews。在即将发布的 iOS 12 中，UIWebViews 将正式弃用。React Native 的 iOS WebView 实现严重依赖 UIWebView 类。因此，鉴于这些发展，我们为 WebView React Native 组件构建了一个新的原生 iOS 后端，该后端使用 WKWebView。

这些更改的最终版本已在此提交中实现，并将包含在 0.57 版本中。

要启用此新实现，请使用useWebKit 属性。

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

改进​

UIWebView 无法提供在 WebView 中运行的 JavaScript 与 React Native 之间进行通信的合法途径。当从 WebView 发送消息时，我们依靠一种 hack 方法将其传递给 React Native。简单来说，我们将消息数据编码为具有特殊方案的 url，并导航 WebView 到该 url。在原生端，我们拦截并取消了此导航，从 url 中解析数据，最后调用 React Native。这种实现容易出错且不安全。我很高兴地宣布，我们已利用 WKWebView 功能完全替换了它。

与 UIWebView 相比，WKWebView 的其他优势包括更快的 JavaScript 执行和多进程架构。请参阅此2014 年 WWDC以了解更多详细信息。

注意事项​

如果您的组件使用以下属性，则在切换到 WKWebView 时可能会遇到问题。目前，我们建议您避免使用这些属性。

不一致的行为

automaticallyAdjustContentInsets 和 contentInsets (提交)

当您向 WKWebView 添加 contentInsets 时，它不会更改 WKWebView 的视口。视口的大小保持与框架相同。使用 UIWebView 时，视口大小实际上会发生变化（如果内容内边距为正，则会变小）。

backgroundColor (提交)

使用 WebView 的新 iOS 实现，如果您使用此属性，则您的背景颜色可能会闪烁到视图中。此外，WKWebView 以与 UIWebview 不同的方式呈现透明背景。请查看提交说明以了解更多详细信息。

不支持

scalesPageToFit (提交)

WKWebView 不支持 scalesPageToFit 属性，因此我们无法在 WebView React Native 组件上实现此功能。

动机​

随着技术的进步和移动应用程序在日常生活中的重要性日益增加，创建无障碍应用程序的必要性也随之增长。

React Native 有限的辅助功能 API 一直是开发人员的一个巨大痛点，因此我们对辅助功能 API 进行了一些更新，以便更容易创建包容性的移动应用程序。

现有 API 的问题​

问题一：两个完全不同但相似的属性 - accessibilityComponentType（Android）和 accessibilityTraits（iOS）​

accessibilityComponentType 和 accessibilityTraits 是两个用于告诉 Android 上的 TalkBack 和 iOS 上的 VoiceOver 用户正在与哪种 UI 元素交互的属性。这两个属性最大的两个问题是

1. 它们是两个具有不同使用方法但具有相同目的的不同属性。在以前的 API 中，这两个是两个独立的属性（每个平台一个），这不仅不方便，而且也让许多开发者感到困惑。iOS 上的 accessibilityTraits 允许 17 个不同的值，而 Android 上的 accessibilityComponentType 仅允许 4 个值。此外，这些值在大多数情况下没有重叠。即使这两个属性的输入类型也不同。accessibilityTraits 允许传入一个 traits 数组或单个 trait，而 accessibilityComponentType 仅允许一个值。
2. Android 上的功能非常有限。使用旧属性，Talkback 唯一能够识别的 UI 元素是“button”、“radiobutton_checked”和“radiobutton_unchecked”。

问题二：不存在辅助功能提示：​

辅助功能提示可以帮助使用 TalkBack 或 VoiceOver 的用户了解当他们在辅助功能元素上执行操作时会发生什么，而仅通过辅助功能标签无法清楚地了解这些操作。可以在设置面板中打开或关闭这些提示。以前，React Native 的 API 完全不支持辅助功能提示。

问题三：忽略反转颜色：​

一些视力障碍的用户在其手机上使用反转颜色以获得更大的屏幕对比度。Apple 为 iOS 提供了一个 API，允许开发者忽略某些视图。这样，当用户打开反转颜色设置时，图像和视频就不会失真。React Native 目前不支持此 API。

新 API 的设计​

解决方案一：组合 accessibilityComponentType（Android）和 accessibilityTraits（iOS）​

为了解决 accessibilityComponentType 和 accessibilityTraits 之间的混淆，我们决定将它们合并到一个属性中。这样做是有道理的，因为它们在技术上具有相同的预期功能，并且通过合并它们，开发人员在构建辅助功能时不再需要担心特定于平台的复杂性。

背景

在 iOS 中，UIAccessibilityTraits 是可以设置在任何 NSObject 上的属性。通过 javascript 属性传递到原生的 17 个 traits 中的每一个都映射到 Objective-C 中的 UIAccessibilityTraits 元素。每个 traits 都由一个长整型表示，并且设置的每个 traits 都通过按位或运算组合在一起。

然而，在 Android 中，AccessibilityComponentType 是 React Native 创造的一个概念，并不直接映射到 Android 中的任何属性。辅助功能由辅助功能委托处理。每个视图都有一个默认的辅助功能委托。如果您想自定义任何辅助功能操作，则必须创建一个新的辅助功能委托，覆盖您想自定义的特定方法，然后将您正在处理的视图的辅助功能委托设置为与新委托相关联。当开发人员设置 AccessibilityComponentType 时，原生代码会根据传入的组件创建一个新的委托，并设置视图以拥有该辅助功能委托。

做出的更改

对于我们的新属性，我们希望创建一个这两个属性的超集。我们决定使新属性主要模仿现有的属性 accessibilityTraits，因为 accessibilityTraits 具有明显更多的值。将通过修改辅助功能委托来填充这些 traits 在 Android 上的功能。

iOS 上的 accessibilityTraits 可以设置为 17 个 UIAccessibilityTraits 值。但是，我们并没有将所有这些值都包含为我们新属性的可能值。这是因为设置其中一些 traits 的效果实际上并不为人所知，并且许多这些值实际上从未使用过。

UIAccessibilityTraits 设置的值通常具有两个目的之一。它们要么描述 UI 元素具有的角色，要么描述 UI 元素所处的状态。我们观察到的以前属性的大多数用法通常使用一个表示角色的值，并将其与“state selected”、“state disabled”或两者结合使用。因此，我们决定创建两个新的辅助功能属性：accessibilityRole 和 accessibilityState。

accessibilityRole

新属性 accessibilityRole 用于告诉 Talkback 或 Voiceover UI 元素的角色。此新属性可以采用以下值之一

• none
• button
• link
• search
• image
• keyboardkey
• text
• adjustable
• header
• summary
• imagebutton

此属性仅允许传入一个值，因为 UI 元素通常在逻辑上不会采用多个值。例外情况是 image 和 button，因此我们添加了一个 imagebutton 角色，它是两者的组合。

accessibilityStates

新属性 accessibilityStates 用于告诉 Talkback 或 Voiceover UI 元素所处的状态。此属性采用包含以下值之一或两个值的数组

• selected
• disabled

解决方案二：添加辅助功能提示​

为此，我们添加了一个新属性 accessibilityHint。设置此属性将允许 Talkback 或 Voiceover 向用户朗读提示。

accessibilityHint

此属性以字符串的形式接收要读取的辅助功能提示。

在 iOS 中，设置此属性将设置视图上相应的原生属性 AccessibilityHint。如果在 iPhone 中启用了辅助功能提示，则 Voiceover 将读取该提示。

在 Android 中，设置此属性会将提示的值附加到辅助功能标签的末尾。这种实现的优点在于它模拟了 iOS 上提示的行为，但缺点是这些提示无法像在 iOS 上那样在 Android 的设置中关闭。

我们在 Android 上做出此决定的原因是，通常，辅助功能提示与特定操作（例如点击）相对应，我们希望跨平台保持行为一致。

问题三的解决方案​

accessibilityIgnoresInvertColors

我们将 Apple 的 api AccessibilityIgnoresInvertColors 公开给了 JavaScript，因此现在当您有一个不想反转颜色的视图（例如图像）时，您可以将此属性设置为 true，它就不会被反转。

新用法​

这些新属性将在 React Native 0.57 版本中可用。

如何升级​

如果您当前正在使用 accessibilityComponentType 和 accessibilityTraits，以下是如何升级到新属性的步骤。

1. 使用 jscodeshift​

最简单的用例可以通过运行 jscodeshift 脚本进行替换。

这个 脚本 替换以下实例

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

为

accessibilityRole= “trait”

此脚本还删除了 AccessibilityComponentType 的实例（假设在您设置 AccessibilityComponentType 的所有地方，您也会设置 AccessibilityTraits）。

2. 使用手动代码修改​

对于使用 AccessibilityTraits 但没有对应 AccessibilityRole 值的用例，以及将多个特征传递到 AccessibilityTraits 的用例，则需要进行手动代码修改。

一般来说，

accessibilityTraits= {[“button”, “selected”]}

将手动替换为

accessibilityRole=“button”
accessibilityStates={[“selected”]}

这些属性已经在 Facebook 的代码库中使用。Facebook 的代码修改出奇地简单。jscodeshift 脚本修复了大约一半的实例，另一半则手动修复。总体而言，整个过程花费不到几个小时。

希望您会发现更新的 API 有用！并请继续使应用更易访问！#inclusion

期待已久的 React Native 0.56 版本现已推出 🎉。此博文重点介绍了此新版本中引入的一些 更改。我们还想借此机会解释自 3 月以来我们一直在忙些什么。

重大更改的困境，或“何时发布？”​

该 贡献者指南 解释了所有对 React Native 的更改所经历的集成过程。该项目由 许多不同的工具 组成，需要协调和持续的支持才能使一切正常运行。再加上积极的开源社区回馈项目，您就会了解其令人难以置信的规模。

随着 React Native 令人印象深刻的采用，必须谨慎进行重大更改，并且该过程并不像我们希望的那样顺利。决定跳过 4 月份和 5 月份的版本，以允许核心团队集成和测试一组新的重大更改。专门的社区沟通 渠道一直被使用，以确保 2018 年 6 月 (0.56.0) 版本尽可能易于被耐心等待稳定版本的用户采用。

0.56.0 是否完美？不，就像每个软件一样：但我们达到了一个点，即“等待更多稳定性”与“测试导致成功结果，因此我们可以继续推进”之间的权衡，我们认为自己已准备好发布它。此外，我们意识到 一些 问题 未 在最终的 0.56.0 版本中解决。大多数开发人员在升级到 0.56.0 时应该不会遇到任何问题。对于那些被上述问题阻碍的用户，我们希望在我们的讨论中见到您，我们期待与您一起解决这些问题。

您可能会将 0.56.0 视为构建更稳定框架的基础构建块：可能需要一两周的广泛采用才能解决所有边缘情况，但这将带来更好的 2018 年 7 月 (0.57.0) 版本。

我们想在结束本节时感谢 所有 67 位贡献者，他们总共提交了 818 次提交（！），这将有助于使您的应用变得更好 👏。

现在，事不宜迟……

重大更改​

Babel 7​

您可能知道，允许我们使用 JavaScript 最新和最棒功能的编译器工具 Babel 即将迁移到 v7。由于此新版本带来了一些重要更改，因此我们认为现在是升级的好时机，允许 Metro 利用其改进。

如果您在升级过程中遇到问题，请参阅 与之相关的文档部分。

现代化 Android 支持​

在 Android 上，许多周围的工具已发生变化。我们已更新到 Gradle 3.5、Android SDK 26、Fresco 到 1.9.0 和 OkHttp 到 3.10.0，甚至 NDK API 目标到 API 16。这些更改应该不会出现问题，并且可以加快构建速度。更重要的是，它将帮助开发人员遵守 下个月生效的新 Play 商店要求。

与此相关，我们想特别感谢 Dulmandakh 为此提交的许多 PR 👏。

在此方向上还需要采取一些步骤，您可以关注更新 Android 支持的未来规划和讨论 专用问题（以及 JSC 的一个辅助问题）。

新的 Node、Xcode、React 和 Flow - 哦，我的天！​

Node 8 现在是 React Native 的标准。它实际上已经在测试中了，但随着 Node 6 进入维护模式，我们已经全力以赴。React 也更新到了 16.4，其中包含大量修复。

我们放弃了对 iOS 8 的支持，使 iOS 9 成为可以定位的最旧 iOS 版本。我们预计这不会成为问题，因为任何可以运行 iOS 8 的设备都可以升级到 iOS 9。此更改使我们能够删除很少使用的代码，这些代码实现了针对运行 iOS 8 的旧设备的解决方法。

持续集成工具链已更新 到 Xcode 9.4，确保所有 iOS 测试都在 Apple 提供的最新开发工具上运行。

我们已升级到 Flow 0.75 以使用新的错误格式 许多开发者都喜欢。我们还为更多组件创建了类型。如果您尚未在项目中强制执行静态类型，请考虑使用 Flow 在编码时而不是在运行时识别问题。

以及很多其他事情……​

例如，YellowBox 已 替换 为新的实现，使调试变得更好。

有关完整的发布说明，请参阅此处完整的 更改日志。并记住关注 升级指南 以避免迁移到此新版本时出现问题。

最后说明：从本周开始，React Native 核心团队将恢复每月举行会议。我们将确保让每个人了解会议内容，并确保在未来的会议中收集您的反馈。

祝大家编码愉快！

Lorenzo、Ryan 和整个 React Native 核心团队

附注：与往常一样，我们想提醒大家，React Native 仍处于 0.x 版本，因为许多更改仍在进行中 - 因此请记住，在升级时，可能某些内容仍然会崩溃或出现故障。在问题和提交 PR 时互相帮助 - 并记住遵守执行的 CoC：屏幕的另一端总是有一个人。