31 篇博文 含有标签「公告」

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 时，提出了我们的口号“Learn once, write anywhere（学一次，写处处）”——我们的意思是 处处。开发者应该能够触及尽可能多的人，而不受限于设备型号或操作系统。

React Native 目标覆盖非常不同的平台，包括移动端、桌面端、网页、电视、虚拟现实、游戏主机等。我们希望在每个平台上实现丰富体验，而不要求开发者只为最低公共标准构建。为此，我们专注于支持每个平台独特的特性。这包括不同的输入机制（如触屏、笔、鼠标）到在虚拟现实中截然不同的三维体验。

这一原则促使我们决定用跨平台的 C++ 实现 React Native 的新核心架构，以促进各平台间的一致性。我们也在完善面向其他平台维护者（如微软 Windows 和 macOS）的公共接口。我们致力于让任何平台支持 React Native。

声明式 UI​

我们不认为应该在每个平台部署完全相同的用户界面，我们相信用相同的声明式编程模型展现每个平台独特的能力。我们的声明式编程模型是 React。

在我们的经验中，React 推广的单向数据流让应用更易于理解。我们倾向于将一个屏幕表达为声明式组件的组合，而不是命令式管理视图。React 在 Web 上的成功以及原生 Android 和 iOS 新框架的发展显示，行业也已接受声明式 UI。

React 推广了声明式用户界面。然而，仍有许多未解问题，而 React 处于解决这些问题的独特位置。React Native 将继续基于 React 的创新，并保持在声明式用户界面运动的前沿。

今天我们发布了 React Native 0.63，默认启用了 LogBox。

LogBox​

我们经常收到社区反馈，指出在 React Native 中错误和警告难以调试。为了解决这些问题，我们全面审视了 React Native 中的错误、警告和日志系统，并从零开始重新设计。

LogBox 是 React Native 中完全重新设计的红框（redbox）、黄框（yellowbox）以及日志体验。在 0.62 版本中，我们引入了 LogBox 作为可选功能。在本次发布中，我们将 LogBox 作为 React Native 的默认体验推出。

LogBox 针对错误和警告过于冗长、格式混乱或无法行动的问题，聚焦于三个主要目标：

• 简洁：日志应提供调试问题所需的最少信息。
• 格式化：日志应格式化以便快速找到所需信息。
• 可操作：日志应是可操作的，以便你能修复问题并继续开发。

为实现这些目标，LogBox 包含：

• 日志通知：警告通知经过重新设计，并增加了对错误的支持，所有 console.warn 和 console.log 消息都会作为通知显示，而不会遮盖你的应用。
• 代码片段：每个错误和警告都包含一个代码片段，显示日志的源代码，直接嵌入应用中，帮助快速定位问题源头。
• 组件堆栈：所有组件堆栈信息从错误消息中剥离，放入单独部分，只显示顶部三个调用帧，这为你提供一个统一、一致的堆栈帧信息区，避免日志信息混乱。
• 堆栈帧折叠：默认情况下，我们折叠与应用代码无关的调用堆栈帧，让你更快看到应用内部问题，而不是筛选 React Native 的内部代码。
• 语法错误格式化：改进了语法错误的格式化，新增带语法高亮的代码片段，便于你看到错误源代码、修复问题，继续开发，避免 React Native 阻碍工作。

我们将这些功能整合到了统一且美观的视觉设计中，错误和警告体验保持一致，且支持翻页浏览所有日志，提升使用愉悦感。

本次变更还将逐步废弃 YellowBox，替换为 LogBox API：

• LogBox.ignoreLogs()：替代了 YellowBox.ignoreLogs([])，用于静默匹配特定字符串或正则表达式的日志。
• LogBox.ignoreAllLogs()：替代了 console.disableYellowBox，用于关闭错误和警告通知。注意：此方法仅关闭通知，未捕获错误仍会弹出全屏 LogBox。

在 0.63 中，使用这些已废弃模块或方法时会有警告。请在 0.64 版本移除前尽早更新代码。

有关 LogBox 和调试 React Native 的更多信息，请参阅文档 这里。

Pressable​

React Native 的设计旨在满足应用程序对平台体验的预期，其中之一是避免“痕迹”——那些能够暴露应用是用 React Native 构建的小细节。其中一大“痕迹”来源是 Touchable 组件：Button、TouchableWithoutFeedback、TouchableHighlight、TouchableOpacity、TouchableNativeFeedback 和 TouchableBounce。这些组件通过允许你为用户交互提供视觉反馈，使应用具备交互性。然而，由于它们内置了与平台交互不匹配的样式和效果，用户能够识别出应用是用 React Native 编写的。

此外，随着 React Native 发展，且对高质量应用的要求提高，这些组件却未能同步演进。React Native 目前支持 Web、桌面和 TV 等多平台，但对于新输入方式的支持不足。React Native 需要在所有平台上支持高质量的交互体验。

为了解决这些问题，我们推出了新的核心组件 Pressable。该组件可检测多种交互类型。其 API 设计允许直接访问当前交互状态，无需父组件手动维护状态。它还设计成可以让各平台扩展其能力，支持悬停（hover）、失焦（blur）、聚焦（focus）等。我们期望大多数开发者会基于 Pressable 构建并共享组件，而不是依赖 TouchableOpacity 等的默认体验。

import {Pressable, Text} from 'react-native';

<Pressable
  onPress={() => {
    console.log('pressed');
  }}
  style={({pressed}) => ({
    backgroundColor: pressed ? 'lightskyblue' : 'white',
  })}>
  <Text style={styles.text}>Press Me!</Text>
</Pressable>;

Pressable 组件的简单示例

你可以从文档了解更多。

原生颜色（PlatformColor、DynamicColorIOS）​

每个原生平台都有系统定义的颜色概念。这些颜色会根据系统主题设置（如浅色或深色模式）、辅助功能设置（如高对比度模式）、乃至于应用上下文（比如视图或窗口的属性）自动响应变化。

虽然可以通过 Appearance API 和/或 AccessibilityInfo 来检测一些这些设置并相应调整样式，但这类抽象开发成本高，且仅仅是对原生颜色外观的近似，特别是在混合应用中，React Native 元素与原生元素并存时，这种差异尤为明显。

React Native 现提供开箱即用的系统颜色支持。PlatformColor() 是一个新 API，可像使用普通颜色一样使用系统颜色。

例如，在 iOS 上，系统提供了名为 labelColor 的颜色，在 React Native 中可用 PlatformColor 使用：

import {Text, PlatformColor} from 'react-native';

<Text style={{color: PlatformColor('labelColor')}}>
  This is a label
</Text>;

把文本颜色设置为 iOS 定义的 labelColor。

相反，Android 提供了如 colorButtonNormal 这样的颜色，你可以这样用：

import {View, Text, PlatformColor} from 'react-native';

<View
  style={{
    backgroundColor: PlatformColor('?attr/colorButtonNormal'),
  }}>
  <Text>This is colored like a button!</Text>
</View>;

把 View 组件背景色设置为 Android 定义的 colorButtonNormal。

你可以从文档了解更多 PlatformColor。也可以查阅 RNTester 中的示例代码。

DynamicColorIOS 是 iOS 独有的 API，允许你定义在浅色和深色模式下分别使用哪种颜色。与 PlatformColor 类似，DynamicColorIOS 可用于任何需要颜色的地方，它底层使用 iOS 的 colorWithDynamicProvider。

import {Text, DynamicColorIOS} from 'react-native';

const customDynamicTextColor = DynamicColorIOS({
  dark: 'lightskyblue',
  light: 'midnightblue',
});

<Text style={{color: customDynamicTextColor}}>
  This color changes automatically based on the system theme!
</Text>;

文本颜色会随系统主题自动变化。

你可以从文档了解更多关于 DynamicColorIOS。

停止支持 iOS 9 和 Node.js 8​

发布四年多后，我们停止支持 iOS 9。此变更将帮助我们更快推进开发，减少原生代码中针对各 iOS 版本的兼容性检查。鉴于其市场份额仅为 1%，对你的用户影响应该很小。

同时，我们也不再支持 Node 8。Node 8 的 LTS 支持已于 2019 年 12 月结束。当前 LTS 是 Node 10，且我们以此作为目标版本。如果你仍在用 Node 8 开发 React Native 应用，建议升级以获得最新安全补丁和更新。

其他显著改进​

• 支持在 <Text /> 中渲染 <View /> 而不需要明确设定尺寸：你现在可以在任意 <Text /> 组件内部渲染 <View />，无需显式设置其宽高。此前版本会导致红屏错误。
• iOS LaunchScreen 从 xib 改为 storyboard：自 2020 年 4 月 30 日起，所有提交至 App Store 的应用必须使用 Xcode storyboard 来提供启动画面，且所有 iPhone 应用都必须支持所有 iPhone 屏幕尺寸。本次提交调整了默认 React Native 模板以符合此要求。

致谢​

感谢数百位贡献者帮助实现了 0.63 版本！

查看全部更新，请查看 0.63 版本更新日志。

今天我们发布了 React Native 版本 0.62，默认支持 Flipper。

此次发布正值全球疫情期间。今天发布此版本是为了尊重数百位贡献者的努力，他们使得此次发布成为可能，同时避免版本跟主分支落后太多。请大家理解贡献者在处理问题方面能力受限，如有必要，准备延迟升级。

默认支持 Flipper​

Flipper 是一个用于调试移动端应用的开发者工具。它在 Android 和 iOS 社区中非常流行，在本次发布中，我们为新建和现有的 React Native 应用默认开启了对 Flipper 的支持。

Flipper 开箱即用的功能包括：

• Metro 操作：直接从工具栏重新加载应用并触发开发者菜单。
• 崩溃报告器：查看来自 Android 和 iOS 设备的崩溃报告。
• React DevTools：使用最新版 React DevTools，与其他工具并列使用。
• 网络检查器：查看设备应用发出的所有网络请求。
• Metro 和设备日志：查看、搜索和筛选 Metro 和设备的所有日志。
• 原生布局检查器：查看和编辑 React Native 渲染器输出的原生布局。
• 数据库和偏好设置检查器：查看和编辑设备数据库与偏好设置。

此外，Flipper 作为一个可扩展的平台，提供了一个市场，从 NPM 拉取插件，你可以发布或安装针对自己工作流定制的插件。可用插件请见 这里。

更多信息请查看 Flipper 文档。

新增暗黑模式功能​

我们新增了一个 Appearance 模块，用于访问用户的外观偏好设置，比如他们偏好的配色方案（浅色或暗色）。

const colorScheme = Appearance.getColorScheme();
if (colorScheme === 'dark') {
  // 使用暗色配色方案
}

我们还新增了一个钩子，用于订阅用户偏好的状态更新：

import {Text, useColorScheme} from 'react-native';

const MyComponent = () => {
  const colorScheme = useColorScheme();
  return <Text>useColorScheme(): {colorScheme}</Text>;
};

更多信息请查看文档的 Appearance 和 useColorScheme。

Apple TV 迁移至 react-native-tvos​

作为我们 Lean Core 计划 的一部分，同时为了使 Apple TV 与 React Native Windows、React Native macOS 等其他平台保持一致，我们开始从核心库中移除 Apple TV 相关代码。

今后，React Native 对 Apple TV 的支持将维护在 react-native-community/react-native-tvos 项目中，及对应的 react-native-tvos NPM 包。该仓库是 React Native 主仓库的完整分叉，仅包含支持 Apple TV 所需的变更。

react-native-tvos 的发布将基于公开发布的 React Native 版本。针对此次 0.62 版本，请升级 Apple TV 项目以使用 react-native-tvos 0.62。

更多升级支持​

0.61 版本发布时，社区推出了新的 升级辅助工具，帮助开发者升级 React Native 新版本。升级助手会显示你当前版本到目标版本的差异，便于你了解并应用所需的改动。

即便有此工具，升级时仍会遇到问题。今天我们推出了更多专门的升级支持——Upgrade-Support。Upgrade Support 是专门针对升级项目问题的 GitHub 问题跟踪区，用户可以在这里提交升级相关问题并获得社区帮助。

我们一直致力于改善升级体验，希望这些工具能在我们尚未覆盖的边缘案例中给予用户支持。

其他改进​

• LogBox：我们新增了可选的 LogBox 错误和警告体验；要启用它，请在 index.js 文件中加入 require('react-native').unstable_enableLogBox()。
• React DevTools v4：升级至 最新的 React DevTools，带来显著的性能提升、更好的导航体验及对 React Hooks 的完整支持。
• 无障碍功能改进：我们改进了无障碍功能，包括新增 accessibilityValue、为 Touchables 添加缺失的属性、onSlidingComplete 无障碍事件，并将 Switch 组件的默认角色从 "button" 改为 "switch"。

破坏性变更​

• 移除 PropTypes：为了减少 React Native 核心库对应用体积的影响，并鼓励使用编译时检查的静态类型系统，我们移除了核心组件中的 propTypes。
• 移除 accessibilityStates：我们移除了已废弃的 accessibilityStates 属性，改用新的 accessibilityState 属性，它为组件向辅助功能服务提供状态信息提供了更丰富的语义描述。
• TextInput 改动：移除了不常用、非 W3C 兼容且难以在 Fabric 中实现的 onTextInput 事件支持。同时也删除了未文档化的 inputView 属性和 selectionState。

弃用通知​

• AccessibilityInfo.fetch 已被弃用，本次发布新增了警告提示。
• 设置 useNativeDriver 现在是必需的，以支持未来切换默认值的计划。
• Animated 组件的 ref 现在指向内部组件，并且弃用了 getNode 方法。

致谢​

感谢数百位贡献者的努力，让 0.62 版本成为可能！

欲了解全部更新内容，请查看 0.62 更新日志。

在 React Native 社区 6 位贡献者提交了 20 多个拉取请求后，我们很高兴推出 react-native doctor，这是一个新命令，旨在帮助你开始使用、排查问题并自动修复开发环境中的错误。doctor 命令的设计灵感主要来源于 Expo 和 Homebrew 自带的 doctor 命令，同时 UI 上借鉴了 Jest 的风格。

我们很高兴地宣布发布 React Native 0.61，这个版本包含了一个我们称之为快速刷新（Fast Refresh）的全新重载体验。

快速刷新​

当我们询问 React Native 社区有关常见痛点时，最常见的答案之一是“热重载”功能存在问题。它在函数组件中不可靠，常常无法更新屏幕，而且对拼写错误和其他错误不够健壮。我们听到大多数人因为太不靠谱而选择关闭它。

在 React Native 0.61 中，我们将现有的“实时重载”（保存时重载）和“热重载”功能统一成一个名为“快速刷新”的全新功能。快速刷新是从零开始重新实现的，遵循以下原则：

• 快速刷新完全支持现代 React，包括函数组件和 Hooks。
• 快速刷新可以优雅地从拼写错误和其他错误中恢复，必要时会回退到完全重载。
• 快速刷新不进行侵入式代码转换，所以足够可靠，默认打开。

要观看快速刷新的演示视频，请查看：

试试看吧，告诉我们你的想法！如果你愿意，也可以在开发者菜单中关闭它（iOS 上按 Cmd+D，Android 上按 Cmd+M 或 Ctrl+M）。打开和关闭都是即时生效的，所以你随时可以切换。

以下是一些快速刷新的小技巧：

• 快速刷新默认会保留函数组件（包括 Hooks）的 React 本地状态。
• 如果你希望每次编辑都重置 React 状态，可以在该组件文件中添加特殊注释 // @refresh reset。
• 快速刷新始终会重新挂载类组件而不保留状态，以保证其可靠性。
• 我们在代码中难免会犯错！快速刷新会在你保存文件后自动重试渲染，你不需要在修正语法或运行时错误后手动重新加载应用。
• 在编辑过程中添加 console.log 或 debugger 语句是一个很不错的调试技巧。

请在 GitHub 上反馈任何关于快速刷新的问题，我们会进行调查。

其他改进​

• 修复了 use_frameworks! CocoaPods 支持。 在 0.60 版本中，我们对 CocoaPods 集成做了一些更新。不幸的是，这破坏了使用 use_frameworks! 的构建。该问题已在 0.61 中修复，方便需要用动态框架构建的 iOS 项目集成 React Native。
• 新增 useWindowDimensions Hook。 这个新的 Hook 会自动提供并订阅尺寸更新，大多数场景可替代 Dimensions API 使用。
• React 升级至 16.9。 此版本废弃了 UNSAFE_ 生命周期方法的旧名称，改进了 act 的功能等。请参阅 React 16.9 博客 获取自动迁移脚本和更多信息。

破坏性变更​

• 移除 React .xcodeproj 文件。 在 0.60 中，我们引入了通过 CocoaPods 自动链接支持，也将 CocoaPods 集成到了端到端测试中。因此，从现在起，我们采用统一标准方式将 RN 集成到 iOS 应用。这有效地废弃了 React .xcodeproj 文件的支持，该文件从 0.61 开始被移除。注意：如果你已经使用了 0.60 的自动链接功能，不会受到影响。

致谢​

感谢所有为 0.61 版本做出贡献的开发者！

要查看所有更新内容，请查阅 0.61 变更日志。

代码与社区健康状况​

在过去六个月中，超过550名贡献者向 React Native 提交了总计2800次提交。社区中有400名贡献者创建了超过 1,150个拉取请求（Pull Requests），其中有 820个拉取请求被合并。

在过去六个月中，平均每天的拉取请求数量已从3个增加到约6个，尽管我们通过 Lean Core 计划将网站、CLI 和许多模块从 React Native 中拆分出去。现在平均未处理拉取请求数量低于25个，我们通常在数小时或几天内回复并提出建议和审查意见。

有意义的社区贡献​

我们想特别强调一些我们认为非常棒的近期贡献：

• 辅助功能（Accessibility）： React Native 0.60 将带来在 Android 和 iOS 上辅助功能 API 的多项改进。所有新特性均直接使用底层平台提供的 API，因此可与 Android 和 iOS 原生的辅助技术集成。感谢 Marc Mulcahy、Alan Kenyon、Estevão Lucas、Sam Mathias Weggersen 和 Janic Duplessis 的贡献：
  • 新增辅助角色和状态 以及 新的辅助状态 API。为多种组件添加了若干缺失的辅助角色，以及一个更利于未来网页支持的新 API。
  • AccessibilityInfo.announceForAccessibility。增加对 Android 的支持，之前仅支持 iOS。
  • 扩展辅助操作支持。添加回调以处理用户定义操作相关的辅助功能。
  • 支持 iOS 辅助标志 和 “减少动画”支持。
  • Android 键盘辅助改进。新增 clickable 属性和 onClick 回调，用于通过键盘导航调用操作（注意：该属性不久将重命名为 focusable）。
  • 使用 CALayers 绘制文本。修复了 iOS 上放大文本消失的问题。
• 新应用屏幕： 社区提出了一个 新应用屏幕设计，该设计已在 0.60 实现。此屏幕是大多数用户首次使用 React Native 时看到的内容，现在它将首次用户引导至文档，同时外观与我们即将改版的网站协调一致 🌟。特别感谢 Orta、Adam Shurson、Glauber Castro、Karan Singh、Eli Perkins、Lucas Bento 和 Eric Lewis 的贡献与合作！
  • 可以通过“React Native Show”视频系列体验新应用屏幕。
• TurboModule 类型： 新的 TurboModules 系统要求为所有原生模块提供 类型定义，以保证原生操作的类型安全。在短短两周内，社区共贡献了约40个拉取请求完善 flow 类型定义的原生模块。除了前述人员，我们还要感谢 Michał Chudziak、Michał Pierzchała、Wojtek Szafraniec、Jean Regisser 以及所有提交了一个或多个拉取请求的贡献者。
• Haste： 自2015年起，React Native 采用了 “haste”模块系统，该系统允许通过全局 ID 而非相对路径导入模块，虽然方便但许多工具支持不佳。James Ide 提议删除 haste，类似于 React 多年前所做的，该计划通过一个 总任务进行了规划，且他提交了18个拉取请求推动实现！想了解详情请查看他的 Twitter 线程。
• Android Fragment： John Shelley 提出的 React Native 支持通过 Android Fragment 运行的方案已被合并，并将在 0.61 中提供支持。这里了解更多关于 Android Fragment。

Lean Core 计划​

Lean Core 的主要动机是将模块从 React Native 中拆分至独立仓库，以便获得更好的维护。在短短六个月内，WebView、NetInfo、AsyncStorage、网站及CLI 这几个仓库合计收到了超过800个拉取请求。除了更好的维护外，这些项目还能比 React Native 主体更频繁地独立发布。

我们也趁机从 React Native 中移除了过时的 polyfill 和遗留组件。过去，为支持老版本 JavaScriptCore (JSC) 中的语言特性如 Map 和 Set，必须使用 polyfill。现在 React Native 捆绑的是更新版本，因此这些 polyfill 被删除。

这项工作仍在进行中，原生与 JavaScript 两边还有许多内容需要拆分或删除，但已有迹象表明我们成功扭转了代码体积持续增长的趋势：比如查看 JavaScript bundle 大小，一年前的 0.54 版本为530KB，6个月后 0.57 版本增长到了607KB（+77KB），而现在在 master 分支上我们看到了减小了28KB至579KB，整体差异超过100KB！

随着 Lean Core 努力的第一轮结束，我们将更加审慎地对待向 React Native 添加的新 API，并将持续评估缩小和加速 React Native 的方法，同时寻找方式赋能社区接管各个组件的维护。

用户反馈​

六个月前，我们曾向社区提问 “你不喜欢 React Native 的哪些方面？”，很好地概述了人们面临的问题。我们在几个月前对该帖作了回复，现在是总结针对最重要问题取得进展的时刻：

• 升级体验： React Native 社区围绕升级体验做了多项改进：自动链接、通过 rn-diff-purge 提供的更好升级命令及即将上线的升级助手网站。我们还会通过每个大版本发布博客，让大家了解破坏性变更和新特性。所有这些改进都会让0.60之后的升级大为简化。
• 支持与不确定性： 众多用户对拉取请求缺乏活动及 Facebook 在 React Native 上投入的不确定感到挫败。正如前文所示，我们可以自信地说，我们已准备好迎接更多拉取请求，期待您的提议和贡献！
• 性能： React Native 0.59 推出了全新更快的 JavaScriptCore (JSC) 版本。另外，我们一直致力于让默认启用 inline-requires 更加容易，接下来几个月还将带来更多激动人心的更新。
• 文档： 我们近期启动了 全面重写 React Native 文档的工作。如果你想贡献文档，非常欢迎！
• Xcode 警告： 我们已经 清理掉所有现存警告，并努力避免引入新的警告。
• 热重载： React 团队正在开发 全新热重载系统，即将集成进 React Native。

遗憾的是，我们尚未能解决所有问题：

• 调试： 我们修复了许多日常遇到的不便问题，但调试体验仍未达到理想水平。我们意识到调试 React Native 体验较差，未来会优先改进。
• Metro 符号链接支持： 目前尚未找到简单直接的解决方案。不过，React Native 用户分享了各种可行的解决方案，或许能帮到你。

鉴于过去半年变化巨大，我们再次向你提问。如果您正在使用最新版本 React Native 并愿意反馈意见，请在我们新一期的 “你不喜欢 React Native 的哪些方面？” 话题下留言。

持续集成​

Facebook 首先将所有拉取请求及内部更改合并至其私有仓库，然后将所有提交同步回 GitHub。Facebook 的基础设施与常见持续集成服务不同，且非所有开源测试都在 Facebook 内部完成。这导致同步到 GitHub 的提交经常会出现测试失败，修复耗费大量时间。

React Native 团队的 Héctor Ramos 过去两个月一直在改进 Facebook 和 GitHub 上的持续集成系统。现在大部分开源测试都在提交变更至 React Native Facebook 版本前运行，这将保持 GitHub 同步提交时的持续集成稳定。

接下来​

务必关注我们关于 React Native 未来发展的演讲！未来几个月，Facebook React Native 团队成员将出席 Chain React 和 React Native EU 会议。同时，敬请期待即将发布的 0.60 版本。令人振奋 ✨

本周，Eli White 在 F8 2019 大会上做了一个关于 React Native 在 Facebook 安卓和 iOS 应用中的应用的演讲。我们很高兴分享过去两年的工作成果以及我们接下来的计划。

请在Facebook 开发者网站观看视频：

演讲亮点：​

• 我们在 2017 和 2018 年主要专注于 React Native 最大的产品——Facebook 的 Marketplace。我们与 Marketplace 团队合作，提升质量并增加产品的吸引力。至此，Marketplace 已成为 Facebook 应用中安卓和 iOS 平台上质量最高的产品之一。
• Marketplace 的性能也是一大挑战，特别是在中端安卓设备上。过去一年我们将启动时间缩短了超过 50%，未来还会有更多改进！最大的性能提升正在被内置到 React Native 中，并将在今年晚些时候带给社区。
• 我们有信心使用 React Native 构建出 Facebook 需要的高质量且高性能的应用。这份信心让我们敢于做更大胆的尝试，比如重新设计 React Native 核心。
• 微软支持并使用 React Native for Windows，让用户能够利用他们的技术专长和代码库渲染到微软的通用 Windows 平台。请关注下周的 Microsoft Build，届时可听他们分享更多。

React Radio 播客谈开源​

Eli 的演讲以介绍我们近期的开源工作收尾。我们在三月时进行了进展更新，最近，Nader Dabit 和 Gant Laborde 邀请 Christoph 参加他们的播客 React Native Radio，聊了聊 React Native 在开源方面的情况。

播客亮点：​

• 我们谈到了 Facebook 的 React Native 团队如何看待开源，以及我们如何建设一个可持续且能应对 React Native 这样庞大项目规模的社区。
• 作为 Lean Core 计划的一部分，我们正按计划移除多个模块。许多模块如 WebView 和 React Native CLI 自被拆分以来已收到超过 100 个 Pull Request。
• 接下来，我们将重点改版 React Native 网站和文档，敬请期待！

你很快就能在喜欢的播客应用中找到本期节目，或者你也可以直接在这里收听录音：

欢迎来到 React Native 0.59 版本！这是又一个重磅发布，包含了 88 位贡献者提交的 644 个提交。贡献的形式多种多样，因此 感谢你们 维护问题、培育社区，以及教授大家 React Native。本月带来了一些备受期待的变更，希望你会喜欢。

🎣 Hooks 来了​

React Hooks 是本次发布的重要内容，它们让你可以跨组件重用有状态的逻辑。关于 hooks 话题非常热，如果你还没听说过，可以看看下面这些精彩资源：

• 引入 Hooks 讲解了为什么我们要在 React 中引入 Hooks。
• Hooks 概览 是对内置 Hooks 的快速介绍。
• 创建你自己的 Hooks 展示了如何用自定义 Hooks 复用代码。
• 理解 React Hooks 探索了 Hooks 带来的新可能性。
• useHooks.com 展示社区维护的 Hooks 配方和演示。

务必在你的应用中尝试使用。我们希望你能像我们一样为这种复用感到振奋。

📱 更新的 JSC 带来性能提升和 Android 64 位支持​

React Native 使用 JSC（JavaScriptCore）来驱动应用。Android 上的 JSC 版本较旧，很多现代 JavaScript 特性不支持。更糟的是，它的性能远不及 iOS 上的现代 JSC。随着本次版本发布，情况有了改变。

感谢 @DanielZlotin, @dulmandakh, @gengjiawen, @kmagiera 和 @kudo 的精彩工作，JSC 赶上了近年来的进展。这带来了 64 位支持、现代 JavaScript 支持以及显著的性能提升。同时，也感谢他们让这个过程变得可维护，这样我们未来能够轻松利用 WebKit 的改进。感谢 Software Mansion 和 Expo 让这项工作成为可能。

💨 使用内联 require 加快应用启动速度​

我们想帮助大家让 React Native 应用默认性能更好，并正努力将 Facebook 的优化带给社区。应用按需加载资源，避免启动时变慢。该功能称为“内联 require”，它让 Metro 可以识别可延迟加载的组件。组件层级复杂且多样的应用将会体验到最大的改进。

我们需要社区反馈效果如何，再决定是否默认启用。当你升级到 0.59 后，会看到一个新的 metro.config.js 文件；将选项切换为 true 并给我们反馈吧！更多关于内联 require，请查看性能文档并对你的应用进行基准测试。

🚅 精简核心正在进行中​

React Native 是一个庞大且复杂的项目，代码库也很复杂。这使得代码不易接近贡献者，测试困难，且作为开发依赖显得臃肿。精简核心 是我们为解决这些问题，将代码迁移到独立库以便更好管理的努力。过去几个版本已经开始了这一步伐，让我们认真起来。

你可能会注意到，更多组件已正式弃用。这是好消息，这些功能现在都有了活跃维护的负责人。请注意警告信息并迁移到新的库中，因为这些组件未来版本会被移除。下面表格列出了组件、弃用状态及迁移去处。

未来几个月，还会有更多组件沿着这条路走向更精简的核心。我们正在寻求帮助——欢迎前往精简核心专题参与。

👩🏽‍💻 CLI 改进​

React Native 的命令行工具是开发者进入生态的入口，但长期存在问题且无官方支持。CLI 工具已迁移到新仓库，一支专注的维护团队已做出令人兴奋的改进。

日志格式更好，命令几乎瞬间执行——你会立即感受到差异：

🚀 升级到 0.59​

我们听到了大家对 React Native 升级流程的反馈，正在采取措施在未来版本中提升体验。升级到 0.59 推荐使用 rn-diff-purge 来确定你当前版本与 0.59 之间的差异，然后手动应用这些更改。升级完成后，便可使用改进后的 react-native upgrade 命令（基于 rn-diff-purge）来升级到 0.60 及后续版本。

🔨 重大变更​

0.59 对 Android 支持进行了整理，遵循 Google 最新推荐，可能导致已有应用出现问题。问题表现为运行时崩溃，并提示“你需要为该 Activity 使用 Theme.AppCompat 主题（或其派生）”。建议更新项目的 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 核心团队

2018 年，React Native 社区在开发和沟通 React Native 的方式上做出了诸多改变。我们相信几年后回头看，这次转变将被视为 React Native 的一个转折点。

许多人对 React Native 架构的重写感到兴奋，这就是广为人知的 Fabric。除了其他改进之外，这将解决 React Native 架构中的根本性限制，并结合 JSI 和 TurboModules 为 React Native 的未来成功奠定基础。

2018 年最大的转变是赋能 React Native 社区。从一开始，Facebook 就鼓励来自全球的开发者参与到 React Native 的开源项目中。从那时起，出现了一批核心贡献者，负责包括发布流程在内的各项事务。

这些成员采取了几个重要步骤，使整个社区在塑造项目未来方面更具权能，并提供了以下资源：

react-native-releases 📬​

这个仓库创建于一月，双重作用是让所有人可以更协作的方式跟进新版本发布，并向任何想要建议 cherry-pick 的人开放版本内容的讨论（例如0.57.8及其之前所有版本）。

它是推动摆脱月度发布周期、以及目前针对 0.57.x 版本采用“长期支持”策略的主力。

这些决定的另一半功劳归于今年创建的另一个仓库：

discussions-and-proposals 🗣​

这个仓库创建于七月，拓展了 React Native 更开放对话环境的理念。此前，这个需求由主仓库中标注为 For Discussion 的 issue 负责，但我们希望将这策略扩展成类似 RFC 的模式，类似其他库（如 React）采用的做法。

这一实验很快在 React Native 生命周期中找到自己的定位。Facebook 团队现正利用社区 RFC 流程来讨论 React Native 可改进之处，并协调围绕 Lean Core 项目 的努力——以及其他有趣的讨论。

@ReactNativeComm 🐣​

我们意识到，沟通这些工作的方式未能达到理想效果。为方便大家更轻松地跟进 React Native 社区的所有动态（从发布到活跃讨论），我们创建了一个可以依赖的新推特账号 @ReactNativeComm。

如果你没有使用该社交网络，记得你总可以通过 GitHub 观看仓库；这几个月该功能得到改进，可以仅接收版本发布的通知，建议你也试试用它。

未来展望 🎓​

过去 7-8 个月来，核心贡献者增强了 React Native Community GitHub 组织 对 React Native 开发的掌控力，并加强了与 Facebook 的协作。但这始终缺乏类似项目所具备的正式架构。

该组织可以通过对所托管的所有包和仓库施行一套标准，为更广泛的开发者社区树立榜样，提供维护者相互协助、贡献符合社区共识标准代码的统一平台。

2019 年初，我们将出台这套新指南。欢迎在 专门讨论帖 中告诉我们你的看法。

我们确信，有了这些改变，社区将变得更加协作，以至于当我们达到 1.0 版本时，我们都能通过这种共同努力，继续构建（甚至更多）精彩的应用 🤗

希望你和我们一样，对这个社区的未来充满期待。我们期待你们积极参与上述仓库中的对话，或通过你们出色的代码贡献一份力量。

编程愉快！

今年，React Native 团队专注于对 React Native 进行大规模的重新架构。正如 Sophie 在她的React Native 现状文章中提到的那样，我们已经制定了一个计划，更好地支持 Facebook 之外不断壮大的 React Native 用户和贡献者群体。现在，是时候分享我们一直在努力的更多细节了。在此之前，我想先阐述我们对开源 React Native 的长期愿景。

我们对 React Native 的愿景是……

• 一个健康的 GitHub 仓库。 议题和拉取请求能在合理时间内得到处理。
  • 提高测试覆盖率。
  • 从 Facebook 代码库同步的提交不应破坏开源测试。
  • 更大规模的有意义的社区贡献。
• 稳定的 API， 使与开源依赖的接口更加简单。
  • Facebook 使用与开源相同的公共 API。
  • 遵循语义化版本控制的 React Native 发布版本。
• 充满活力的生态系统。 由社区维护的高质量 ViewManagers、本地模块以及多平台支持。
• 优秀的文档。 重点帮助用户创建高质量体验，以及保持最新的 API 参考文档。

我们已确定以下重点领域来帮助实现这一愿景。

✂️ 精简核心​

我们的目标是缩小 React Native 的代码表面，移除非核心和未使用的组件。我们将把非核心组件转移到社区，以便其更快发展。缩小的代码表面将使管理 React Native 的贡献变得更容易。

WebView 是一个我们已转交给社区的组件例子。我们正在制定工作流程，以便内部团队在从仓库移除这些组件后依然能继续使用。我们已经确定了数十个组件，准备交由社区维护。

🎁 开源内部工具与 🛠 工具链更新​

Facebook 产品团队的 React Native 开发体验与开源社区存在显著差异。开源社区流行的许多工具在 Facebook 内部并未使用，Facebook 内部可能有等效的工具。在某些情况下，Facebook 团队已经习惯了外部没有的工具。这些差异在我们开源即将推出的架构工作时可能带来挑战。

我们将努力发布一些内部工具，同时提升对开源社区流行工具的支持。以下是我们将解决项目的非详尽列表：

• 开源 JSI，并让社区能够引入自己的 JavaScript 虚拟机，替代 React Native 初始版本中的 JavaScriptCore。关于 JSI 我们将在未来文章详细介绍，目前你可以通过Parashuram 在 React Conf 的演讲了解更多。
• 支持 Android 上的 64 位库。
• 支持在新架构下的调试。
• 改进对 CocoaPods、Gradle、Maven 以及新 Xcode 构建系统的支持。

✅ 测试基础设施​

Facebook 工程师发布代码时，只有在通过所有测试后，才视为安全合并。这些测试用于识别修改是否可能破坏我们自己的 React Native 接口。然而，Facebook 使用 React Native 的方式与开源有所不同，这导致我们可能无意中破坏了开源版本的 React Native。

我们将增强内部测试，确保它们运行在尽可能接近开源的环境中，防止破坏测试的代码误传到开源版本。我们还将完善基础设施，使核心仓库在 GitHub 上拥有更好的测试能力，便于未来的拉取请求自带测试。

结合缩小代码表面，这将让贡献者更加自信快速地合并拉取请求。

📜 公开 API​

Facebook 将通过公开 API 来使用 React Native，与开源用户一致，以减少无意的破坏性改动。我们已经开始转换内部调用点。我们的目标是统一稳定的公共 API，逐步实现 1.0 版本的语义化版本控制。

📣 交流沟通​

React Native 是GitHub 上贡献者数量最多的开源项目之一。这让我们非常高兴，也想保持这一态势。我们将继续推动吸引参与者的举措，比如提升透明度和开放讨论。文档是新来 React Native 用户首要接触的内容，但过去并未被优先关注。我们想要改变这一点，从恢复自动生成的 API 参考文档开始，创造更多聚焦于打造优质用户体验的内容，并完善我们的发布说明。

时间表​

我们计划在未来一年左右陆续完成这些项目。其中一些工作已在进行中，比如JSI 已经开源。另一些工作会需要更长时间完成，比如缩小代码表面。我们会尽力及时向社区通报进展。请加入我们的讨论与提案仓库，这是 React Native 社区发起的一个项目，促成了本路线图中提及的多个计划。