宣布 React Native 0.66 版本发布
今天我们发布了 React Native v0.66,支持 Android 12 和 iOS 15,同时修复了若干问题并进行了常规更新。
今天我们发布了 React Native v0.66,支持 Android 12 和 iOS 15,同时修复了若干问题并进行了常规更新。
React Native 在提升移动开发水平方面取得了巨大成功,无论是在 Facebook 还是在整个行业内。随着我们以新的方式与计算机互动,以及新设备的不断发明,我们希望 React Native 能够服务于每一个人。尽管 React Native 最初是为构建移动应用而创建,我们相信专注于多平台并针对每个平台的优势和限制构建会产生共生效应。当我们将这项技术扩展到桌面和虚拟现实领域时,已经看到了巨大的好处,我们很高兴与大家分享这对 React Native 未来意味着什么。
自从我们向 GitHub 社区发布详尽审核的差距分析及改进 React Native 无障碍性的议题列表,已经过去四周。在 React Native 社区的帮助下,我们在提升无障碍性方面已经取得了显著进展。社区成员一直在帮助贡献者、审核测试并关注之前的无障碍问题。自 3 月 8 日以来,社区关闭了六个问题,包括四个合并请求,还有七个其他合并请求正在审查流程中。
在这项工作持续进行的同时,Facebook 的 React Native 和无障碍团队正在评估这项倡议之前提交的无障碍缺陷和问题,确认它们是否已包含在现有的差距分析中,或者是否有额外的问题需要纳入项目。已发现一个新的问题并已纳入项目,另外四个问题直接映射到现有问题,预计还有两个问题通过解决其根本原因的现有问题将被关闭。
感谢所有参与的社区成员。你们正真正推动 React Native 更加无障碍,造福所有人!
2020 年 5 月,Facebook 成为首家签署 GAAD 承诺 的公司,承诺将无障碍作为 React Native 开源项目的核心部分来推进。从那时起,Facebook 花费时间认真审查并记录了 React Native 中的无障碍差距。到目前为止,这些差距分析发现了 90 个问题,全部都已转化为 GitHub issues。
总体来看,我们发现 React Native 的 API 在无障碍支持方面表现良好。但同时也发现,许多核心组件尚未充分利用平台的无障碍 API,对某些平台特定功能的支持仍然缺失。
贡献者的热情和多样性一直在 React Native 的发展中发挥着至关重要的作用,这些无障碍差距是当前和新贡献者极好的机会。如果你有兴趣为 React Native 贡献力量,我们鼓励你加入我们,一起让 React Native 更加无障碍。
为了认可贡献者的努力,当一个无障碍问题关闭并附带拉取请求时,贡献者将由我们的社区经理在 Twitter 上获得公开表扬。其拉取请求被接受合入代码库的贡献者,还会在我们每月的 React Native 博客问题更新中被重点介绍。
请加入我们,一起让 React Native 为每个人都更具无障碍性。
对需要更多投入的问题感兴趣的贡献者,可访问 改进 React Native 无障碍项目页面,查看需要 React Native 知识的 GitHub issues。
有意更新 React Native 文档以反映正在关闭的无障碍差距的技术写手,可以访问 React Native 文档。
将此倡议分享给任何可能提供帮助的人!
关注 React Native 的 GAAD 承诺开源无障碍社区经理,Twitter 账号是 Twitter,Facebook 页面是 Facebook,及时了解最新进展。
去年,我们进行了用户访谈并发放了一项调查问卷,以更多地了解人们在何时何地以及如何使用 React Native 文档。基于 24 次访谈和超过 3000 份调查响应的数据和指导意见,我们努力改进 React Native 的文档,今天很高兴与大家分享我们的进展:
Pressable 组件及React Native 组件介绍文档。非常感谢所有参与访谈、填写调查和文档工作的朋友们!是你们的合作让这一切成为可能。
上周在 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!
经过数百名贡献者数月的辛勤工作,React Native 核心团队自豪地宣布发布 0.60 版本。本次发布涵盖了 Android 和 iOS 平台的重要迁移,同时也修复了许多问题。本文将介绍本次发布的亮点。当然,请务必查阅更新日志以获取更详细的信息。最后,感谢所有贡献者帮助我们达成这一里程碑!
无障碍 API 进行了许多改进,比如 announceForAccessibility,以及对 roles、action support、flags 等的提升。无障碍是一门复杂的学问,但我们希望这些改进能让无障碍支持变得更容易。详情请务必查看 React Native 开源更新 2019 年 6 月。
React Native 的启动界面进行了更新!感谢众多贡献者帮助设计了新的界面。这个新的 “Hello World” 将以更友好、更吸引人的方式迎接用户进入生态系统。

AndroidX 是 Android 生态系统的一大进步,旧的支持库组件正在被弃用。在 0.60 版本,React Native 已经迁移至 AndroidX。这是一个破坏性变更,您的原生代码和依赖也需要进行迁移。
由于此变更,React Native 应用必须开始使用 AndroidX。两者无法在同一应用中并行使用,因此应用的所有代码和依赖都必须统一使用其一。
来自 matt-oakes 在 discussions-and-proposals 的说明
尽管您的原生代码需要自行迁移,[@mikehardy]、@cawfree 和 @m4tt72 开发了一个名为 jetifier 的巧妙工具,可以自动修补您的 node_modules。库维护者需要升级,但这个工具可以为您提供临时解决方案,给维护者时间发布支持 AndroidX 的版本。如果您遇到与 AndroidX 迁移相关的错误,可以试试这个工具。
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 版本!
我们于2018年第四季度公布了我们的 React Native 开源路线图,决定加大对 React Native 开源社区的投入。
在第一个里程碑中,我们重点关注识别和改进社区中最显眼的方面。我们的目标是减少未合并的拉取请求,缩减项目的表面面积,确定主要用户问题,并建立社区管理的指导方针。
在过去两个月里,我们取得了超过预期的进展。详情请继续阅读:
为了构建一个健康的社区,我们必须快速响应代码贡献。过去几年里,我们不太重视社区贡献的审查,积压了280个拉取请求(2018年12月)。在第一个里程碑里,我们将未处理的拉取请求数量减少到约65个。同时,每天新开的拉取请求平均数量从3.5个增长到了7个,这意味着我们在过去三个月处理了大约 600个拉取请求。
我们合并了 近三分之二 的拉取请求,关闭了三分之一。关闭的拉取请求没有被合并,原因是它们已经过时或者质量较低,或者不必要地增加了项目表面面积。大部分合并的拉取请求修复了错误,提升了跨平台一致性,或者引入了新功能。其中值得一提的贡献包括提升类型安全和支持 AndroidX 的持续工作。
在 Facebook,我们直接运行 React Native 的主分支,因此所有更改都会先经过测试,确保发布版本的质量。在所有合并的拉取请求中,只有6个引发了问题:4个只影响了内部开发,2个是在发布候选版本阶段被发现。
社区中较为显眼的贡献之一是 更新后的“RedBox”屏幕。这是社区如何改善开发者体验的一个良好范例。
当前 React Native 的表面面积非常广泛,包含许多已经不维护的抽象层,这些在 Facebook 内部使用较少。我们正在努力缩减表面面积,以使 React Native 更加精简,并让社区更好地维护那些 Facebook 内部较少使用的抽象层。
在第一个里程碑中, 我们向社区寻求 Lean Core 项目的帮助。社区反响热烈,我们几乎应接不暇。 看看不到一个月内完成的所有工作!
最让我们兴奋的是,维护者们积极投入,修复了长期存在的问题,增加了测试,并支持了很多长期以来请求的功能。这些模块获得的支持超过了 React Native 以往任何时候,说明这对社区来说是一个巨大进步。示例项目包括自抽取以来收到大量拉取请求的 WebView,以及由社区成员维护的 CLI,如今已收获了急需的改进和修复,详情见 React Native CLI 新家园。
2018年12月,我们向社区征询了他们关于 React Native 不满意的地方。我们汇总了反馈,并对每个问题进行了 回复。幸运的是,我们社区面临的许多问题,Facebook 内部同样存在。下一里程碑中,我们计划解决一些主要问题。
其中投票最高的问题之一是升级到 React Native 新版本时的开发体验。遗憾的是,我们在 Facebook 内部并不经历这一问题,因为我们直接使用主分支。值得庆幸的是,社区成员已开始着手改进这一问题:
没有 React Native 社区,特别是 Mike Grabowski 和 Lorenzo Sciandra 的帮助,我们无法顺利发布版本。我们希望改进发布管理流程,并计划从现在起更加积极参与:
许多计划将体现在即将发布的 React Native 0.59 版本 中。0.59 将带来 React Hooks、针对 Android 的新 64 位 JavaScriptCore 版本以及许多性能和功能提升。目前它已经作为候选版本发布,预计两周内稳定。
接下来的两个月里,我们将继续管理拉取请求, 保持进度,同时开始减少未处理的 GitHub 问题数。我们将通过 Lean Core 项目持续缩减 React Native 表面面积。计划解决社区排名前5的主要问题。在完善社区指南后,我们将关注网站和文档。
我们非常高兴能在3月于 Facebook 伦敦接待来自社区的十多位贡献者,共同推进多项工作。感谢你们使用 React Native,希望你们能感受到我们在2019年努力带来的改进。数月后我们将带来新更新,届时也会持续合并你们的拉取请求! ⚛️✌️
在 React Native 推出不久后,我们开始每两周发布一次,以帮助社区采用新功能,同时保持版本的生产环境稳定。在 Facebook,我们必须每两周稳定代码库,以发布生产环境的 iOS 应用,因此我们决定以相同的节奏发布开源版本。现在,Facebook 的许多应用特别是在 Android 平台上每周都会发布一次。因为我们每周都从 master 分支发版,所以需要保持它的高度稳定。所以双周发布频率对于内部贡献者来说也不再有益。
我们经常听到社区反馈说发布速度难以跟上。像 Expo 这样的工具不得不跳过每隔一版,以应对快速的版本变化。因此很明显,双周发布并没有很好地服务社区。
我们很高兴宣布新的每月发布节奏,以及 2016 年 12 月发布的版本 v0.40,该版本已经稳定了整整一个月,现在可以采用了。(只需要确保在 iOS 上更新你原生模块的头文件)。
虽然发布时间可能会有几天的浮动以避免周末或处理不可预见的问题,但你现在可以期待每个月的第一个工作日可用发布版本,并在月底正式发布。
1 月的候选版本已准备好试用,你可以在这里查看有哪些新内容。
为了了解即将到来的变更并给 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 促成其实现)
升级到新版 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,你无法在旧版本 React Native 中享用新功能。举例来说,如果这套新升级代码只发布于 0.38.0,那你就无法从 0.29.2 升级到 0.38.0。
基于 Git 的升级大大提升开发者体验,并且要让所有人都能用得上非常重要。通过使用独立的全局安装包 react-native-git-upgrade,无论你的项目用哪个版本 React Native,今天都可以使用这套新代码。
另外原因是 Martin Konicek 最近的 Yeoman 淘汰。我们不希望为了评估旧模板进而生成补丁,再把 Yeoman 依赖重新带回 react-native 包。
总结一句,尽情享用该功能,欢迎随时提出改进建议、报告问题,尤其是提交 Pull Request。每种环境和每个 React Native 项目都各不相同,我们需要你的反馈,让这个工具为更多人顺利工作。
特别感谢了不起的公司 Zenika 和 M6 Web(存档),没有他们这一切都不可能实现!