29 篇标记为“engineering”的文章

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

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

亮点​

• React 19
• 朝着更小更快的版本发布
• Metro 中 JavaScript 日志的选择性启用
• 增加对 Android XML 可绘制对象的支持
• iOS 上的 ReactNativeFactory

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

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

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

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

• 发布
• 新架构之后是什么？
• Native Modules 的 Web API 规范
• LeanCore 2.0
• Nitro Modules - 通过将 props 暴露为 jsi::Values 来解除 View 组件的阻塞
• 树外平台和 CocoaPods
• 桌面上的 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​

本次会议专门讨论 Microsoft 关于将 Web API 子集引入 React Native 的 RFC。它旨在通过利用熟悉的 API 来增强 React Native 的可扩展性并吸引更多 Web 开发者。开放访问大量现有的、没有显式 React Native 支持的开源 Web 库。

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

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

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

本次会议的结论强化了两个关键点：首先，React Native 社区在尽可能采用 Web 兼容规范方面达成了高度一致。其次，我们需要为如何为不同平台单独维护这些 Web API 实现建立清晰的技术策略。Microsoft 和 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 核心集成的场景。

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

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

桌面上的 React Native​

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

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

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

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

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

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

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

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

亮点​

• Yoga 3.1 和布局改进
• 新架构稳定化
• 使用框架

破坏性更改​

• TypeScript 中的 Touchables 不能再用作泛型表达式中的类型
• 支持 minSdk 23 和 minIOSVersion 13.4 的最后一个版本
• Android：JSIModule 已被删除
• Android：PopUp Menu 已从核心中删除
• iOS：最终确定推送通知弃用工作
• 社区 CLI：删除 ram-bundle 和 profile-hermes 命令

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

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

随着 0.71 版本的发布，React Native 正在通过以下更改投资于 TypeScript 体验

• 新应用模板默认为 TypeScript
• TypeScript 声明随 React Native 一起发布
• React Native 文档优先考虑 TypeScript

在这篇文章中，我们将介绍这些更改对您作为 TypeScript 或 Flow 用户意味着什么。

大家好！

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

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

这些更改的尾声已在 此提交 中完成，并将在 0.57 版本中可用。

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

<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 (提交)

当您向 WKWebView 添加 contentInsets 时，它不会更改 WKWebView 的视口。视口保持与框架相同的大小。对于 UIWebView，视口大小实际上会更改（如果内容插页为正数，则会变小）。

backgroundColor (提交)

使用 WebView 的新 iOS 实现，如果您使用此属性，您的背景颜色可能会闪烁可见。此外，WKWebView 渲染透明背景的方式与 UIWebView 不同。请查看提交说明以获取更多详细信息。

不支持

scalesPageToFit (提交)

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

动机​

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

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 能够识别的 UI 元素只有“button”、“radiobutton_checked”和“radiobutton_unchecked”。

问题二：不存在的可访问性提示：​

可访问性提示帮助使用 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。

accessibilityTraits 在 iOS 上可以设置为 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，所以我们添加了一个 role 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. 使用手动代码修改​

对于使用了 AccessibilityTraits 但没有对应的 AccessibilityRole 值的情况，以及将多个 traits 传递给 AccessibilityTraits 的情况，则必须进行手动代码修改。

一般来说，

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

将手动替换为

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

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

希望您会发现更新后的 API 很有用！并请继续使应用程序易于访问！#inclusion

自从我们上次发布关于 React Native 的状态更新以来已经有一段时间了。

在 Facebook，我们比以往任何时候都更多地使用 React Native，并将其用于许多重要项目。我们最受欢迎的产品之一是 Marketplace，它是我们应用程序中的顶级标签之一，每月有 8 亿人使用。自 2015 年创建以来，Marketplace 的所有内容都是使用 React Native 构建的，包括应用程序不同部分的一百多个全屏视图。

我们还在应用程序的许多新部分中使用 React Native。如果您观看了上个月的 F8 主题演讲，您会认出 Blood Donations、Crisis Response、Privacy Shortcuts 和 Wellness Checks – 所有这些都是最近使用 React Native 构建的功能。Facebook 主要应用程序之外的项目也在使用 React Native。新的 Oculus Go VR 头显包括 一个配套移动应用程序，该应用程序完全使用 React Native 构建，更不用说 React VR 为头显本身中的许多体验提供支持。

当然，我们也使用许多其他技术来构建我们的应用程序。Litho 和 ComponentKit 是我们在应用程序中广泛使用的两个库；两者都为构建 native 屏幕提供了类似 React 的组件 API。React Native 从未打算取代所有其他技术——我们专注于使 React Native 本身更好，但我们很高兴看到其他团队借鉴 React Native 的想法，例如将 即时重新加载 也带到非 JavaScript 代码中。

架构​

当我们在 2013 年启动 React Native 项目时，我们将其设计为在 JavaScript 和 native 之间有一个单一的“桥梁”，它是异步的、可序列化的和批处理的。正如 React DOM 将 React 状态更新转换为对 DOM API（如 document.createElement(attrs) 和 .appendChild()）的命令式、可变调用一样，React Native 被设计为返回一个 JSON 消息，其中列出了要执行的突变，例如 [["createView", attrs], ["manageChildren", ...]]。我们将整个系统设计为永不依赖于获得同步响应，并确保该列表中的所有内容都可以完全序列化为 JSON 并返回。我们这样做是为了它赋予我们的灵活性：在这个架构之上，我们能够构建诸如 Chrome 调试 之类的工具，这些工具通过 WebSocket 连接异步运行所有 JavaScript 代码。

在过去的 5 年中，我们发现这些初始原则使构建某些功能变得更加困难。异步桥梁意味着您无法将 JavaScript 逻辑与许多期望同步响应的 native API 直接集成。批处理桥梁对 native 调用进行排队，这意味着 React Native 应用程序更难调用以 native 方式实现的函数。可序列化桥梁意味着不必要的复制，而不是在两个世界之间直接共享内存。对于完全在 React Native 中构建的应用程序，这些限制通常是可以忍受的。但是对于 React Native 和现有应用程序代码之间具有复杂集成的应用程序，它们令人沮丧。

我们正在进行 React Native 的大规模重新架构，以使框架更灵活，并更好地与混合 JavaScript/native 应用程序中的 native 基础设施集成。 通过这个项目，我们将应用我们在过去 5 年中学到的知识，并逐步将我们的架构带入更现代化的架构。我们正在重写 React Native 的许多内部组件，但大多数更改都在幕后：现有的 React Native 应用程序将继续工作，几乎或完全没有变化。

为了使 React Native 更轻量级并更好地适应现有的 native 应用程序，这种重新架构有三个主要的内部变化。首先，我们正在改变线程模型。UI 的每次更新不再需要在三个不同的线程上执行工作，而是可以在任何线程上同步调用 JavaScript 以进行高优先级更新，同时仍然保持低优先级工作在主线程之外以保持响应性。其次，我们将 异步渲染 功能整合到 React Native 中，以允许多个渲染优先级并简化异步数据处理。最后，我们正在简化我们的桥梁，使其更快更轻便；native 和 JavaScript 之间的直接调用更有效率，并且将更容易构建跨语言堆栈跟踪等调试工具。

一旦这些更改完成，更紧密的集成将成为可能。今天，在没有复杂 hack 的情况下，不可能集成 native 导航和手势处理或 native 组件（如 UICollectionView 和 RecyclerView）。在我们更改线程模型之后，构建此类功能将变得很简单。

我们将在今年晚些时候发布有关这项工作的更多详细信息，因为它即将完成。

社区​

除了 Facebook 内部的社区之外，我们很高兴拥有 Facebook 之外蓬勃发展的 React Native 用户和协作者群体。我们希望更多地支持 React Native 社区，既要更好地为 React Native 用户服务，也要使项目更容易贡献。

正如我们的架构更改将帮助 React Native 更简洁地与其他 native 基础设施互操作一样，React Native 在 JavaScript 方面也应该更精简，以更好地适应 JavaScript 生态系统，其中包括使 VM 和 bundler 可互换。我们知道重大更改的步伐可能难以跟上，因此我们希望找到减少主要版本发布的方法。最后，我们知道一些团队正在寻找更全面的文档，例如启动优化等主题，而我们在这些方面的专业知识尚未书面记录下来。预计在未来一年内会看到其中一些变化。

如果您正在使用 React Native，您就是我们社区的一份子；请继续告诉我们如何才能使 React Native 对您更好。

React Native 只是移动开发者工具箱中的一个工具，但我们坚信它——并且我们每天都在使其变得更好，在过去一年中，有 500 多位贡献者提交了超过 2500 次 commits。