在 React Native 社区 6 位贡献者提交了 20 多个拉取请求后，我们很高兴推出 react-native doctor，这是一个新命令，旨在帮助你开始使用、排查问题并自动修复开发环境中的错误。doctor 命令的设计灵感主要来源于 Expo 和 Homebrew 自带的 doctor 命令，同时 UI 上借鉴了 Jest 的风格。

我们很高兴地宣布发布 React Native 0.61，这个版本包含了一个我们称之为快速刷新（Fast Refresh）的全新重载体验。

快速刷新​

当我们询问 React Native 社区有关常见痛点时，最常见的答案之一是“热重载”功能存在问题。它在函数组件中不可靠，常常无法更新屏幕，而且对拼写错误和其他错误不够健壮。我们听到大多数人因为太不靠谱而选择关闭它。

在 React Native 0.61 中，我们将现有的“实时重载”（保存时重载）和“热重载”功能统一成一个名为“快速刷新”的全新功能。快速刷新是从零开始重新实现的，遵循以下原则：

• 快速刷新完全支持现代 React，包括函数组件和 Hooks。
• 快速刷新可以优雅地从拼写错误和其他错误中恢复，必要时会回退到完全重载。
• 快速刷新不进行侵入式代码转换，所以足够可靠，默认打开。

要观看快速刷新的演示视频，请查看：

试试看吧，告诉我们你的想法！如果你愿意，也可以在开发者菜单中关闭它（iOS 上按 Cmd+D，Android 上按 Cmd+M 或 Ctrl+M）。打开和关闭都是即时生效的，所以你随时可以切换。

以下是一些快速刷新的小技巧：

• 快速刷新默认会保留函数组件（包括 Hooks）的 React 本地状态。
• 如果你希望每次编辑都重置 React 状态，可以在该组件文件中添加特殊注释 // @refresh reset。
• 快速刷新始终会重新挂载类组件而不保留状态，以保证其可靠性。
• 我们在代码中难免会犯错！快速刷新会在你保存文件后自动重试渲染，你不需要在修正语法或运行时错误后手动重新加载应用。
• 在编辑过程中添加 console.log 或 debugger 语句是一个很不错的调试技巧。

请在 GitHub 上反馈任何关于快速刷新的问题，我们会进行调查。

其他改进​

• 修复了 use_frameworks! CocoaPods 支持。 在 0.60 版本中，我们对 CocoaPods 集成做了一些更新。不幸的是，这破坏了使用 use_frameworks! 的构建。该问题已在 0.61 中修复，方便需要用动态框架构建的 iOS 项目集成 React Native。
• 新增 useWindowDimensions Hook。 这个新的 Hook 会自动提供并订阅尺寸更新，大多数场景可替代 Dimensions API 使用。
• React 升级至 16.9。 此版本废弃了 UNSAFE_ 生命周期方法的旧名称，改进了 act 的功能等。请参阅 React 16.9 博客 获取自动迁移脚本和更多信息。

破坏性变更​

• 移除 React .xcodeproj 文件。 在 0.60 中，我们引入了通过 CocoaPods 自动链接支持，也将 CocoaPods 集成到了端到端测试中。因此，从现在起，我们采用统一标准方式将 RN 集成到 iOS 应用。这有效地废弃了 React .xcodeproj 文件的支持，该文件从 0.61 开始被移除。注意：如果你已经使用了 0.60 的自动链接功能，不会受到影响。

致谢​

感谢所有为 0.61 版本做出贡献的开发者！

要查看所有更新内容，请查阅 0.61 变更日志。

上周在 Chain React 大会上，我们宣布了 Hermes，这是一款我们在 Facebook 研发的开源 JavaScript 引擎。它是一款小巧轻量、为在 Android 上运行 React Native 优化的 JavaScript 引擎。快来看看吧！

Hermes 通过降低内存占用、减少下载大小，以及缩短应用可用时间或“交互时间”（TTI），提升了 React Native 的性能。

“在分析性能数据时，我们注意到 JavaScript 引擎本身是启动性能和下载大小的重要因素。基于这些数据，我们知道必须优化 JavaScript 性能，以适应手机这种更受限的环境，相较于台式机或笔记本电脑。在探索过其他选项后，我们构建了一个我们称之为 Hermes 的新 JavaScript 引擎。它设计用来提升应用性能，重点关注我们的 React Native 应用，即使是在内存有限、存储速度较慢且计算能力受限的主流设备上。” —Hermes：一款为移动应用优化的开源 JavaScript 引擎，起步于 React Native

想要立即开始使用？务必查看文档中的新手指南，了解如何在现有 React Native 应用中启用 Hermes！

插画作者：Rachel Nabors

经过数百名贡献者数月的辛勤工作，React Native 核心团队自豪地宣布发布 0.60 版本。本次发布涵盖了 Android 和 iOS 平台的重要迁移，同时也修复了许多问题。本文将介绍本次发布的亮点。当然，请务必查阅更新日志以获取更详细的信息。最后，感谢所有贡献者帮助我们达成这一里程碑！

关注无障碍功能​

无障碍 API 进行了许多改进，比如 announceForAccessibility，以及对 roles、action support、flags 等的提升。无障碍是一门复杂的学问，但我们希望这些改进能让无障碍支持变得更容易。详情请务必查看 React Native 开源更新 2019 年 6 月。

崭新的起点​

React Native 的启动界面进行了更新！感谢众多贡献者帮助设计了新的界面。这个新的 “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! 存在兼容性问题，相关 issue 正在跟踪并提供变通方案和未来补丁。

精简核心模块移除​

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 团队引入了对原生模块链接的重大改进，称为 自动链接（autolinking）！多数场景下，您不再需要使用 react-native link。同时，整体链接流程也得到了重新设计。请务必照文档所述先执行对现有依赖的 react-native unlink。

升级助手​

@lucasbento、@pvinis、@kelset 和 @watadarkstar 开发了一个极好的工具——Upgrade Helper，简化升级过程。它帮助 React Native 用户（尤其是已有底层项目或复杂定制的用户）清晰查看版本间的变更。请查看 更新的升级文档，并尝试使用该工具规划您的升级路径！

致库维护者的一些提醒​

AndroidX 相关变更几乎肯定需要更新您的库，请尽快支持。如果您还无法升级，建议使用 jetifier 检查您的库，确保用户能在构建时对您的库进行修补。

请查看 自动链接文档 以更新配置和 README。根据您的库之前的集成方式，您可能还需做额外调整。CLI 的依赖 指南提供了关于如何定义依赖接口的信息。

感谢​

以上是我们记录到的主要亮点，当然还有许多值得期待的更新。查看全部更新请访问 更新日志。一如既往，请关注更多新闻。祝您愉快地使用 0.60 版本！

代码与社区健康状况​

在过去六个月中，超过550名贡献者向 React Native 提交了总计2800次提交。社区中有400名贡献者创建了超过 1,150个拉取请求（Pull Requests），其中有 820个拉取请求被合并。

在过去六个月中，平均每天的拉取请求数量已从3个增加到约6个，尽管我们通过 Lean Core 计划将网站、CLI 和许多模块从 React Native 中拆分出去。现在平均未处理拉取请求数量低于25个，我们通常在数小时或几天内回复并提出建议和审查意见。

有意义的社区贡献​

我们想特别强调一些我们认为非常棒的近期贡献：

• 辅助功能（Accessibility）： React Native 0.60 将带来在 Android 和 iOS 上辅助功能 API 的多项改进。所有新特性均直接使用底层平台提供的 API，因此可与 Android 和 iOS 原生的辅助技术集成。感谢 Marc Mulcahy、Alan Kenyon、Estevão Lucas、Sam Mathias Weggersen 和 Janic Duplessis 的贡献：
  • 新增辅助角色和状态 以及 新的辅助状态 API。为多种组件添加了若干缺失的辅助角色，以及一个更利于未来网页支持的新 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个拉取请求完善 flow 类型定义的原生模块。除了前述人员，我们还要感谢 Michał Chudziak、Michał Pierzchała、Wojtek Szafraniec、Jean Regisser 以及所有提交了一个或多个拉取请求的贡献者。
• Haste： 自2015年起，React Native 采用了 “haste”模块系统，该系统允许通过全局 ID 而非相对路径导入模块，虽然方便但许多工具支持不佳。James Ide 提议删除 haste，类似于 React 多年前所做的，该计划通过一个 总任务进行了规划，且他提交了18个拉取请求推动实现！想了解详情请查看他的 Twitter 线程。
• Android Fragment： John Shelley 提出的 React Native 支持通过 Android Fragment 运行的方案已被合并，并将在 0.61 中提供支持。这里了解更多关于 Android Fragment。

Lean Core 计划​

Lean Core 的主要动机是将模块从 React Native 中拆分至独立仓库，以便获得更好的维护。在短短六个月内，WebView、NetInfo、AsyncStorage、网站及CLI 这几个仓库合计收到了超过800个拉取请求。除了更好的维护外，这些项目还能比 React Native 主体更频繁地独立发布。

我们也趁机从 React Native 中移除了过时的 polyfill 和遗留组件。过去，为支持老版本 JavaScriptCore (JSC) 中的语言特性如 Map 和 Set，必须使用 polyfill。现在 React Native 捆绑的是更新版本，因此这些 polyfill 被删除。

这项工作仍在进行中，原生与 JavaScript 两边还有许多内容需要拆分或删除，但已有迹象表明我们成功扭转了代码体积持续增长的趋势：比如查看 JavaScript bundle 大小，一年前的 0.54 版本为530KB，6个月后 0.57 版本增长到了607KB（+77KB），而现在在 master 分支上我们看到了减小了28KB至579KB，整体差异超过100KB！

随着 Lean Core 努力的第一轮结束，我们将更加审慎地对待向 React Native 添加的新 API，并将持续评估缩小和加速 React Native 的方法，同时寻找方式赋能社区接管各个组件的维护。

用户反馈​

六个月前，我们曾向社区提问 “你不喜欢 React Native 的哪些方面？”，很好地概述了人们面临的问题。我们在几个月前对该帖作了回复，现在是总结针对最重要问题取得进展的时刻：

• 升级体验： React Native 社区围绕升级体验做了多项改进：自动链接、通过 rn-diff-purge 提供的更好升级命令及即将上线的升级助手网站。我们还会通过每个大版本发布博客，让大家了解破坏性变更和新特性。所有这些改进都会让0.60之后的升级大为简化。
• 支持与不确定性： 众多用户对拉取请求缺乏活动及 Facebook 在 React Native 上投入的不确定感到挫败。正如前文所示，我们可以自信地说，我们已准备好迎接更多拉取请求，期待您的提议和贡献！
• 性能： React Native 0.59 推出了全新更快的 JavaScriptCore (JSC) 版本。另外，我们一直致力于让默认启用 inline-requires 更加容易，接下来几个月还将带来更多激动人心的更新。
• 文档： 我们近期启动了 全面重写 React Native 文档的工作。如果你想贡献文档，非常欢迎！
• Xcode 警告： 我们已经 清理掉所有现存警告，并努力避免引入新的警告。
• 热重载： React 团队正在开发 全新热重载系统，即将集成进 React Native。

遗憾的是，我们尚未能解决所有问题：

• 调试： 我们修复了许多日常遇到的不便问题，但调试体验仍未达到理想水平。我们意识到调试 React Native 体验较差，未来会优先改进。
• Metro 符号链接支持： 目前尚未找到简单直接的解决方案。不过，React Native 用户分享了各种可行的解决方案，或许能帮到你。

鉴于过去半年变化巨大，我们再次向你提问。如果您正在使用最新版本 React Native 并愿意反馈意见，请在我们新一期的 “你不喜欢 React Native 的哪些方面？” 话题下留言。

持续集成​

Facebook 首先将所有拉取请求及内部更改合并至其私有仓库，然后将所有提交同步回 GitHub。Facebook 的基础设施与常见持续集成服务不同，且非所有开源测试都在 Facebook 内部完成。这导致同步到 GitHub 的提交经常会出现测试失败，修复耗费大量时间。

React Native 团队的 Héctor Ramos 过去两个月一直在改进 Facebook 和 GitHub 上的持续集成系统。现在大部分开源测试都在提交变更至 React Native Facebook 版本前运行，这将保持 GitHub 同步提交时的持续集成稳定。

接下来​

务必关注我们关于 React Native 未来发展的演讲！未来几个月，Facebook React Native 团队成员将出席 Chain React 和 React Native EU 会议。同时，敬请期待即将发布的 0.60 版本。令人振奋 ✨

本周，Eli White 在 F8 2019 大会上做了一个关于 React Native 在 Facebook 安卓和 iOS 应用中的应用的演讲。我们很高兴分享过去两年的工作成果以及我们接下来的计划。

请在Facebook 开发者网站观看视频：

演讲亮点：​

• 我们在 2017 和 2018 年主要专注于 React Native 最大的产品——Facebook 的 Marketplace。我们与 Marketplace 团队合作，提升质量并增加产品的吸引力。至此，Marketplace 已成为 Facebook 应用中安卓和 iOS 平台上质量最高的产品之一。
• Marketplace 的性能也是一大挑战，特别是在中端安卓设备上。过去一年我们将启动时间缩短了超过 50%，未来还会有更多改进！最大的性能提升正在被内置到 React Native 中，并将在今年晚些时候带给社区。
• 我们有信心使用 React Native 构建出 Facebook 需要的高质量且高性能的应用。这份信心让我们敢于做更大胆的尝试，比如重新设计 React Native 核心。
• 微软支持并使用 React Native for Windows，让用户能够利用他们的技术专长和代码库渲染到微软的通用 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 讲解了为什么我们要在 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 来确定你当前版本与 0.59 之间的差异，然后手动应用这些更改。升级完成后，便可使用改进后的 react-native upgrade 命令（基于 rn-diff-purge）来升级到 0.60 及后续版本。

🔨 重大变更​

0.59 对 Android 支持进行了整理，遵循 Google 最新推荐，可能导致已有应用出现问题。问题表现为运行时崩溃，并提示“你需要为该 Activity 使用 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，我们直接运行 React Native 的主分支，因此所有更改都会先经过测试，确保发布版本的质量。在所有合并的拉取请求中，只有6个引发了问题：4个只影响了内部开发，2个是在发布候选版本阶段被发现。

社区中较为显眼的贡献之一是 更新后的“RedBox”屏幕。这是社区如何改善开发者体验的一个良好范例。

精简核心（Lean Core）​

当前 React Native 的表面面积非常广泛，包含许多已经不维护的抽象层，这些在 Facebook 内部使用较少。我们正在努力缩减表面面积，以使 React Native 更加精简，并让社区更好地维护那些 Facebook 内部较少使用的抽象层。

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

最让我们兴奋的是，维护者们积极投入，修复了长期存在的问题，增加了测试，并支持了很多长期以来请求的功能。这些模块获得的支持超过了 React Native 以往任何时候，说明这对社区来说是一个巨大进步。示例项目包括自抽取以来收到大量拉取请求的 WebView，以及由社区成员维护的 CLI，如今已收获了急需的改进和修复，详情见 React Native CLI 新家园。

主要用户问题​

2018年12月，我们向社区征询了他们关于 React Native 不满意的地方。我们汇总了反馈，并对每个问题进行了 回复。幸运的是，我们社区面临的许多问题，Facebook 内部同样存在。下一里程碑中，我们计划解决一些主要问题。

其中投票最高的问题之一是升级到 React Native 新版本时的开发体验。遗憾的是，我们在 Facebook 内部并不经历这一问题，因为我们直接使用主分支。值得庆幸的是，社区成员已开始着手改进这一问题：

• 来自 Callstack 的 Michał Pierzchała 通过在底层使用 rn-diff-purge，提升了 react-native upgrade 功能，见 相关拉取请求。我们同时更新了官网，移除过时的升级说明。
• 计划默认推荐 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 版本以及许多性能和功能提升。目前它已经作为候选版本发布，预计两周内稳定。

后续计划​

接下来的两个月里，我们将继续管理拉取请求， 保持进度，同时开始减少未处理的 GitHub 问题数。我们将通过 Lean Core 项目持续缩减 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 📬​

这个仓库创建于一月，双重作用是让所有人可以更协作的方式跟进新版本发布，并向任何想要建议 cherry-pick 的人开放版本内容的讨论（例如0.57.8及其之前所有版本）。

它是推动摆脱月度发布周期、以及目前针对 0.57.x 版本采用“长期支持”策略的主力。

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

discussions-and-proposals 🗣​

这个仓库创建于七月，拓展了 React Native 更开放对话环境的理念。此前，这个需求由主仓库中标注为 For Discussion 的 issue 负责，但我们希望将这策略扩展成类似 RFC 的模式，类似其他库（如 React）采用的做法。

这一实验很快在 React Native 生命周期中找到自己的定位。Facebook 团队现正利用社区 RFC 流程来讨论 React Native 可改进之处，并协调围绕 Lean Core 项目 的努力——以及其他有趣的讨论。

@ReactNativeComm 🐣​

我们意识到，沟通这些工作的方式未能达到理想效果。为方便大家更轻松地跟进 React Native 社区的所有动态（从发布到活跃讨论），我们创建了一个可以依赖的新推特账号 @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 发布版本。
• 充满活力的生态系统。 由社区维护的高质量 ViewManagers、本地模块以及多平台支持。
• 优秀的文档。 重点帮助用户创建高质量体验，以及保持最新的 API 参考文档。

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

✂️ 精简核心​

我们的目标是缩小 React Native 的代码表面，移除非核心和未使用的组件。我们将把非核心组件转移到社区，以便其更快发展。缩小的代码表面将使管理 React Native 的贡献变得更容易。

WebView 是一个我们已转交给社区的组件例子。我们正在制定工作流程，以便内部团队在从仓库移除这些组件后依然能继续使用。我们已经确定了数十个组件，准备交由社区维护。

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

Facebook 产品团队的 React Native 开发体验与开源社区存在显著差异。开源社区流行的许多工具在 Facebook 内部并未使用，Facebook 内部可能有等效的工具。在某些情况下，Facebook 团队已经习惯了外部没有的工具。这些差异在我们开源即将推出的架构工作时可能带来挑战。

我们将努力发布一些内部工具，同时提升对开源社区流行工具的支持。以下是我们将解决项目的非详尽列表：

• 开源 JSI，并让社区能够引入自己的 JavaScript 虚拟机，替代 React Native 初始版本中的 JavaScriptCore。关于 JSI 我们将在未来文章详细介绍，目前你可以通过Parashuram 在 React Conf 的演讲了解更多。
• 支持 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 社区发起的一个项目，促成了本路线图中提及的多个计划。