我们最近分享了React Native 的多平台愿景，介绍了将 React 拓展到其他平台如何提升整个框架。过去几年中，我们通过与微软合作开发 Windows 和 macOS 版本的 React Native，以及与 Oculus 合作进行 VR 版本的 React Native，取得了显著进展。
正如我们今年早些时候的计划所述，我们正在加大对这些平台的关注并扩大团队规模，以实现我们的愿景。为了支持我们新的团队成员以及未来更多的员工，我们正在招聘两位工程经理：一位负责支持 React Native 桌面端，另一位负责支持 React Native VR 端。
React Native 在提升移动开发水平方面取得了巨大成功，无论是在 Facebook 还是在整个行业内。随着我们以新的方式与计算机互动，以及新设备的不断发明，我们希望 React Native 能够服务于每一个人。尽管 React Native 最初是为构建移动应用而创建，我们相信专注于多平台并针对每个平台的优势和限制构建会产生共生效应。当我们将这项技术扩展到桌面和虚拟现实领域时，已经看到了巨大的好处，我们很高兴与大家分享这对 React Native 未来意味着什么。
过去一年，我们的世界变化巨大，React Native 也不例外。我们欢迎了新成员加入团队（期待将来能与他们见面！），项目日益成熟，也涌现了新的机遇。很高兴在本文及后续文章中与大家分享这一切！
在 Facebook，我们的团队按半年为一个周期工作。每个半年周期，我们会检视战略、制定计划，并在内部共享。今天，我们想与社区分享2021年下半年的计划。
2021年下半年对 React Native 来说是激动人心的一段时间。我们的关注重点包括培养社区、开始向开源社区推广新架构，以及推动技术进步。
今天我们发布了 React Native 0.65 版本，带来了新版 Hermes、无障碍功能改进、依赖包升级等诸多更新。
Hermes 是 Facebook 为 React Native 优化的开源 JavaScript 虚拟机，本次升级到了 0.8.1 版本。本次发布的一些亮点功能包括：
Intl) 现已内置于 Android 版本的 Hermes 并默认启用，API 大小开销仅为 57-62K（相比之下，JSC 达到 6MiB）。因此 Hermes 用户不再需要地区语言相关的 polyfill。特别感谢 @mganandraj 及微软的合作伙伴们促成了这项实现！Function.prototype.toString 的改动，修复了因错误的特征检测导致的性能下降，并支持了源码注入的使用场景。完整的 Hermes 更新日志请见此处。
如果你尚未启用 Hermes，请按这里的步骤将你的应用切换到 Hermes，以享受以上新特性和性能提升！
去年，Facebook 承诺加入 GAAD 提升 React Native 的无障碍体验。0.65 版本汇报了该承诺带来的成果以及其他无障碍改进！主要变化包括：
getRecommendedTimeoutMillis API。该接口公开了用户在 Android 无障碍选项中设置的默认超时时间，方便需要更多时间查看或操作控件的用户。disabled 和 unselected）的正确朗读。你可以在这里关注或参与我们待解决的无障碍问题！
react-native-codegen 版本 0.0.7 现在需要作为 package.json 中的 devDependency。此次发布包含了来自 61 位贡献者 的超过 1100 条提交。感谢所有为本次版本贡献和支持的朋友！完整更新日志请见 这里。
距 Facebook 承诺加入 GAAD Pledge 以提升 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）来提升性能。
在本次发布中，我们很高兴地宣布，你现在也可以在 iOS 上使用 Hermes。要启用 iOS 上的 Hermes，请在你的 Podfile 中将 hermes_enabled 设置为 true，然后运行 pod install。
use_react_native!(
:path => config[:reactNativePath],
# 在 iOS 上启用hermes，将 false 改为 true 并安装 pods
:hermes_enabled => true
)
请注意，iOS 上的 Hermes 支持仍处于早期阶段。我们暂时保持其为可选启用状态，同时继续进行基准测试。我们鼓励你在自己的应用中尝试，并告知我们其表现如何！
Inline Requires 是 Metro 的一个配置选项，它通过延迟 JavaScript 模块执行直到实际使用时，来提升启动速度，而不是在启动时全部执行。
该功能已存在多年，并作为一个可选配置在我们的性能文档部分中推荐使用。我们现在默认为新应用启用此选项，帮助用户无需额外配置即可获得快速的 React Native 应用启动速度。
Inline Requires 是一个 Babel 转换，将模块导入转换为内联形式。举例来说，Inline Requires 会把模块导入从文件顶部转移到实际使用的位置。
之前的写法：
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>;
};
关于 Inline Requires 的更多信息请参阅 性能文档。
过去一年，Facebook 赞助了 Major League Hacking 资助项目，支持对 React Native 的贡献。Jessie Nguyen 和 Saphal Patro 贡献了使 Chrome DevTools 的 Performance 标签页能可视化在 Hermes 环境下运行应用的执行情况的功能。
详细信息请查看 新文档页面。
我们为 Hermes 添加了 Proxy 支持，使其兼容流行的社区项目，如 react-native-firebase 和 mobx。如果你之前使用了这些包，现在可以迁移到 Hermes。
我们计划在未来版本中让 Hermes 成为 Android 的默认 JavaScript 引擎，因此正在解决用户在使用 Hermes 时碰到的剩余问题。如果还有问题阻碍你的应用采用 Hermes，请在 Hermes GitHub 仓库 提交 issue 反馈。
React 17 并未包含面向开发者的新特性或重大破坏性更改。对于 React Native 应用，主要变化是支持了新的 JSX 转换，使文件无需导入 React 即可使用 JSX。
关于 React 17 的更多信息，请参阅 React 博客。
感谢数百位贡献者助力 0.64 发布！0.64 变更日志 列出了本次发布包含的全部更改内容。
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 组件介绍文档。非常感谢所有参与访谈、填写调查和文档工作的朋友们！是你们的合作让这一切成为可能。
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。
我们不认为应该在每个平台部署完全相同的用户界面，我们相信用相同的声明式编程模型展现每个平台独特的能力。我们的声明式编程模型是 React。
在我们的经验中，React 推广的单向数据流让应用更易于理解。我们倾向于将一个屏幕表达为声明式组件的组合，而不是命令式管理视图。React 在 Web 上的成功以及原生 Android 和 iOS 新框架的发展显示，行业也已接受声明式 UI。
React 推广了声明式用户界面。然而，仍有许多未解问题，而 React 处于解决这些问题的独特位置。React Native 将继续基于 React 的创新，并保持在声明式用户界面运动的前沿。