代码与社区健康​

过去六个月中，超过 550 位贡献者为 React Native 提交了总计 2800 次代码提交。社区中的 400 位贡献者创建了超过 1,150 个 Pull Request，其中 820 个 Pull Request 已被合并。

尽管我们通过 Lean Core 计划将官网、CLI 和多个模块从 React Native 中拆分出来，过去六个月日均 Pull Request 数量仍从三个增至约六个。目前平均未处理 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。为多个组件补充缺失的无障碍角色，新增 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 个 Pull Request 来完成 flow 类型原生模块的工作。除了前文提到的贡献者外，我们还要感谢 Michał Chudziak、Michał Pierzchała、Wojtek Szafraniec 和 Jean Regisser 等所有提交过 Pull Request 的贡献者。

• Haste： 自 2015 年起，React Native 一直使用 “haste” 模块系统，该系统允许通过全局 ID 而非相对路径导入模块，这种方式虽然便捷但许多工具支持不佳。James Ide 提出移除 haste 模块系统（类似于多年前 React 的做法）。他通过一个总括任务规划了全部工作，并提交了 18 个 Pull Request 来实现这一目标！详情请参阅他的 Twitter 讨论串。

• Android Fragments：John Shelley 提出的通过 Android Fragments 支持 React Native 的提案已合并，将在 0.61 版本中提供。了解更多关于 Android Fragments 的信息。

Lean Core​

Lean Core 的主要目标是将模块从 React Native 中拆分到独立仓库，以便获得更好的维护。短短六个月内，WebView、NetInfo、AsyncStorage、官网 和 CLI 等仓库共接收了超过 800 个 Pull Request。除了更完善的维护外，这些项目还能比 React Native 本身更频繁地独立发布。

我们还借此机会从 React Native 核心移除了过时的 polyfill 和遗留组件。过去为了在旧版 JavaScriptCore (JSC) 中支持 Map 和 Set 等语言特性，polyfill 是必需的。随着 React Native 搭载新版 JSC，这些 polyfill 已被移除。

这项工作仍在进行中，原生和 JavaScript 端仍有大量内容需要拆分或移除，但已有初步迹象表明我们成功扭转了表面积和应用体积的增长趋势：以 JavaScript 包为例，约一年前的 0.54 版本中 React Native JavaScript 包大小为 530kb，六个月内增长到 0.57 版本的 607kb（增加 77kb）。如今在主分支上我们看到包大小减少 28kb 至 579kb，差值超过 100kb！

随着 Lean Core 首阶段工作告一段落，我们将更审慎地考虑新增 React Native API，持续探索减小体积、提升速度的方案，并寻找赋能社区接管各类组件的方法。

用户反馈​

六个月前，我们曾向社区发起提问"您对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。

但仍有部分问题尚未完全解决：

• 调试体验： 虽然修复了许多日常高频出现的缺陷，但调试体验改进仍未达预期。我们深知当前调试体验欠佳，后续将优先优化此环节。

• Metro符号链接： 目前尚未实现简洁解决方案，但React Native用户已分享多种变通方案供您参考。

鉴于近半年的重大变革，我们再次向您提出相同问题：如果您正在使用最新版React Native并希望反馈建议，请参与新版“您对React Native有哪些不满之处？”讨论。

持续集成​

Facebook采用先合并Pull Request至内部仓库，再同步到GitHub的工作流。其基础设施与常规CI服务存在差异，导致部分开源测试未在内部运行，同步到GitHub的提交常引发测试中断且修复耗时。

React Native团队成员Héctor Ramos历时两月优化了Facebook与GitHub的双端CI系统。现在绝大多数开源测试会在变更提交至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 核心架构。

• 微软正通过 React Native for Windows 支持 Universal Windows Platform 开发，让开发者能复用技术栈实现跨平台渲染。欢迎下周关注 Microsoft Build 大会获取更多技术分享。

React Radio 开源专题播客​

Eli 在演讲尾声提及近期开源工作。我们三月已同步进展，近期 Nader Dabit 与 Gant Laborde 更邀请 Christoph 做客 React Native Radio 节目探讨开源生态。

播客要点：​

• 我们探讨了 Facebook React Native 团队对开源的理解，以及如何为超大规模项目构建可持续的社区生态。

• Lean Core 计划进展顺利，WebView 和 React Native CLI 等模块剥离后已收到超 100 个 Pull Request。

• 接下来我们将重点重构 React Native 官网及文档体系，敬请期待！

您可在常用播客平台订阅本期内容，或直接点击收听：

欢迎使用 React Native 0.59 版本！本次重大更新包含 88 位贡献者提交的 644 个 commit。贡献不仅限于代码提交，因此我们要特别_感谢_所有维护 issue、建设社区和传播 React Native 知识的朋友们。本月带来了多项期待已久的功能更新，希望你们喜欢。

🎣 Hooks 正式到来​

React Hooks 已在此版本中正式支持，它让你能够在组件间复用状态逻辑。关于 Hooks 的讨论热度很高，如果你还不了解，不妨看看以下优质资源：

• Introducing Hooks 阐述了我们为何将 Hooks 引入 React
• Hooks at a Glance 快速概览内置 Hooks
• Building Your Own Hooks 演示如何通过自定义 Hooks 实现代码复用
• Making Sense of React Hooks 探索 Hooks 带来的全新可能性
• useHooks.com 展示社区维护的 Hooks 实践方案与示例

强烈建议你在应用中尝试此特性，希望你能和我们一样感受到逻辑复用的魅力。

📱 JSC 更新带来 Android 性能提升与 64 位支持​

React Native 使用 JSC（JavaScriptCore）作为应用的 JavaScript 引擎。此前 Android 平台的 JSC 版本较旧，导致许多现代 JavaScript 特性无法支持，其性能也远逊于 iOS 的现代 JSC 引擎。这个版本彻底改变了这一现状。

感谢 @DanielZlotin、@dulmandakh、@gengjiawen、@kmagiera 和 @kudo 的卓越工作，JSC 现已追平近几年的发展进度。本次更新带来了 64 位支持、现代 JavaScript 特性支持以及显著的性能提升。特别感谢他们建立了可维护的升级流程，让我们未来能够更轻松地获取 WebKit 改进成果，同时感谢 Software Mansion 和 Expo 对此工作的支持。

💨 内联引用加速应用启动​

我们致力于帮助开发者默认获得高性能的 React Native 应用，正努力将 Facebook 的优化方案引入社区。通过按需加载资源而非拖慢启动速度，这项称为 "inline requires"（内联引用）的特性让 Metro 能够识别需要懒加载的组件。具有深层复杂组件结构的应用将获得最显著的性能提升。

在默认启用此功能前，我们需要社区验证其实际效果。升级至 0.59 后，你会看到新的 metro.config.js 文件，只需将对应选项设为 true 并提交你的反馈！更多关于内联引用的内容可参阅性能文档，用于评估你的应用性能。

🚅 核心精简计划启动​

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 的最新建议进行了清理，这可能会导致现有应用出现故障。这个问题可能表现为运行时崩溃，并显示消息"You need to use a Theme.AppCompat theme (or descendant) with this activity"。我们建议更新您项目的 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 内部直接运行 React Native 的 master 分支，因此所有变更在进入正式版本前都经过测试。在所有合并的拉取请求中，仅六个引发了问题：其中四个仅影响内部开发，两个在候选发布阶段就被发现。

社区最显著的贡献之一是 新版“RedBox”错误界面。这充分体现了社区如何让开发者体验更加友好。

Lean Core​

React Native 当前涉及范围过广，包含许多 Facebook 内部较少使用的未维护抽象层。我们正努力缩小范围，使 React Native 更轻量，同时让社区更好地维护 Facebook 较少使用的抽象层。

首个里程碑期间，我们邀请社区协助 Lean Core 项目。响应非常热烈，进展速度甚至让我们应接不暇。查看不到一个月完成的工作成果！

最令人振奋的是，维护者们积极修复了长期存在的问题、补充测试用例并支持了期待已久的功能。这些模块获得的社区支持远超 React Native 内部时期，充分证明这是社区发展的重要一步。典型案例如 WebView，分离后收到大量拉取请求；以及 CLI 工具现由社区成员维护，获得了急需的改进和修复。

主要用户问题​

去年12月，我们向社区征询了对 React Native 的不满之处。我们汇总了反馈，并对每个问题都做出了回应。幸运的是，社区面临的许多问题在 Facebook 内部也同样存在。在下一个里程碑中，我们计划解决其中一些主要问题。

其中投票最高的问题之一就是升级到新版本 React Native 的开发者体验。遗憾的是，由于我们直接从 master 分支运行 React Native，因此自身并未遇到此问题。值得庆幸的是，社区成员已经主动站出来解决这个问题：

• Callstack 的 Michał Pierzchała 在底层使用了 rn-diff-purge 来改进 react-native upgrade 命令。我们还更新了官方网站，移除了过时的升级指南。

• 我们计划默认推荐在 iOS 项目中使用 CocoaPods，这将减少升级 React Native 时项目文件的变动。如此一来，开发者安装和链接第三方模块将更加容易，这在精简核心项目的背景下尤为重要，因为我们预计项目默认会链接更多模块。

0.59 版本发布​

如果没有 React Native 社区的帮助，特别是 Mike Grabowski 和 Lorenzo Sciandra，我们无法完成版本发布。我们希望改进发布管理流程，并计划从今以后更深入地参与：

• 我们将与社区成员合作，为每个主要版本撰写博客文章

• 当开发者升级到新版本时，我们将在 CLI 中直接显示破坏性变更

• 我们将缩短版本发布所需的时间。我们正在探索增加自动化测试的方法，并制定改进的手动测试计划

这些计划中的许多内容将被纳入即将发布的 React Native 0.59 版本中。0.59 版本将包含 React Hooks、适用于 Android 的新版 64 位 JavaScriptCore，以及众多性能和功能改进。该版本目前作为候选版本发布，预计将在未来两周内稳定。

后续计划​

在接下来的两个月里，我们将继续管理拉取请求以确保进度，同时开始减少未解决的 GitHub issue 数量。我们将通过精简核心项目继续缩小 React Native 的涉及范围。我们计划解决5个顶级社区问题。在敲定社区指南后，我们将把注意力转向官方网站和文档。

我们非常激动能在三月份于 Facebook 伦敦办公室接待来自社区的十多位贡献者，共同推动这些工作。我们很高兴您正在使用 React Native，并希望您能看到并感受到我们在2019年所做的改进。几个月后我们将带来下一次更新，而在此期间，我们_将继续合并您的拉取请求！_ ⚛️✌️

2018 年，React Native 社区在开发和沟通方式上做出了一系列调整。我们相信，几年后回顾这段历程时，这次转型将成为 React Native 发展的重要转折点。

许多人对 React Native 架构的重写（即广为人知的 Fabric）感到兴奋。这项改造不仅能解决 React Native 架构中的根本性局限，还将结合 JSI 和 TurboModules 为框架未来的成功奠定基础。

2018 年最重大的转变是赋能 React Native 社区。从最初开始，Facebook 就鼓励全球开发者参与 React Native 开源项目。此后，一批核心贡献者逐渐涌现，开始负责包括版本发布在内的关键工作。

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

react-native-releases 📬​

该仓库创建于 1 月，具有双重使命：既让所有人能以更协作的方式跟进新版本发布，又向任何希望提议特定版本包含内容（如 0.57.8 及其先前版本）的贡献者开放讨论。

这成为我们放弃月度发布周期的主要驱动力，也是当前 0.57.x 版本采用"长期支持"策略的基石。

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

discussions-and-proposals 🗣​

7 月创建的该仓库拓展了 React Native 开放讨论的理念。此前这项工作由主仓库中标记为 For Discussion 的 issue 承担，但我们希望将其扩展为其他库（如 React）采用的 RFC 流程。

这一尝试迅速在 React Native 生命周期中找到定位。Facebook 团队现正通过社区 RFC 流程探讨 React Native 的改进方向，并围绕 Lean Core 计划 协调工作——此外还有许多引人关注的讨论。

@ReactNativeComm 🐣​

我们意识到，沟通这些工作的方式未能达到预期效果。为了让您更便捷地跟进 React Native 社区动态（从版本发布到活跃讨论），我们创建了新的 Twitter 账号 @ReactNativeComm 供您关注。

若您未使用该社交平台，请记住您始终可以通过 GitHub 关注仓库动态——过去数月该功能已支持仅接收版本发布通知，值得您考虑使用。

未来展望 🎓​

过去 7-8 个月间，核心贡献者强化了 React Native 社区 GitHub 组织，使其在 React Native 开发中承担更多主导权，并加强与 Facebook 的协作。但当前仍缺乏同类项目具备的正式组织结构。

该组织能够为更广大的开发者社区树立典范——通过强制执行一套适用于所有托管包/仓库的标准规范，为维护者们提供相互协作的枢纽平台，让大家能够共同贡献符合社区共识标准的高质量代码。

我们将在2019年初正式实施这套全新的指导方针。欢迎您通过专项讨论区分享宝贵意见。

我们相信这些变革将使社区协作更加紧密。当React Native迈入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 的范畴，移除非核心及未使用的组件。我们将非核心组件转交社区以加速其发展。精简后的范畴将使贡献管理更高效。

WebView 是我们移交社区的组件范例。我们正开发工作流，确保内部团队在组件移出仓库后仍可使用。我们还确定了数十个待移交组件。

🎁 开源内部工具与 🛠 更新工具链​

Facebook 产品团队的 React Native 开发体验与开源环境差异显著。开源社区流行的工具在 Facebook 内部未必使用，某些功能由内部工具实现。有时 Facebook 团队已习惯外部不存在的工具。这些差异将在我们开源新架构时带来挑战。

我们将开源部分内部工具，同时增强对开源社区流行工具的支持。以下是我们将推进的项目（非完整清单）：

• 开源 JSI 并支持社区引入自选 JavaScript 虚拟机，取代初始版 RN 的 JavaScriptCore。我们将在后续文章详解 JSI，您可通过 Parashuram 在 React Conf 的演讲提前了解

• 支持 Android 64 位库

• 支持新架构下的调试功能

• 增强对 CocoaPods、Gradle、Maven 及新版 Xcode 构建系统的支持

✅ 测试基础设施​

当 Facebook 工程师提交代码时，若通过全部测试即被视为可安全合并。这些测试能识别变更是否会破坏我们内部的 React Native 功能界面。然而，Facebook 内部使用 React Native 的方式存在差异，这导致我们可能在无意中破坏了开源版本的 React Native。

我们将加强内部测试机制，确保其在尽可能接近开源环境的状态下运行，从而防止破坏性代码流入开源版本。同时将构建更完善的基础设施，支持在 GitHub 核心仓库进行高效测试，使未来的 pull request 能便捷地包含测试用例。

结合精简后的核心功能范围，这些改进将使贡献者能更快速、更自信地合并 pull request。

📜 公共 API​

Facebook 将通过公共 API 使用 React Native（与开源社区采用的方式相同），以减少意外的破坏性变更。我们已着手转换内部调用点，目标是形成稳定的公共 API，最终在 1.0 版本实现语义化版本控制。

📣 沟通​

React Native 是 GitHub 上贡献者数量最多的开源项目之一，这让我们深感欣喜并希望持续保持。我们将推进增强透明度、开放讨论等举措来促进贡献者深度参与。文档作为新用户接触 React Native 的首要环节却长期未被优先关注，我们将着手改善：恢复自动生成的 API 参考文档，新增聚焦打造优质用户体验的内容，并优化发布说明。

时间线​

我们计划在未来一年左右逐步落地这些项目。部分工作（如已进入开源版本的 JSI）已在进行中，而精简核心功能范围等任务将耗时更久。我们将尽力向社区同步进展，欢迎加入 Discussions and Proposals 仓库参与讨论——这个由 React Native 社区发起的倡议，已孕育出本路线图中提及的多个项目。

长期以来，Apple 一直建议开发者使用 WKWebView 替代 UIWebView。在即将发布的 iOS 12 中，UIWebView 将被正式弃用。由于 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 发送时，我们依赖一种变通方案进行传递：先将消息数据编码到特殊协议的 URL 中，再导航 WebView 至该 URL。在原生端，我们拦截并取消此导航，解析 URL 中的数据，最终调用 React Native。这种实现方式不仅容易出错且存在安全隐患。很高兴向大家宣布，我们现已利用 WKWebView 的特性完全重构了此机制。

WKWebView 相较于 UIWebView 的其他优势包括更快的 JavaScript 执行速度和多进程架构。更多细节请参考 2014 年 WWDC。

注意事项​

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

行为不一致：

automaticallyAdjustContentInsets 和 contentInsets (提交记录)

向 WKWebView 添加 contentInsets 时，WKWebView 的视口（viewport）尺寸不会改变，仍保持与框架相同的尺寸。而 UIWebView 的实际视口尺寸会发生变化（当内容边距为正数时视口会缩小）。

backgroundColor (提交记录)

使用新的 iOS WebView 实现时，此属性可能导致背景色出现闪烁现象。此外，WKWebView 与 UIWebview 渲染透明背景的方式存在差异，具体细节请查看提交说明。

不受支持：

scalesPageToFit (提交记录)

由于 WKWebView 本身不支持 scalesPageToFit 属性，我们无法在 React Native 的 WebView 组件中实现此功能。

背景动机​

随着技术进步和移动应用在日常生活中日益重要，开发无障碍应用的需求也变得越来越迫切。

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 只能识别 "button"、"radiobutton_checked" 和 "radiobutton_unchecked" 三种 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 元素。每个特性用长整型表示，多特性通过按位或(OR)组合。

Android 的 AccessibilityComponentType 则是 React Native 自创概念，不直接对应 Android 原生属性。Android 通过无障碍委托处理：每个视图有默认委托，如需定制需创建新委托并覆盖特定方法。当开发者设置 AccessibilityComponentType 时，原生代码会根据传入组件创建新委托。

具体变更

新属性旨在成为两属性的超集。我们决定新属性主要基于现有属性 accessibilityTraits 进行建模，因为 accessibilityTraits 的值要多得多。这些特性的功能将通过修改无障碍委托在 Android 上实现。

accessibilityTraits 在 iOS 支持 17 种值，但新属性未全采纳。因部分特性效果不明确，且许多值实际极少使用。

这些特性值通常体现两种用途：描述 UI 元素角色或状态。观察发现，开发者通常组合一个角色值（如 "button"）与状态值（如 "selected" 或 "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 用于说明 UI 元素状态，接受包含以下一个或多个值的数组：

• selected

• disabled

解决方案二：添加无障碍提示​

我们新增 accessibilityHint 属性，设置后 TalkBack 或 VoiceOver 将向用户朗读提示内容。

accessibilityHint

此属性接受字符串形式的无障碍提示内容。

iOS 中设置该属性会同步原生视图的 AccessibilityHint 属性，当 iPhone 开启无障碍提示时 VoiceOver 将朗读。

Android 的实现是将提示内容追加到无障碍标签末尾。这样做模拟了 iOS 的行为，但缺点是 Android 无法像 iOS 那样在设置中单独关闭提示。

此设计源于无障碍提示通常对应特定操作（如点击），我们希望保持跨平台行为一致。

问题三解决方案​

accessibilityIgnoresInvertColors

我们将 Apple 的 AccessibilityIgnoresInvertColors API 暴露给 JavaScript。现在当您有不希望颜色反转的视图（如图片）时，设置此属性为 true 即可避免反转。

使用方式​

这些新属性将在 React Native 0.57 版本中提供。

升级指南​

若您当前正在使用 accessibilityComponentType 和 accessibilityTraits，可按以下步骤迁移到新属性。

方法一：使用 jscodeshift 工具​

简单场景可通过运行 jscodeshift 脚本完成替换。

此脚本可自动替换以下情况：

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

为

accessibilityRole= “trait”

该脚本还会移除 AccessibilityComponentType 实例（假设您每次设置 AccessibilityComponentType 时都会同时设置 AccessibilityTraits）。

方法二：手动代码替换​

对于 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 次提交 (!)，这些工作将帮助您的应用更臻完善 👏。

那么，闲话少说...

重大变更​

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。这些变更应能平稳过渡并带来更快的构建速度。更重要的是，这将帮助开发者满足下月生效的 Google Play 商店新要求。

我们要特别感谢 Dulmandakh 为此提交的多项 PR，正是这些贡献让此次升级成为可能 👏。

这方面仍需更多改进措施，您可通过专门议题（以及关于 JSC 的单独议题）参与未来 Android 支持更新的规划讨论。

全新的 Node、Xcode、React 和 Flow​

Node 8 现已成为 React Native 的标准配置。其实此前已在测试中推进，但随着 Node 6 进入维护模式，我们全面转向了 Node 8。React 也同步更新至 16.4 版本，带来了大量修复更新。

我们将停止支持 iOS 8，iOS 9 成为可支持的最低版本。所有能运行 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 时保持友善互助，并始终遵守我们推行的 CoC 行为准则——请记住，屏幕对面永远是一个真实的人。

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

在 Facebook，我们比以往任何时候都更广泛地在重要项目中使用 React Native。其中最受欢迎的产品是 Marketplace——这是我们应用中每月被 8 亿用户使用的顶级标签页之一。自 2015 年创建以来，Marketplace 完全采用 React Native 构建，包含遍布应用不同部分的数百个全屏视图。

我们也在应用的许多新模块中使用 React Native。如果您上个月观看了 F8 主题演讲，会注意到献血、危机应对、隐私快捷设置和健康检查等功能——这些都是近期采用 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 状态更新转换为 document.createElement(attrs) 和 .appendChild() 等 DOM API 的命令式可变调用，React Native 被设计为返回列出待执行变更的单一 JSON 消息，例如 [["createView", attrs], ["manageChildren", ...]]。我们设计的整个系统从不依赖同步响应，并确保列表中所有内容都能完全序列化为 JSON 并还原。这样做是为了获得灵活性：基于此架构，我们得以构建诸如Chrome 调试等工具，该工具通过 WebSocket 连接异步运行所有 JavaScript 代码。

过去五年我们发现，这些初始原则使得某些功能的构建更加困难。异步桥接意味着无法将 JavaScript 逻辑直接集成到许多需要同步响应的原生 API 中。批处理桥接会对原生调用进行排队，导致 React Native 应用更难调用原生实现的函数。而可序列化桥接则意味着不必要的内存复制，而非直接在两个环境间共享内存。对于完全采用 React Native 构建的应用，这些限制通常可以接受。但对于 React Native 与现有应用代码需复杂集成的场景，这些限制令人沮丧。

我们正在进行 React Native 的大规模架构重构，以使框架更灵活，并与 JavaScript/原生混合应用中的原生基础设施更好集成。 通过该项目，我们将应用过去五年积累的经验，逐步将架构升级至更现代化的形态。我们正在重写 React Native 的许多内部实现，但大部分变更都在底层：现有 React Native 应用将继续运行，几乎不需要修改。

为了让 React Native 更轻量级并更好地融入现有原生应用，这次架构重构包含三大内部改进。首先，我们正在改变线程模型。用户界面更新不再需要在三个不同线程上执行工作，新架构允许在任何线程上同步调用 JavaScript 来处理高优先级更新，同时仍将低优先级任务移出主线程以保持响应能力。其次，我们将异步渲染能力整合到 React Native 中，以支持多级渲染优先级并简化异步数据处理。最后，我们正在简化桥接机制，使其更快速轻量：原生代码与 JavaScript 之间的直接调用将更高效，并便于构建跨语言堆栈追踪等调试工具。

这些改进完成后，更深入的集成将成为可能。当前若想整合原生导航/手势处理或 UICollectionView、RecyclerView 等原生组件，必须采用复杂技巧。线程模型改造后，构建此类功能将变得直接高效。

我们将在今年晚些时候这项工作接近完成时公布更多细节。

社区生态​

除 Facebook 内部社区外，我们欣喜地看到外部 React Native 用户和贡献者生态蓬勃发展。我们期待通过优化开发者体验和降低贡献门槛，为社区提供更完善的支持。

正如架构改进能提升 React Native 与其他原生设施的协同能力，我们也致力于精简 JavaScript 侧架构：包括支持可替换的虚拟机与打包工具，使其更契合 JavaScript 生态系统。我们理解重大变更的更新节奏可能带来适配压力，因此将探索减少大版本更新的方案。同时针对启动优化等尚未系统文档化的专业领域，我们将补充更详实的指南。这些改进将在未来一年逐步落地。

只要您在使用 React Native，就是社区的重要成员——请继续告诉我们如何为您打造更出色的开发体验。

虽然 React Native 只是移动开发者工具箱中的选项之一，但我们坚信其价值——去年 500+ 贡献者提交的 2500 多次代码更新，正推动它日臻完善。