跳到主要内容

30 篇带有“工程”标签的文章

查看所有标签

React Native 0.79 - 更快的工具和更多功能

·9 分钟阅读
Alan Hughes
Alan Hughes
Expo 软件工程师
Shubham Gupta
Shubham Gupta
Dream11 软件工程师
Fabrizio Cucci
Fabrizio Cucci
Meta 软件工程师
Nicola Corti
Nicola Corti
Meta 软件工程师

今天我们很高兴发布 React Native 0.79！

此版本在多个方面进行了性能改进，并修复了一些错误。首先，由于延迟哈希，Metro 现在启动速度更快，并且稳定支持包导出。由于 JS 包压缩的更改以及更多改进，Android 中的启动时间也将得到改善。

亮点​

React Native 0.78 - React 19 及更多

·10 分钟阅读
Vojtech Novak
Vojtech Novak
Expo 软件工程师
Shubham Gupta
Shubham Gupta
Dream11 软件工程师
Fabrizio Cucci
Fabrizio Cucci
Meta 软件工程师
Riccardo Cipolleschi
Riccardo Cipolleschi
Meta 软件工程师

今天我们很高兴发布 React Native 0.78！

此版本在 React Native 中发布了 React 19，以及其他相关功能，例如对 Android Vector drawables 的原生支持以及 iOS 更好的棕地集成。

亮点​

React Native 核心贡献者峰会 2024 总结

·10 分钟阅读
Michał Pierzchała
Michał Pierzchała
Callstack 技术主管
Szymon Rybczak
Szymon Rybczak
Callstack 软件工程师
Mo Javad
Mo Javad
Theodo 移动部门主管（英国）
Steven Moyes
Steven Moyes
Microsoft 高级产品经理

每年，React Native 社区的核心贡献者都会与 React Native 团队聚在一起，共同塑造该项目的方向。

去年也不例外，只是略有不同。我们通常在 React Universe Conf（前身为 React Native EU）的前一天在弗罗茨瓦夫的 Callstack 总部会面。在 2024 年，我们吸取了过去的经验，将峰会举办了两天，以便我们有更多非结构化的时间在一起。

all-participants

这项年度传统已成为贡献者分享见解和表达担忧的宝贵机会，也为核心团队分享他们的计划并从 React Native 生态系统的主要贡献者（包括合作伙伴公司、个人库作者和朋友）那里收集反馈提供了机会。

我们将峰会分为两个轨道，涵盖以下主题

在这篇博文中，我们想让您先睹为快本次聚会的成果。

版本发布​

我们对 React Native 的发布过程进行了广泛的讨论。核心团队赞赏 Meta 外部的贡献者参与发布所带来的价值，并强调了拥有每晚构建版本的重要性，这对于树外平台（如 React Native visionOS）、库维护者 (Reanimated) 和框架 (Expo) 尤其有益。我们讨论了发布频率，有些人要求更频繁的发布以更快地发布修复程序，而另一些人则对第三方库和升级工作的影响表示担忧。

我们还集思广益，探讨如何减少意外的破坏性更改，并改进关于 React Native 和第三方依赖项之间兼容性的沟通。

本次会议表明，管理 React Native 的发布是多么复杂，以及考虑到生态系统中所有不同的部分，这个话题是多么微妙。

新架构之后是什么？​

既然新架构已经稳定发布，我们讨论了接下来应该关注什么。下一个重大事件可能是什么？主题围绕以下几点展开

  • Web 兼容性 – 在围绕 React Strict DOM 项目方向的讨论中得出结论，该项目应被视为临时 polyfill，而 Xplat 团队则在 React Native 核心中实现适当的跨平台功能。
  • 稳定核心 API – 结果表明，我们需要就这对应用开发者、库作者、树外平台意味着什么达成更多共识。例如，可能需要从共享的 C++ 代码库中提取 iOS 和 Android 的平台原生逻辑。其中一部分已在 LeanCore 2.0 的讨论中涵盖。
  • 旧架构支持 – 正如预期的那样，团队确认基于并发渲染的新 React 19 功能在旧架构中无法工作。新功能主要针对新架构。由于 React 19 发布计划中的障碍，目前尚不清楚如何在旧架构和新架构都支持的功能之间划清界限。
  • React Native 的第三方库 – 今天，我们库作者可以使用 TurboModules、ExpoModules，最近还可以使用 NitroModules 来实现桥接原生平台功能的相同目标。我们需要更好的文档来介绍如何做好这一点。
  • 棕地文档 – 在峰会召开时，将 React Native 集成到原生应用中的官方文档已经过时。从那时起，该团队跟进了 Android 和 iOS 的最新且更简单的文档。
  • Metro web 的 Tree-shaking – Metro 核心团队愿意合并 Expo 团队在该领域的工作。

Native Modules 的 Web API​

本次会议专门讨论了微软的 RFC，该 RFC 围绕着将 Web API 子集引入 React Native 的想法。它旨在通过利用熟悉的 API 来增强 React Native 的可扩展性并吸引更多 Web 开发者。开放访问大量现有开源 Web 库，这些库没有明确的 React Native 支持。

web-apis

Web API 规范的标准化不仅有益，而且对于 React Native 的发展至关重要，并且与我们的多平台愿景和 react-strict-dom 项目非常吻合。Web 通过其规范提供了一个统一的接口，而 React Native 社区模块目前缺乏这种接口。微软已经确定了大约 200 个重要的 Web API，可以首先为他们支持的平台实施：iOS、Android、Windows 和 macOS。

我们鼓励库开发者尽可能使其 API 与 Web 规范保持一致，因为这种标准化将提高跨平台的代码可移植性和开发者体验。

虽然该提案似乎对 React Native 的未来有利，但我们仍在集思广益下一步的行动。我们注意到一个担忧是 API 的治理，以及它们是否需要与平台实现放在不同的存储库中。另一个担忧是在特定平台允许 W3C 未指定的行为时，是否会偏离官方规范。我们需要弄清楚如何避免捆绑不必要的模块，例如使用 Babel 插件。更不用说这项倡议的范围相当大。

会议结论强调了两个关键点：首先，React Native 社区在尽可能采用 Web 兼容规范方面达成了高度一致。其次，我们需要为如何在不同平台上分别维护这些 Web API 实现建立清晰的技术策略。微软可以与 Callstack 一起改进原始 RFC，并为少数 API 生成概念验证实现，作为社区倡议。这种渐进式方法将帮助我们在扩大范围之前验证设计和开发者体验。

LeanCore 2.0​

2019 年，React Native 团队启动了 Lean Core 计划。目标是解决 React Native 核心的表面积，并减少过时和遗留的 API 和组件。从那时起，React Native 组件和 API 表面就应该进行另一轮清理了。

如今，许多组件没有得到积极维护，但有更好的社区替代方案。此外，还有一些组件有重复项，最终应合并以提高可维护性。

在 API 方面，许多 JS 层 API 都与原生 iOS 和 Android 实现绑定，而不是真正的平台无关。例如，对于 Pressable，我们有 android_disableSound 和 android_ripple 等 props。理想情况下，React Native 组件应具有尽可能小的 API 表面，且不与任何特定平台绑定。

随着树外平台的增长并被生态系统更多地采用，需要找到一种方法来减少 React Native 核心的组件和 API 表面，从而减轻 React Native 核心团队的负担，并使树外平台和库维护者更容易保持最新。

作为额外的奖励，这将使初级应用开发者更容易上手 React Native，因为他们需要学习的重复组件和“陷阱”更少。如果有更好的社区替代方案，可以引导开发者并鼓励他们使用可用的社区替代方案。

在会议期间，我们讨论了

  • Lean Core 的高层动机以及对相关方（开发者、库维护者、Meta）的好处
  • 在一些真实世界的生产 React Native 应用中使用的组件的聚合视图
  • 从核心中移除的候选组件的标准
  • 执行 Lean Core 2.0 的明确行动计划，包括
    • 弃用的高层流程
    • 处理 Meta 内部正在使用但有更好的社区替代方案的组件的情况，

作为下一步，一组核心贡献者将着手收集更多遥测数据和数据，评估社区替代方案，并整理一份详细说明拟议更改的 RFC。

Nitro Modules - 通过将 props 作为 jsi::Values 公开来解除 View 组件的阻塞​

最近，Marc Rousavy 引入了 Nitro Modules 作为创建 Native Modules 的替代方法。Nitro Modules 利用实验性的 C++ Swift Interop，并结合了一系列增强功能，可以在某些情况下提高性能。然而，在本次会议期间，我们讨论了 Nitro Modules 和现有 TurboModules 之间涉及的各种权衡。

虽然 Nitro Modules 提供了一些性能优势，但它们也有局限性和需要解决的考虑因素。例如，使用实验性的互操作功能可能会引入 TurboModules 中不存在的复杂性或兼容性问题。我们的讨论重点是这些权衡，以及将 Nitro Modules 的一些改进向上游合并到 React Native Core 中的潜力，这将使开发者能够从更高效的模块中受益。

树外平台 & CocoaPods​

树外平台展现了 React Native 的全部功能，我们可以在运行在我们移动设备、桌面甚至 VR/XR 设备上的不同平台之间共享一个 JS 代码库。创建这样一个平台目前并不是最容易的过程，实际上没有关于应该如何创建、开发和维护的指南。此外，React Native Core 在某种程度上与 Android 和 iOS 平台绑定。未来，我们可以争取实现所有平台都受到平等对待，并通过相同的 API 与 C++/JS 核心集成的场景。

oot-platforms

在本次会议期间，不同平台的维护者讨论了问题是什么，他们遇到了哪些困难，以及统一创建和维护新的树外平台的过程的解决方案应该是什么。

本次会议的另一个方面是讨论 CocoaPods 以及与管理原生依赖项相关的未来计划。最近，CocoaPods 团队宣布他们已进入维护模式，并且不会发布新的重大改进或功能。有多种替代方案可以使用，在本次会议期间，我们讨论了它们的优缺点，以及迁移会是什么样子。

桌面平台上的 React Native​

来自微软的 Steven 和 Saad，react-native-windows 和 react-native-macos 的维护者，主持了一次会议，听取并收集与桌面平台相关的贡献者的反馈。讨论的主题包括探索如何提高 React Native for Desktop 的采用率（例如在 Visual Studio 中拥有专门的工作流程，或将桌面作为 Nx 的一部分公开），以及如何支持 Expo，这对于更多采用来说是一个持续的痛点。

macOS 和 Windows 之间社区模块的可用性存在很大差异，这主要是由于 iOS 代码与 macOS 大部分兼容，而 RNW 需要定制实现。在为 React Native for Windows 开发新架构时，该团队看到了 C++ 模块的潜力，它可以实现跨平台更广泛的代码共享，这将有望减轻针对桌面平台的负担。值得注意的是，在社区方面，Software Mansion 正在努力为其最受欢迎的模块（如 React Native Screens、Gesture Handler 和 Reanimated）添加桌面支持。

我们仍然对几天时间聚在一起进行几个小时的交流所带来的知识共享和思想交流印象深刻。在本次峰会期间，我们为有助于改进和重塑 React Native 生态系统的倡议播下了种子。

如果您有兴趣加入 React Native 的开发，请务必加入我们的开放倡议并阅读我们网站上的贡献指南。我们希望将来也能与您亲自见面！

React Native 0.77 - 新的样式功能、Android 16KB 页面支持、Swift 模板

·15 分钟阅读
Vojtech Novak
Vojtech Novak
Expo 软件工程师
Mazen Chami
Mazen Chami
InfiniteRed 软件工程师
Blake Friedman
Blake Friedman
Meta 软件工程师
Rob Hogan
Rob Hogan
Meta 软件工程师

今天我们很高兴发布 React Native 0.77！

此版本发布了多项功能：新的样式功能，例如支持 display: contents、boxSizing、mixBlendMode 和 outline 相关属性，以提供更强大的布局选项；Android 16KB 页面支持，以兼容较新的 Android 设备。我们还在通过将其迁移到 Swift 来实现社区模板的现代化，同时继续支持和维护与喜欢 Objective-C 的开发者的兼容性。

React Native 0.75 - 布局中支持百分比值、新架构稳定化、模板和 init 更新及更多

·14 分钟阅读
Gabriel Donadel Dall'Agnol
Gabriel Donadel Dall'Agnol
Expo 软件工程师
Siddharth Kulkarni
Siddharth Kulkarni
Coinbase 软件工程师
Thibault Malbranche
Thibault Malbranche
Brigad 首席移动工程师
Blake Friedman
Blake Friedman
Meta 软件工程师
Riccardo Cipolleschi
Riccardo Cipolleschi
Meta 软件工程师
Nicola Corti
Nicola Corti
Meta 软件工程师

今天我们很高兴发布 React Native 0.75！

此版本发布了多项功能，例如支持 % 值的 Yoga 3.1、新架构的多个稳定化修复以及引入了建议用户使用 React Native 框架的建议。

亮点​

破坏性更改​

React Native 0.71-RC0 Android 服务中断事后分析

·7 分钟阅读
Nicola Corti
Nicola Corti
Meta 软件工程师
Lorenzo Sciandra
Lorenzo Sciandra
Microsoft 高级软件工程师

既然 0.71 已发布，我们想分享一些关于 2022 年 11 月 4 日在为所有 React Native 版本发布第一个 0.71 发行候选版（用于 React Native 和 Expo Android 构建）时导致 Android 构建中断的事件的关键信息。

帮助解决该事件的贡献者最近参加了一次事后分析会议，详细讨论了发生的事情、我们从中吸取的教训以及我们将采取哪些行动来避免未来发生类似的服务中断。

为 iOS 15 和 Android 12 准备您的应用

·3 分钟阅读
Samuel Susla
Samuel Susla
Meta 软件工程师

大家好！

随着今年晚些时候发布新的移动操作系统版本，我们建议您提前准备好 React Native 应用，以避免在这些版本普遍可用时出现回归。

引入新的 iOS WebView

·2 分钟阅读
Ramanpreet Nara
Facebook 软件工程师

长期以来，Apple 一直不鼓励使用 UIWebView，而倾向于使用 WKWebView。在未来几个月内发布的 iOS 12 中，UIWebView 将被正式弃用。React Native 的 iOS WebView 实现严重依赖于 UIWebView 类。因此，鉴于这些发展，我们为 WebView React Native 组件构建了一个新的原生 iOS 后端，该后端使用 WKWebView。

这些更改的最后部分已在 此提交中落实，并将在 0.57 版本中提供。

要选择加入此新实现，请使用 useWebKit prop

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

改进​

UIWebView 没有合法的方式来促进 WebView 中运行的 JavaScript 与 React Native 之间的通信。当从 WebView 发送消息时，我们依赖一种 hack 方法将其传递到 React Native。简而言之，我们将消息数据编码到一个带有特殊 scheme 的 url 中，并将 WebView 导航到该 url。在原生端，我们拦截并取消了此导航，从 url 中解析数据，并最终调用到 React Native。这种实现容易出错且不安全。我很高兴地宣布，我们已经利用 WKWebView 的功能完全替换了它。

WKWebView 相对于 UIWebView 的其他优势包括更快的 JavaScript 执行速度和多进程架构。请参阅 2014 年 WWDC 了解更多详情。

注意事项​

如果您的组件使用以下 props，则在切换到 WKWebView 时可能会遇到问题。目前，我们建议您避免使用这些 props

行为不一致

automaticallyAdjustContentInsets 和 contentInsets (commit)

当您向 WKWebView 添加 contentInsets 时，它不会更改 WKWebView 的视口。视口大小与框架大小保持一致。对于 UIWebView，视口大小实际上会发生变化（如果 contentInsets 为正数，则会变小）。

backgroundColor (commit)

对于 WebView 的新 iOS 实现，如果您使用此属性，则背景颜色可能会闪烁出现。此外，WKWebView 渲染透明背景的方式与 UIWebview 不同。请查看提交说明了解更多详情。

不支持

scalesPageToFit (commit)

WKWebView 不支持 scalesPageToFit prop，因此我们无法在 WebView React Native 组件上实现此功能。

辅助功能 API 更新

·7 分钟阅读
Ziqi Chen
Ziqi Chen
加州大学伯克利分校学生

动机​

随着技术的进步和移动应用在日常生活中变得越来越重要，创建易于访问的应用的必要性也日益增加。

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 允许传入 traits 数组或单个 trait，而 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 属性传递到 native 的 17 个 traits 中的每一个都映射到 Objective-C 中的 UIAccessibilityTraits 元素。Traits 各自用一个长整型表示，并且每个设置的 trait 都进行 OR 运算。

然而，在 Android 上，AccessibilityComponentType 是 React Native 创造的一个概念，并不直接映射到 Android 中的任何属性。辅助功能由辅助功能委托处理。每个视图都有一个默认的辅助功能委托。如果你想自定义任何辅助功能操作，你必须创建一个新的辅助功能委托，重写你想自定义的特定方法，然后将你要处理的视图的辅助功能委托设置为与新的委托关联。当开发者设置 AccessibilityComponentType 时，native 代码会基于传入的组件创建一个新的委托，并将视图设置为拥有该辅助功能委托。

已做的更改

对于我们的新属性，我们希望创建一个这两个属性的超集。我们决定将新属性主要模仿现有属性 accessibilityTraits 建模，因为 accessibilityTraits 具有明显更多的值。Android 上这些 traits 的功能将通过修改辅助功能委托进行 polyfill 填充。

iOS 上的 accessibilityTraits 可以设置为 17 个 UIAccessibilityTraits 值。但是，我们没有将所有这些值都包含为我们新属性的可能值。这是因为设置其中一些 traits 的效果实际上不是很清楚，并且其中许多值实际上从未使用过。

UIAccessibilityTraits 值通常具有两个目的之一。它们要么描述 UI 元素具有的角色，要么描述 UI 元素所处的状态。我们观察到之前属性的大多数用法通常使用一个代表角色的值，并将其与 “state selected”、“state 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 用于告知 Talkback 或 Voiceover UI 元素所处的状态。此属性接受一个数组，其中包含以下一个或两个值：

  • selected
  • disabled

解决方案二：添加辅助功能提示​

为此，我们添加了一个新属性 accessibilityHint。设置此属性将允许 Talkback 或 Voiceover 向用户朗读提示。

accessibilityHint

此属性以字符串形式接收要读取的辅助功能提示。

在 iOS 上，设置此属性将在视图上设置相应的 native 属性 AccessibilityHint。如果 iPhone 中启用了辅助功能提示，Voiceover 将会读取该提示。

在 Android 上，设置此属性会将提示的值附加到辅助功能标签的末尾。此实现的优点是它模仿了 iOS 上提示的行为，但此实现的缺点是这些提示无法像在 iOS 上那样在 Android 的设置中关闭。

我们在 Android 上做出此决定的原因是，通常，辅助功能提示与特定操作（例如，点击）相对应，并且我们希望保持跨平台行为的一致性。

问题三的解决方案​

accessibilityIgnoresInvertColors

我们将 Apple 的 api AccessibilityIgnoresInvertColors 暴露给 JavaScript，因此现在当您有一个不希望颜色反转的视图（例如图像）时，您可以将此属性设置为 true，它将不会被反转。

新用法​

这些新属性将在 React Native 0.57 版本中可用。

如何升级​

如果您当前正在使用 accessibilityComponentType 和 accessibilityTraits，以下是您可以升级到新属性的步骤。

1. 使用 jscodeshift​

最简单的用例可以通过运行 jscodeshift 脚本来替换。

此脚本 替换了以下实例

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

替换为

accessibilityRole= “trait”

此脚本还会删除 AccessibilityComponentType 的实例（假设您在设置 AccessibilityComponentType 的任何地方，也会设置 AccessibilityTraits）。

2. 使用手动 codemod​

对于使用了 AccessibilityTraits 但没有 AccessibilityRole 对应值的情况，以及将多个 traits 传递到 AccessibilityTraits 的情况，必须进行手动 codemod。

一般来说，

accessibilityTraits= {[“button”, “selected”]}

将手动替换为

accessibilityRole=“button”
accessibilityStates={[“selected”]}

这些属性已经在 Facebook 的代码库中使用。Facebook 的 codemod 非常简单。jscodeshift 脚本修复了我们大约一半的实例，另一半是手动修复的。总的来说，整个过程花费不到几个小时。

希望您会发现更新后的 API 很有用！并请继续使应用程序具有辅助功能！#inclusion