代码与社区健康​

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

在过去六个月中，平均每天的 Pull Request 数量已从三个增加到大约六个，尽管我们通过精简核心工作将网站、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，完成了 flow 类型原生模块的工作。除了上面已经提到的人员之外，我们还要感谢Michał Chudziak、Michał Pierzchała、Wojtek Szafraniec 和Jean Regisser 以及所有提交了一个或多个 Pull Request 的人。
• 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 多个 Pull Request。除了更好的维护，这些项目还可以比 React Native 本身更频繁地独立发布。

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

这项工作仍在进行中，在原生和 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) 版本。此外，我们一直在努力使默认启用 inline-requires 更加容易，并且在接下来的几个月里，我们还有更多激动人心的更新。
• 文档：我们最近开始努力 彻底审查和重写 React Native 的所有文档。如果您想贡献，我们非常欢迎您的帮助！
• Xcode 中的警告：我们 消除了所有现有的警告，并正努力避免引入新警告。
• 热重载：React 团队正在构建一个 新的热重载系统，该系统将很快集成到 React Native 中。

不幸的是，我们尚未能改进所有方面。

• 调试： 我们修复了许多人们日常遇到的不便的 bug 和问题，但不幸的是，我们在这方面取得的进展不如预期。我们认识到使用 React Native 进行调试体验不佳，未来我们将优先改进这一点。
• Metro 符号链接：不幸的是，我们尚未能为此找到一个简单直接的解决方案。但是，React Native 用户 分享了各种可能的变通方法，也许对您有用。

鉴于过去六个月的大量更改，我们想再次问您同样的问题。如果您正在使用最新版本的 React Native，并且有什么希望提供反馈，请在我们的新版 “你对 React Native 有什么不满？” 中评论。

持续集成​

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

React Native 团队的 Héctor Ramos 在过去两个月里一直在改进 Facebook 和 GitHub 上的 React Native 的持续集成系统。现在，Facebook 提交更改之前，大部分开源测试都在运行，这将使 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 平台 (UWP) 上进行渲染。请关注下周的 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 Requests。
• 接下来，我们将专注于彻底改造 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 是一个庞大而复杂的项目，拥有一个复杂的存储库。这使得代码库对于贡献者来说难以接近，难以测试，并且作为开发依赖项过于庞大。精简核心是我们通过将代码迁移到独立库以实现更好管理的努力。过去几个版本的发布已经迈出了第一步，但让我们认真对待。

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

在接下来的几个月里，将有更多的组件遵循这一精简核心的路径。我们正在寻求这方面的帮助 — 请访问精简核心总览以贡献您的力量。

👩🏽‍💻 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 工作原理和为公益做出贡献的好方法。谢谢！请关注未来类似的 issues。

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

今年剩下的时间里，我们还将带来更多改进。敬请期待！

Ryan 和整个React Native 核心团队

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

作为我们的第一个里程碑，我们专注于识别和改进社区最显著的方面。我们的目标是减少未处理的拉取请求，缩小项目的表面积，识别主要的用户问题，并建立社区管理指南。

在过去的两个月里，我们取得了比预期更多的进展。请继续阅读以了解更多详情

拉取请求​

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

我们合并了 近三分之二 的 pull requests，关闭了三分之一。如果 pull requests 过时、质量低下或不必要地增加了项目的表面积，它们就会被关闭而未被合并。大多数合并的 pull requests 修复了 bug、提高了跨平台一致性或引入了新功能。值得注意的贡献包括提高了类型安全性以及正在进行的 AndroidX 支持工作。

在 Facebook，我们从 master 分支运行 React Native，因此我们在将所有更改发布到 React Native Release 之前首先进行测试。在所有合并的拉取请求中，只有六个导致了问题：四个只影响内部开发，两个在发布候选阶段被发现。

一项更引人注目的社区贡献是 更新的“RedBox”屏幕。这是社区让开发者体验更友好的一个很好的例子。

精简核心​

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

在第一个里程碑中，我们 向社区寻求 Lean Core 项目的帮助。反响非常热烈，我们几乎跟不上所有进展。 查看不到一个月内完成的所有工作！

让我们最激动的是，维护者们已经积极地修复了长期存在的问题，添加了测试，并支持了长期以来大家要求的功能。这些模块获得了比以往在 React Native 内更多的支持，表明这是社区迈出的重要一步。例如， WebView 在被提取后 收到了许多 pull requests，而 CLI 现在 由社区成员维护 并获得了急需的改进和修复。

主要用户问题​

12 月份，我们询问社区 他们不喜欢 React Native 的地方。我们汇总了这些反馈并 对每一个问题都进行了回复。幸运的是，社区面临的许多问题也是 Facebook 面临的问题。在下一个里程碑中，我们计划解决一些主要问题。

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

• Callstack 的 Michał Pierzchała 通过在后台使用 rn-diff-purge 改进了 react-native 升级。我们还更新了网站，删除了过时的升级说明。
• 我们计划默认推荐 iOS 项目使用 CocoaPods，这将减少升级 React Native 时项目文件的变动。这将使人们更容易安装和链接第三方模块，这在 Lean Core 项目的背景下尤为重要，因为我们预计项目默认将链接更多模块。

0.59 版本​

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

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

这些计划中的许多内容将纳入即将发布的 React Native 0.59 版本。0.59 将支持 React Hooks，为 Android 提供新的 64 位 JavaScriptCore 版本，并包含许多性能和功能改进。该版本目前已发布为候选版本，预计将在两周内稳定。

后续步骤​

在接下来的两个月里，我们将继续管理 pull requests 以保持进度，同时开始减少未关闭的 GitHub issue 数量。我们将继续通过 Lean Core 项目减少 React Native 的表面积。我们计划解决 5 个社区面临的首要问题。随着社区指南的最终确定，我们将把注意力转向我们的网站和文档。

我们非常高兴在三月份在 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 📬​

该存储库创建于一月，它兼具双重目的：允许每个人以更协作的方式跟上新版本，并向任何想要建议cherry-pick（例如0.57.8及其所有先前版本）的人开放了关于特定版本内容的讨论。

这是推动月度发布周期转变以及当前用于 0.57.x 版本的“长期支持”方法背后的驱动力。

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

discussions-and-proposals 🗣​

该存储库创建于七月，它扩展了关于React Native更开放的对话环境的想法。以前，这一需求由主存储库中标记为For Discussion的问题来处理，但我们希望将此策略扩展到其他库（例如React）所采用的RFC方法。

这项实验立即在React Native的生命周期中找到了自己的作用。Facebook团队现在正在使用社区RFC流程来讨论可以改进React Native的地方，并协调围绕Lean Core项目的努力——以及其他有趣的讨论。

@ReactNativeComm 🐣​

我们意识到，我们沟通这些努力的方法没有达到我们期望的有效性，为了让大家更容易跟上React Native社区中发生的一切（从发布到活跃的讨论），我们创建了一个新的Twitter账号，您可以依赖它：@ReactNativeComm。

如果您不在该社交网络上，请记住您始终可以通过 GitHub 监视仓库；此功能在过去几个月有所改进，现在可以只接收发布通知，所以无论如何您都应该考虑使用它。

未来展望 🎓​

在过去的7-8个月里，核心贡献者增强了React Native Community GitHub组织，以承担更多React Native开发的责任，并加强与Facebook的协作。但这一切一直缺乏与其他类似项目相同的正式结构。

这个组织可以通过对其中托管的所有包/仓库强制执行一套标准，为维护者提供一个互相帮助和贡献符合社区约定质量代码的单一场所，从而为更广泛的开发者社区树立榜样。

在2019年初，我们将实施这套新的指导方针。请在专门的讨论区告诉我们您的想法。

我们相信，通过这些改变，社区将变得更具协作性，这样当我们达到 1.0 版本时，我们都将继续通过这项共同努力来编写（更）出色的应用程序 🤗

我希望您和我们一样对这个社区的未来感到兴奋。我们很高兴看到您参与到上述仓库中的讨论或您将创作的精彩代码中。

快乐编码！

今年，React Native 团队一直专注于进行大规模的 React Native 重构。正如 Sophie 在她的 《React Native 现状》博文中提到的那样，我们已经制定了一个计划，以更好地支持 Facebook 之外蓬勃发展的 React Native 用户和贡献者群体。现在是时候分享我们一直在进行的工作的更多细节了。在此之前，我想阐述一下我们对 React Native 开源的长期愿景。

我们对 React Native 的愿景是……

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

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

✂️ 精简核心​

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

WebView 是一个我们已转移给社区的组件示例。我们正在制定一个工作流程，以便内部团队在我们将这些组件从仓库中移除后，能够继续使用它们。我们已经确定了 数十个更多组件 将移交给社区进行管理。

🎁 开源内部结构和 🛠更新工具​

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

我们将努力发布一些内部工具。我们还将改进对开源社区流行工具的支持。以下是我们将要解决的项目的不完全列表

• 开源 JSI 并允许社区引入自己的 JavaScript 虚拟机，替换 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 社区的一项举措，促成了本路线图中讨论的几项工作的诞生。

长期以来，Apple 一直不鼓励使用 UIWebView，转而推荐 WKWebView。在即将在未来几个月发布的 iOS 12 中，UIWebView 将被正式弃用。React Native 的 iOS WebView 实现严重依赖 UIWebView 类。因此，鉴于这些发展，我们为使用 WKWebView 的 WebView React Native 组件构建了一个新的原生 iOS 后端。

这些更改的最后部分已合并到此提交，并且将在 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 的特性来完全取代它。

WKWebView 相较于 UIWebView 的其他优势包括更快的 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 允许传入特性数组或单个特性，而 accessibilityComponentType 只允许单个值。
2. Android上的功能非常有限。使用旧属性，Talkback 唯一能识别的 UI 元素是“按钮”、“单选按钮已选中”和“单选按钮未选中”。

问题二：不存在的无障碍提示：​

无障碍提示可帮助使用 TalkBack 或 VoiceOver 的用户了解当他们对无障碍元素执行操作时会发生什么，而这些信息仅凭无障碍标签是无法得知的。这些提示可以在设置面板中开启和关闭。以前，React Native 的 API 完全不支持无障碍提示。

问题三：忽略反色：​

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

新 API 的设计​

解决方案一：合并 accessibilityComponentType (Android) 和 accessibilityTraits (iOS)​

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

背景

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

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

所做的更改

对于我们的新属性，我们希望创建这两个属性的超集。我们决定主要以现有属性 accessibilityTraits 为蓝本设计新属性，因为 accessibilityTraits 的值明显更多。Android 对这些特性的功能将通过修改无障碍委托进行兼容。

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

UIAccessibilityTraits 的值通常具有两种目的之一。它们要么描述 UI 元素所扮演的角色，要么描述 UI 元素所处的状态。我们观察到的以前属性的大多数用法通常使用一个表示角色的值，并将其与“已选状态”、“已禁用状态”或两者结合使用。因此，我们决定创建两个新的无障碍属性：accessibilityRole 和 accessibilityState。

accessibilityRole

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

• 无
• 按钮
• 链接
• 搜索
• 图片
• 键盘键
• 文本
• 可调整
• 标题
• 总结
• 图片按钮

此属性只允许传入一个值，因为UI元素通常逻辑上不会承担其中多个角色。例外是图片和按钮，因此我们添加了一个组合两者的角色“图片按钮”。

辅助功能状态

新属性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很有用！并请继续让应用程序无障碍！#包容

备受期待的 React Native 0.56 版本现已发布 🎉。本文将重点介绍此新版本中的一些更改。我们还想借此机会解释一下自三月份以来我们一直忙于哪些事情。

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

《贡献者指南》解释了 React Native 的所有更改都必须经历的集成过程。该项目由许多不同的工具组成，需要协调和持续支持才能使一切正常运行。再加上为项目做出贡献的充满活力的开源社区，您将体会到这一切的宏大规模。

随着 React Native 的广泛应用，破坏性更改必须格外小心地进行，而且这个过程并非我们期望的那么顺利。我们决定跳过四月和五月的发布，以便核心团队能够集成和测试一套新的破坏性更改。在此过程中，我们使用了专门的社区沟通渠道，以确保 2018 年 6 月（0.56.0）版本对那些耐心等待稳定版本的用户来说尽可能轻松。

0.56.0 完美吗？不，就像任何软件一样：但我们已经达到了一个点，在“等待更多稳定性”与“测试带来了成功的结果，因此我们可以继续前进”之间的权衡，让我们觉得已经准备好发布。此外，我们也意识到一些未在最终的 0.56.0 版本中解决的问题。大多数开发者应该可以轻松地升级到 0.56.0。对于那些被上述问题困扰的开发者，我们希望在我们的讨论中能见到您，并期待与您一起解决这些问题。

您可以将 0.56.0 视为构建更稳定框架的基础：可能需要一到两周的广泛采用才能消除所有边缘情况，但这将导致 2018 年 7 月 (0.57.0) 发布更加出色。

我们想借此机会感谢所有 67 位贡献者，他们提交了总计 818 个 commit（！），这些提交将使您的应用程序变得更好 👏。

现在，话不多说...

重大更改​

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，从而使之成为可能 👏。

在这一方向上还需要采取一些进一步的措施，您可以在专用 issue（以及关于JSC的附带 issue）中跟踪 Android 支持更新的未来规划和讨论。

新的 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 版本，因为仍有许多更改正在进行中——所以请记住，在升级时，是的，很可能仍然会遇到崩溃或损坏的情况。请在 issue 和提交 PR 时互相帮助——并请记住遵守强制执行的行为准则：屏幕的另一边总是一个活生生的人。

距离我们上次发布 React Native 的状态更新已经有一段时间了。

在 Facebook，我们比以往任何时候都更多地使用 React Native，并且将其用于许多重要项目。我们最受欢迎的产品之一是 Marketplace，它是我们应用程序中顶级标签之一，每月有 8 亿人使用。自 2015 年创建以来，Marketplace 的所有内容都使用 React Native 构建，包括应用程序不同部分的数百个全屏视图。

我们也在使用 React Native 开发应用的许多新部分。如果你看了上个月的 F8 主题演讲，你就会认识血型捐赠（Blood Donations）、危机响应（Crisis Response）、隐私快捷方式（Privacy Shortcuts）和健康检查（Wellness Checks）——这些都是最近用 React Native 构建的功能。Facebook 应用主应用之外的项目也在使用 React Native。新的 Oculus Go VR 头显包含 一个配套的移动应用，该应用完全用 React Native 构建，更不用说头显本身许多体验都由 React VR 提供支持。

当然，我们也使用许多其他技术来构建我们的应用。 Litho 和 ComponentKit 是我们在应用中广泛使用的两个库；它们都提供了一个类似 React 的组件 API 来构建原生屏幕。React Native 从未有过取代所有其他技术的宏伟目标——我们专注于让 React Native 本身变得更好，但我们很高兴看到其他团队借鉴 React Native 的理念，比如将 即时重载 应用到非 JavaScript 代码中。

架构​

当我们在 2013 年启动 React Native 项目时，我们设计了一个在 JavaScript 和原生之间、异步、可序列化且可批量处理的单一“桥梁”。就像 React DOM 将 React 状态更新转化为命令式的、可变的对 DOM API 的调用，例如 document.createElement(attrs) 和 .appendChild()，React Native 被设计成返回一个单一的 JSON 消息，列出要执行的变异操作，例如 [["createView", attrs], ["manageChildren", ...]]。我们设计整个系统是为了永不依赖同步响应，并确保列表中所有内容都可以完全序列化为 JSON 并返回。我们这样做是为了获得灵活性：基于这种架构，我们能够构建像 Chrome 调试 这样的工具，它通过 WebSocket 连接异步运行所有 JavaScript 代码。

在过去的 5 年里，我们发现这些最初的原则使得构建某些功能变得更加困难。异步桥接意味着您无法将 JavaScript 逻辑直接与许多期望同步响应的原生 API 集成。批处理桥接会队列化原生调用，这意味着 React Native 应用程序更难调用原生实现的功能。可序列化桥接意味着不必要的复制，而不是直接在两个世界之间共享内存。对于完全用 React Native 构建的应用程序，这些限制通常是可以忍受的。但对于 React Native 和现有应用程序代码之间复杂集成的应用程序，它们令人沮丧。

我们正在对 React Native 进行大规模的重新架构，以使框架更灵活，并在混合 JavaScript/原生应用程序中更好地与原生基础设施集成。通过这个项目，我们将应用我们在过去 5 年中学到的知识，并逐步将我们的架构带入更现代的境界。我们正在重写 React Native 的许多内部组件，但大部分更改都在幕后：现有的 React Native 应用程序将继续运行，几乎不需要或根本不需要更改。

为了让 React Native 更轻量级，并更好地融入现有的原生应用，这次架构重组有三个主要的内部变化。首先，我们正在改变线程模型。现在，每个 UI 更新不再需要在一三个不同的线程上执行工作，而是可以在任何线程上同步调用 JavaScript 来处理高优先级更新，同时仍然将低优先级工作移出主线程，以保持响应能力。其次，我们将 异步渲染 功能整合到 React Native 中，以允许多渲染优先级并简化异步数据处理。最后，我们正在简化我们的桥接，使其更快、更轻量级；原生和 JavaScript 之间的直接调用更有效率，并将使构建跨语言堆栈跟踪等调试工具更加容易。

一旦这些更改完成，更紧密的集成将成为可能。如今，如果没有复杂的 hack，就不可能集成原生导航和手势处理，或者像 UICollectionView 和 RecyclerView 这样的原生组件。在我们对线程模型进行更改之后，构建这样的功能将变得简单直接。

我们将在今年晚些时候，待其接近完成时，发布更多关于这项工作的细节。

社区​

除了 Facebook 内部的社区，我们也很高兴在 Facebook 之外拥有蓬勃发展的 React Native 用户和合作者群体。我们希望通过更好地服务 React Native 用户并使项目更容易贡献，来更多地支持 React Native 社区。

正如我们的架构更改将帮助 React Native 更清晰地与其他原生基础设施互操作一样，React Native 在 JavaScript 方面也应该更精简，以便更好地适应 JavaScript 生态系统，其中包括使 VM 和打包器可互换。我们知道破坏性更改的速度可能难以跟上，因此我们希望找到减少主要版本发布的方法。最后，我们知道有些团队正在寻求更详尽的文档，例如启动优化等主题，而我们的专业知识尚未被记录下来。预计在未来一年内会看到其中一些变化。

如果您正在使用 React Native，您就是我们社区的一员；请继续告诉我们如何才能让 React Native 为您做得更好。

React Native只是移动开发人员工具箱中的一个工具，但我们坚信它——而且我们每天都在让它变得更好，去年有500多名贡献者提交了2500多次提交。