跳至主内容

1 篇文章 标记为 "announcement"

查看所有标签

React Native 开源进展更新：2019年6月

· 1 分钟阅读
Christoph Nakazawa
Christoph Nakazawa
Former Engineer @ Facebook
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

代码与社区健康​

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

尽管我们通过 Lean Core 计划将官网、CLI 和多个模块从 React Native 中拆分出来，过去六个月日均 Pull Request 数量仍从三个增至约六个。目前平均未处理 Pull Request 数量已降至 25 个以下，我们通常会在数小时或数天内回复审查建议。

重要的社区贡献​

我们特别想强调以下值得关注的近期贡献：

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 —— 这将是个激动人心的里程碑 ✨

React Native 在 F8 大会的开源播客

· 1 分钟阅读
Christoph Nakazawa
Christoph Nakazawa
Former Engineer @ Facebook
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

本周，Eli White 在 F8 2019 大会上介绍了 React Native 在 Facebook Android 和 iOS 应用中的应用。我们很高兴能分享过去两年的工作成果以及未来规划。

欢迎访问 Facebook 开发者网站观看完整视频：

F8 Talk about React Native

演讲亮点：​

  • 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

· 1 分钟阅读
Ryan Turner
Ryan Turner
核心维护者 & React Native 开发者
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

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

🎣 Hooks 正式到来​

React Hooks 已在此版本中正式支持，它让你能够在组件间复用状态逻辑。关于 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 文件的源码，展示如何启用 inlineRequires

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

🚅 核心精简计划启动​

React Native 是一个庞大而复杂的项目，其仓库结构也很复杂。这使得代码库对贡献者不够友好，测试困难，并且作为开发依赖显得臃肿。Lean Core 是我们为解决这些问题所做的努力，通过将代码迁移到独立的库中以实现更好的管理。在过去的几个版本中，我们已经迈出了第一步，但现在我们要认真对待了。

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

ComponentDeprecated?New home
AsyncStorage0.59@react-native-community/react-native-async-storage
ImageStore0.59expo-file-system or react-native-fs
MaskedViewIOS0.59@react-native-community/react-native-masked-view
NetInfo0.59@react-native-community/react-native-netinfo
Slider0.59@react-native-community/react-native-slider
ViewPagerAndroid0.59@react-native-community/react-native-viewpager

在接下来的几个月中，将会有更多的组件遵循这条路径，以实现更精简的核心。我们正在寻求帮助 — 请前往 lean core umbrella 参与贡献。

👩🏽‍💻 CLI 改进​

React Native 的命令行工具是开发者进入生态系统的入口，但它们长期以来存在问题且缺乏官方支持。CLI 工具已被迁移到一个新仓库，并且一个专门的维护者小组已经做出了一些令人兴奋的改进。

日志的格式化现在更好了。命令现在几乎可以即时运行 — 您会立即注意到不同：

0.58 的 CLI 启动很慢0.59 的 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 核心团队

React Native 开源更新（2019年3月）

· 1 分钟阅读
Christoph Nakazawa
Christoph Nakazawa
Former Engineer @ Facebook
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

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，因此自身并未遇到此问题。值得庆幸的是，社区成员已经主动站出来解决这个问题：

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 社区发展状况

· 1 分钟阅读
Lorenzo Sciandra
Lorenzo Sciandra
核心维护者 & React Native 开发者
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

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时代时，通过这样的集体努力，我们必将打造出（更）卓越的应用程序 🤗

希望您和我们同样为社区的未来感到振奋。无论是参与上述仓库的讨论，还是通过您即将创造的精彩代码，我们都热切期待见证您的参与。

编程愉快！

开源路线图

· 1 分钟阅读
Héctor Ramos
Héctor Ramos
Facebook 工程师
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

今年，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 社区发起的倡议，已孕育出本路线图中提及的多个项目。

发布 0.56 版本

· 1 分钟阅读
Lorenzo Sciandra
Lorenzo Sciandra
核心维护者 & Drivetribe 的 React Native 开发者
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

期待已久的 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 行为准则——请记住，屏幕对面永远是一个真实的人。

月度发布周期：发布十二月和一月候选版

· 1 分钟阅读
Eric Vicenti
Eric Vicenti
Facebook 工程师
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

React Native 推出后不久，我们开始每两周发布一次版本，旨在帮助社区采用新功能的同时保持生产环境版本的稳定性。在 Facebook 内部，我们需要每两周为 iOS 生产应用发布稳定代码库，因此决定以相同节奏发布开源版本。如今，许多 Facebook 应用（尤其是 Android 应用）已实现每周发布。由于我们每周从 master 分支直接发布，必须确保其高度稳定，这使得双周发布周期甚至无法惠及内部贡献者。

我们频繁收到社区反馈，表示版本更新速度令人难以跟进。像 Expo 这样的工具不得不跳过某些版本以应对快速变更。显然，双周发布节奏未能很好地服务社区。

现在改为月度发布​

我们很高兴宣布新的月度发布周期，以及 2016 年 12 月版本 v0.40——该版本在过去一个月已充分稳定，现可投入使用（请确保更新 iOS 原生模块的头文件）。

尽管为避免周末或处理突发问题可能微调日期，您现在可以预期：当月版本将在月初首日提供测试版，并于月末最后一天正式发布。

使用当月版本以获得最佳支持​

一月候选版已可试用，您可在此查看更新内容。

为及时了解变更动态并向 React Native 贡献者提供有效反馈，请尽可能使用当月候选版。当月末正式版本发布时，其包含的变更已在 Facebook 生产环境应用中运行超过两周。

您可通过全新的 react-native-git-upgrade 命令轻松升级应用：

npm install -g react-native-git-upgrade
react-native-git-upgrade 0.41.0-rc.0

我们希望这种更简洁的方式能让社区更便捷地跟踪 React Native 变更，并尽可能快速地采用新版本！

（感谢 Martin Konicek 提出此方案，以及 Mike Grabowski 推动落地）

借助 Git 实现更轻松的升级

· 1 分钟阅读
Nicolas Cuillery
Nicolas Cuillery
Zenika 的 JavaScript 顾问兼培训师
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

升级到新版本的 React Native 一直很困难。你可能以前见过类似这样的情况：

这些选项都不理想：覆盖文件会导致丢失本地更改，而不覆盖则无法获取最新更新。

今天，我很荣幸地推出一款新工具来解决这个问题。这个工具叫 react-native-git-upgrade，它在幕后使用 Git 尽可能自动解决冲突。

使用方法​

要求：Git 必须在 PATH 环境变量中可用。你的项目无需由 Git 管理。

全局安装 react-native-git-upgrade：

$ npm install -g react-native-git-upgrade

或者使用 Yarn：

$ yarn global add react-native-git-upgrade

然后在项目目录中运行：

$ cd MyProject
$ react-native-git-upgrade 0.38.0

注意：请不要运行 'npm install' 来安装新版本的 react-native。该工具需要比较新旧项目模板才能正常工作。只需在应用目录中运行上述命令（保持当前旧版本状态）。

示例输出：

你也可以不带参数运行 react-native-git-upgrade 直接升级到最新版 React Native。

我们会尽力保留你在 Android 和 iOS 构建文件中的修改，因此升级后无需运行 react-native link。

我们设计的实现方案尽可能减少侵入性。它完全基于在临时目录中即时创建的本地 Git 仓库，不会干扰你的项目仓库（无论你使用 Git、SVN、Mercurial 还是其他版本控制系统）。如果发生意外错误，你的源代码会被自动恢复。

工作原理​

关键步骤是生成 Git 补丁。这个补丁包含了 React Native 模板从你当前版本到目标版本之间的所有变更。

要获取此补丁，我们需要基于 node_modules 目录中 react-native 包内嵌的模板生成应用（这些模板与 react-native init 命令使用的相同）。然后，当基于当前版本和新版本的模板分别生成原生应用后，Git 就能生成适配你项目的补丁（包含你的应用名称）：

[...]

diff --git a/ios/MyAwesomeApp/Info.plist b/ios/MyAwesomeApp/Info.plist
index e98ebb0..2fb6a11 100644
--- a/ios/MyAwesomeApp/Info.plist
+++ b/ios/MyAwesomeApp/Info.plist
@@ -45,7 +45,7 @@
        <dict>
            <key>localhost</key>
            <dict>
-               <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
+               <key>NSExceptionAllowsInsecureHTTPLoads</key>
                <true/>
            </dict>
        </dict>
[...]

接下来只需将此补丁应用到你的源文件。传统的 react-native upgrade 流程会要求你处理每个微小差异，而 Git 能通过三方合并算法自动处理大多数变更，最终仅留下熟悉的冲突标记：

    13B07F951A680F5B00A75B9A /* Release */ = {
      isa = XCBuildConfiguration;
      buildSettings = {
        ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
<<<<<<< ours
        CODE_SIGN_IDENTITY = "iPhone Developer";
        FRAMEWORK_SEARCH_PATHS = (
          "$(inherited)",
          "$(PROJECT_DIR)/HockeySDK.embeddedframework",
          "$(PROJECT_DIR)/HockeySDK-iOS/HockeySDK.embeddedframework",
        );
=======
        CURRENT_PROJECT_VERSION = 1;
>>>>>>> theirs
        HEADER_SEARCH_PATHS = (
          "$(inherited)",
          /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include,
          "$(SRCROOT)/../node_modules/react-native/React/**",
          "$(SRCROOT)/../node_modules/react-native-code-push/ios/CodePush/**",
        );

这些冲突通常很容易理解：ours 标记代表"你的团队"，而 theirs 可视为"React Native 团队"。

为何引入新的全局包？​

React Native 自带全局 CLI（即 react-native-cli 包），它将命令委托给 node_modules/react-native/local-cli 目录中的本地 CLI。

正如上文所述，升级过程必须从当前 React Native 版本启动。若将实现代码嵌入本地 CLI，旧版本用户将无法享受此功能。例如，若新升级代码仅在 0.38.0 发布，则无法从 0.29.2 升级至 0.38.0。

基于 Git 的升级极大改善了开发者体验，使其惠及所有用户至关重要。通过全局安装独立包 react-native-git-upgrade，无论项目使用哪个 React Native 版本，您今天就能使用这项新功能。

另一重要原因是 Martin Konicek 近期完成的 Yeoman 清理工作。我们不愿让 Yeoman 依赖项重新进入 react-native 包，这会影响为创建补丁而进行的旧模板评估。

立即试用并反馈意见​

最后我想说：请尽情享受这项功能，欢迎随时提出改进建议、报告问题，特别是提交 PR。每个开发环境存在差异，每个 React Native 项目也各不相同，我们需要您的反馈来确保该功能适用于所有场景。

致谢​

衷心感谢杰出企业 Zenika 和 M6 Web (存档链接)，没有它们的支持这一切都不可能实现！

全新 Button 组件、Yarn 加速安装及公开路线图

· 1 分钟阅读
Héctor Ramos
Héctor Ramos
Former Developer Advocate @ Facebook
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

许多开发者向我们反馈，React Native 的更新迭代速度太快，很难及时追踪最新进展。为更好地同步当前工作重点，我们正式发布了 React Native 开发路线图。整体规划主要围绕三大优先事项展开：

  • 核心库增强：为重点组件和 API 增加更多功能

  • 稳定性提升：改进底层架构以减少错误并提升代码质量

  • 开发者体验优化：帮助 React Native 开发者提高效率

如果您有希望加入路线图的功能建议，欢迎访问 Canny 平台提交新功能提案或参与现有讨论。

React Native 最新动态​

今日发布的 React Native 0.37 版本新增了核心按钮组件，可轻松为应用添加可点击按钮。同时引入对新型包管理工具 Yarn 的支持，将大幅加速应用依赖更新流程。

Button 组件正式推出​

我们正式推出基础款 <Button /> 组件，完美适配各平台原生视觉风格。这回应了社区最常见的反馈：React Native 是极少数未内置开箱即用按钮的移动开发框架。

Android 与 iOS 平台按钮效果

<Button
  onPress={onPressMe}
  title="Press Me"
  accessibilityLabel="Learn more about this Simple Button"
/>

资深开发者通常这样创建按钮：iOS 使用 TouchableOpacity 实现默认效果，Android 用 TouchableNativeFeedback 实现涟漪反馈，再添加样式修饰。虽然自定义按钮开发门槛不高，但我们致力于让 React Native 学习曲线更平缓。基础按钮组件加入核心库后，新手开发者首日就能实现惊艳功能，无需耗费时间调整按钮样式或学习触摸组件细节。

该组件旨在提供跨平台的原生体验，因此不会包含自定义按钮的所有高级功能。它是绝佳的入门选择，但并非要取代现有按钮方案。欲了解更多详情，请查阅全新 Button 组件文档，内含可运行示例！

使用 Yarn 加速 react-native init​

现在您可以使用 JavaScript 新型包管理工具 Yarn 大幅加速 react-native init 过程。请先安装 Yarn 并将 react-native-cli 升级至 1.2.0 版以体验加速效果：

$ npm install -g react-native-cli

新建应用时将显示"Using yarn"提示：

Yarn 使用界面

在优质网络环境下实测显示，react-native init 耗时仅需 1 分钟左右（使用 npm 3.10.8 时约需 3 分钟）。Yarn 安装虽为可选，但我们强烈推荐使用。

致谢​

衷心感谢所有为此版本作出贡献的开发者！完整更新日志已在 GitHub 发布。包含二十余项错误修复与新特性的 React Native，因您的付出而持续进化。