宣布 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 的未来意味着什么。
在过去的一年里,我们的世界发生了巨大的变化,React Native 也不例外。我们欢迎了团队的新成员(我们很高兴最终能与他们面对面见面!),我们的项目已经成熟,新的机遇也随之出现。我们很高兴在这篇文章和未来的文章中与大家分享这一切!
在 Facebook,我们的团队以半年为周期工作。每半年,我们都会回顾我们的战略,制定计划,并在内部分享。今天,我们想与您,我们的社区,分享我们下半年的计划。
2021 年下半年对 React Native 来说是激动人心的半年。我们的重点领域包括培育社区、开始向开源社区推广新架构以及推动技术向前发展。
今天我们发布了 React Native 0.65 版本,其中包含新版本的 Hermes、无障碍功能改进、软件包升级等等。
Hermes 是 Facebook 开源的 JavaScript VM,针对 React Native 进行了优化,已升级到 0.8.1 版本。此版本中的一些突出功能包括
Intl
) 现在已内置于 Android 上的 Hermes 中,并默认启用,每个 API 的大小开销仅为 57-62K(相比于 JSC 的 6MiB)。通过此更改,Hermes 用户不再需要区域设置 polyfill。非常感谢 @mganandraj 和 Microsoft 的其他合作伙伴推动了此实现的完成!Function.prototype.toString
的更改,修复了由于不正确的特性检测导致的性能下降,并 支持源代码注入用例。您可以在此处找到完整的 Hermes 变更日志。
按照此处的步骤选择在您的应用程序中启用 Hermes(如果您尚未启用),以利用这些新功能和优势!
去年,Facebook 承诺 GAAD 改进 React Native 中的无障碍功能。0.65 分享了此承诺的结果和其他无障碍功能的成功!一些值得注意的更改包括
getRecommendedTimeoutMillis
API。这公开了用户在 Android 的无障碍功能选项中设置的首选默认超时值,适用于可能需要额外时间来查看或访问控件等的用户。disabled
和 unselected
。您可以在此处关注或贡献我们的未解决的无障碍功能问题!
package.json
中使用 react-native-codegen
版本 0.0.7
作为 devDependency
。此版本包含来自 61 位贡献者的超过 1100 次提交。感谢每一位贡献和支持此版本的人!您可以在此处找到完整的变更日志。
自 Facebook 承诺 GAAD 承诺 使 React Native 具有无障碍功能以来已经一年了,该项目超出了我们的预期。我们很高兴地宣布,该项目将在 2021 年全年继续进行,并希望向大家更新我们目前的进展。在去年对 React Native 中的无障碍功能差距进行彻底分析之后,填补这些差距的工作已经开始。
我们从 90 个未解决的差距分析问题开始,从 2021 年 3 月项目在 GitHub 上启动到现在
社区已关闭 11 个问题。
React Native 团队已评估并关闭 19 个问题。
已合并 9 个拉取请求。
已将 1 个拉取请求合并到 React Native 文档中。
我们要感谢 React Native 社区在过去一年中为实现更易访问的 React Native 所做的重大进展。每一位贡献者的努力都为改进 React Native 无障碍功能做出了贡献。
自从我们向 GitHub 社区发布经过彻底审查的差距分析和问题列表以改进 React Native 的无障碍功能以来,已经过去了四周。在 React Native 社区的帮助下,我们已经在改进无障碍功能方面取得了巨大进展。社区成员一直在帮助贡献者、审查测试,并关注先前的无障碍功能问题。自 3 月 8 日以来,社区已关闭六个问题,其中四个拉取请求,另有七个拉取请求正在等待审查。
在这项工作继续进行的同时,Facebook 的 React Native 和无障碍功能团队正在评估在此倡议之前提交的无障碍功能错误和问题,以确定它们是否已包含在我们当前的差距分析中,或者是否需要将其他问题纳入项目中。已经发现了一个新问题并将其移至项目中,另有四个问题直接映射到现有问题,预计其他两个问题将通过解决解决其问题根本原因的现有问题来关闭。
感谢所有参与的社区成员。你们真正在推动 React Native 变得对每个人都更易访问!
今天我们发布了 React Native 0.64,其中包含对 iOS 上 Hermes 的支持。
Hermes 是一个开源 JavaScript 引擎,针对运行 React Native 进行了优化。它通过减少内存使用、减少下载大小并缩短应用程序变得可用或“可交互时间”(TTI)所需的时间来提高性能。
在此版本中,我们很高兴地宣布,您现在也可以使用 Hermes 在 iOS 上进行构建。要在 iOS 上启用 Hermes,请在您的 Podfile
中将 hermes_enabled
设置为 true
,然后运行 pod install
。
use_react_native!(
:path => config[:reactNativePath],
# to enable hermes on iOS, change `false` to `true` and then install pods
:hermes_enabled => true
)
请记住,iOS 上的 Hermes 支持仍处于早期阶段。我们将其保留为选择加入,因为我们正在进行进一步的基准测试。我们鼓励您在自己的应用程序上试用,并告知我们它的运行情况!
内联 require 是一种 Metro 配置选项,它通过延迟 JavaScript 模块的执行直到它们被使用时,而不是在启动时执行,从而缩短启动时间。
此功能已经存在并被推荐了几年,作为选择加入的配置选项,列在我们的文档的性能部分中。我们现在为新应用程序默认启用此选项,以帮助人们拥有快速的 React Native 应用程序,而无需额外的配置。
内联 require 是一种 Babel 转换,它接受模块导入并将其转换为内联。例如,内联 require 将此模块导入调用从文件顶部转换为其使用位置。
之前
import {MyFunction} from 'my-module';
const MyComponent = props => {
const result = MyFunction();
return <Text>{result}</Text>;
};
之后
const MyComponent = props => {
const result = require('my-module').MyFunction();
return <Text>{result}</Text>;
};
有关内联 require 的更多信息,请参见性能文档。
在过去一年中,Facebook 赞助了 Major League Hacking fellowship,支持对 React Native 的贡献。Jessie Nguyen 和 Saphal Patro 添加了使用 Chrome DevTools 上的 Performance 选项卡可视化在使用 Hermes 时应用程序执行情况的功能。
有关更多信息,请查看新的文档页面。
我们已向 Hermes 添加了代理支持,从而实现了与流行的社区项目(如 react-native-firebase 和 mobx)的兼容性。如果您一直在使用这些软件包,现在可以将您的项目迁移到 Hermes。
我们计划在即将发布的版本中使 Hermes 成为 Android 的默认 JavaScript 引擎,因此我们正在努力解决人们在使用 Hermes 时遇到的剩余问题。如果还有其他问题阻止您的应用程序采用 Hermes,请在 Hermes GitHub 存储库上打开一个问题。
React 17 不包含面向开发人员的新功能或重大突破性更改。对于 React Native 应用程序,主要更改是新的 JSX 转换,使文件不再需要导入 React 即可使用 JSX。
有关 React 17 的更多信息,请访问 React 博客。
感谢数百位贡献者,他们帮助使 0.64 成为可能!0.64 变更日志包含此版本中包含的所有更改。
在 2020 年 5 月,Facebook 是第一家承诺 GAAD 承诺 的公司,通过这样做,他们承诺将无障碍功能作为 React Native 开源项目的核心组成部分。自 5 月以来,Facebook 花费了时间认真审查和记录 React Native 中的无障碍功能差距。到目前为止,差距分析已发现 90 个问题,所有这些问题都已转换为 GitHub 问题。
总的来说,我们发现 React Native API 为无障碍功能提供了强大的支持。但是,我们也发现许多核心组件尚未完全利用平台无障碍功能 API,并且缺少对某些平台特定功能的支持。
贡献者的热情和多样性一直对 React Native 的开发起着至关重要的作用,而这些无障碍功能方面的差距是当前和新贡献者的绝佳机会。如果您一直有兴趣为 React Native 做出贡献,我们鼓励您加入我们,使 React Native 更加易于访问。
为了表彰贡献者的努力,当一个无障碍功能问题被关闭并附加到拉取请求时,贡献者将从我们的社区经理那里在 Twitter 上获得表扬。拉取请求被接受到代码库中的贡献者将在我们每月在 React Native 博客上发布的问题更新中突出显示。
请加入我们,使 React Native 对每个人都更易访问。
新的贡献者应该阅读贡献指南,并浏览 React Native GitHub 中 46 个 good first issues 的列表。
对需要更多努力的问题感兴趣的贡献者应访问 改进 React Native 无障碍功能的项目页面,以查看需要他们 React Native 知识的 GitHub 问题。
对更新 React Native 文档以反映正在弥补的无障碍功能差距的技术作家应访问 React Native 文档。
与任何可能提供帮助的人分享此倡议!
在 Twitter 或 Facebook 上关注 React Native 的 GAAD 承诺开源无障碍功能社区经理,以了解最新进展。
去年,我们进行了用户访谈并发送了 一项调查,以了解更多关于人们如何以及何时使用 React Native 文档的信息。通过从 24 次访谈和 3000 多份调查回复中收集的数据和指导,我们已经能够努力改进 React Native 的文档,并且我们很高兴今天分享这一进展
Pressable
和 React Native 组件介绍 文档非常感谢所有参与访谈、调查和文档工作的人!您的协作使这一切成为可能。
Facebook 的 React Native 团队遵循一些原则,这些原则有助于确定我们如何优先处理 React Native 的工作。这些原则专门代表我们的团队,不一定代表 React Native 社区中的每个利益相关者。我们在此处分享这些原则,以提高我们驱动力、我们如何做出决策以及我们如何集中精力的透明度。
我们对 React Native 的首要任务是符合人们对每个平台的期望。这就是 React Native 渲染到平台原语的原因。我们重视原生外观和感觉,而不是跨平台一致性。
例如,React Native 中的 TextInput 在 iOS 上渲染为 UITextField。这确保了与密码管理器和键盘控件的集成开箱即用。通过使用平台原语,React Native 应用程序还能够与 Android 和 iOS 新版本的设计和行为更改保持同步。
为了匹配原生应用程序的外观和感觉,我们也必须匹配它们的性能。这是我们集中最雄心勃勃的努力的地方。例如,Facebook 创建了 Hermes,一个新的从头开始为 Android 上的 React Native 构建的 JavaScript 引擎。Hermes 显着缩短了 React Native 应用程序的启动时间。我们还在进行重大的架构更改,以优化线程模型,并使 React Native 更容易与原生代码互操作。
Facebook 应用程序中有数以百计的屏幕使用 React Native 实现。Facebook 应用程序被数十亿人在各种各样的设备上使用。这就是为什么 我们投入精力解决大规模的、最具挑战性的问题。
在我们的应用程序中部署 React Native 使我们能够识别在较小规模下无法看到的问题。例如,Facebook 专注于提升各种设备的性能,从最新的 iPhone 到许多老一代的 Android 设备。这种关注为我们的架构项目(如 Hermes、Fabric 和 TurboModules)提供了信息。
我们已经证明 React Native 也可以扩展到大型组织。当数百名开发人员在同一个应用程序上工作时,逐步采用是必须的。这就是为什么我们确保 React Native 可以一次采用一个屏幕。很快,我们将更进一步,使现有原生屏幕的单个原生视图能够迁移到 React Native。
专注于大规模意味着我们的团队目前没有处理许多事情。例如,我们的团队不推动 React Native 在行业中的普及。我们也不积极为我们在大规模下看不到的问题构建解决方案。我们很自豪我们有许多合作伙伴和核心贡献者,他们能够专注于社区的那些重要领域。
出色的用户体验是迭代创造的。在运行中的应用程序中看到代码更改的结果应该只需要几秒钟。React Native 的架构使其能够在开发过程中提供近乎即时的反馈。
我们经常从团队那里听到,采用 React Native 显着提高了他们的开发效率。这些团队发现,开发过程中的即时反馈使得尝试不同的想法和添加额外的润色变得更加容易,因为他们不必为每一个小小的更改而中断他们的编码会话。当我们对 React Native 进行更改时,我们会确保保留开发者体验的这种质量。
即时反馈不是 React Native 提高开发者效率的唯一方式。团队可以利用快速增长的高质量开源软件包生态系统。团队还可以在 Android、iOS 和 Web 之间共享业务逻辑。这有助于他们更快地发布更新,并减少平台团队之间的组织孤岛。
当我们在 2014 年推出 React Native 时,我们用我们的座右铭“一次学习,随处编写”来介绍它——我们指的是任何地方。开发人员应该能够在不受设备型号或操作系统限制的情况下接触到尽可能多的人。
React Native 的目标平台非常多样,包括移动设备、桌面设备、Web、电视、VR、游戏机等等。我们希望在每个平台上实现丰富的体验,而不是要求开发人员为最低的共同标准构建。为了实现这一目标,我们专注于支持每个平台的独特功能。这包括从不同的输入机制(例如触摸、笔、鼠标)到根本不同的消费体验,例如 VR 中的 3D 环境。
这一原则影响了我们决定在跨平台 C++ 中实现 React Native 新核心架构的决定,以促进跨平台的对等性。我们还在改进针对其他平台维护者(如微软的 Windows 和 macOS)的公共接口。我们努力使任何平台都能支持 React Native。
我们不相信在每个平台上部署完全相同的用户界面,我们相信使用相同的声明式编程模型来公开每个平台的独特功能。我们的声明式编程模型是 React。
根据我们的经验,React 普及的单向数据流使应用程序更容易理解。我们更喜欢将屏幕表示为声明式组件的组合,而不是命令式管理视图。React 在 Web 上的成功以及新的原生 Android 和 iOS 框架的方向表明,行业也已经接受了声明式 UI。
React 普及了声明式用户界面。然而,仍然存在许多 React 具有独特优势解决的未解决问题。React Native 将继续建立在 React 的创新之上,并保持在声明式用户界面运动的最前沿。