React Native 0.70 版本发布，Hermes 终于成为默认 Engine

React Native 的新版本 0.70.0 终于发布了，本次 0.70 版本对架构进行了多项升级调整，例如：

针对 Codegen 进行了新的统一配置支持
Hermes 成为了默认的引擎
Android 平台上完整的 CMake 支持
新架构文档更新

新架构的文档

自从 0.68 发布之后，在过去的几个月里官方一直在努力为文档的 new-architecture 部分添加更多的内容，现在的文档包含了迁移指南、示例教程等相关内容，而新架构主要包含有：

JavaScript Interface(JSI)
Fabric
Turbo Modules
CodeGen

如果你还不知道新架构有什么，欢迎查阅： React Native 的全新架构更新

Hermes 作为默认引擎

React Native 0.70 是第一个默认启用 Hermes 的版本，Hermes 是 Meta 的内部 JS 引擎。

从去年 10 月开发，官方就宣布开始准备让 Hermes 成为所有 React Native 应用的默认引擎。

Hermes 是专为资源受限的设备而设计，并针对启动、应用大小和内存消耗进行了优化，Hermes 和其他 JS 引擎之间的一个关键区别是：它能够提前将 JavaScript 源代码编译为字节码。

这个预编译的字节码捆绑在二进制文件中，使解释器不必在应用启动期间执行这个昂贵的步骤。

而今天，Hermes 将作为默认引擎随 React Native 0.70 一起发布，这意味着从 v0.70 开始的所有新项目都将默认启用 Hermes。

这里请注意，开发者其实无需等待 React Native 0.70 才使用 Hermes ，完全可以自行启用该能力： reactnative.dev/docs/hermes… 。

另外，从 2020 年开始 React Native 就在硬件上针对 Android 和 iOS 运行了相关的基准测试，主要是通过 Mattermost 测量了三个不同指标：TTI、二进制大小和内存消耗。

Android

iOS

TTI 对比

集成问题

本次发布还解决了一个长期存在的问题，该问题主要是兼容性相关，在发布新的 React Native 版本时经常出现：React Native 通过 CocoaPods 和 npm 分发的预构建二进制文件依赖于 Hermes，这使得 API 或 ABI 会出现不兼容 。

为了解决这个问题，从 React Native 0.69 开始，Hermes 会与 React Native 的每个版本一起构建，这样做确保了 Hermes 与每个版本的 React Native 完全兼容。

进行中

随着 Hermes 不断发展，目前官方的目标是：改善开发人员体验，并确保没有人因为 Hermes 对 JavaScript 支持不够完整而避免使用 Hermes，更具体地说：

开发人员能够直接从 Chrome devtools UI 运行采样分析器。
添加对 BigInt 的支持，这是来自社区的长期请求，它可能会阻止一些开发人员使用 Hermes，因为它不能被 polyfill。
添加对 WeakRef 的支持。

统一的 Codegen 配置

在 0.70 中，官方引入了一种统一的方式来定义 iOS 和 Android 的 Codegen 规范，以前开发者必须将 Android 配置放在单独的 build.gradle 文件中，现在你可以直接在 package.json 中定义它：

  "codegenConfig": {
    "name": "CustomAnimationView",
    "type": "components",
    "jsSrcsDir": "./src",
    "android": {
      "javaPackageName": "com.custom.animation"
    }
  }

这一改进为库维护者将他们的代码库迁移到新架构提供了更一致的体验。

libraries 新架构

使用 0.70之后，New Architecture 上的用户无需在其 Android.mk 或 CMake 文件上进行任何额外配置即可自动链接库。

Autolinking 是 React Native 开发体验的关键能力之一，它允许开发者使用命令包含外部库 yarn add，而无需处理 CocoaPods 或 Gradle 设置。

新架构要求开发者调整 auto-linking 功能，以支持使用 Codegen 并将 native 库代码公开给应用开发人员。

虽然 auto-linking 之前在 iOS 上的 New Architecture 库运行良好，但对 Android 却不是这样，而在 0.70 中官方缩小了这一差距，开发者现在可以继续通过 yarn add 将库添加到项目中。

Android Full CMake

从 0.70 开始，用户可以直接使用 CMake 来配置他们的 Native 构建，虽然我们不希望开发者直接编写 C++ 代码，但仍然需要提供原生编译的入口。

从现在开始，开发者可以使用 CMakeLists.txt 文件而不是 Android.mk 文件来处理项目中与 Android/Native 相关的任何内容，本次更改使得新架构上的应用和库用户都会变得更方便，因为：

应用中创建的 CMake 文件要小得多（只需要 3 行代码，而 Android.mk 文件需要 50 多行代码。
Codegen 现在会同时生成 Android.mk 和 CMakeLists.txt，因此如果库使用我们为新架构库提供的默认设置，会自动完成适配。
上面提到的自动链接将适用于 CMake 和 Android.mk 文件。
尽管现在可以自由使用 Android.mk 和 CMake 文件，但未来推荐的解决方案还是 CMake 文件（由于 CMake 有更好的文档、工具和生态系统）。

0.70 的亮点

如上所述，此版本中还有一些重要的改进，包括：

Catalyst 支持实时修复，在 Podfile 中设置 mac_catalyst_enabled 为 true 可以启用（有关详细信息可见 upgrade-helper ）。
将 Metro 升级到 0.72.0，这将启用新的 React JSX 转换：reactjs.org/blog/2020/0…。
reactnativeutilsjni 由于它是从相同的 reactnativejni 源构建的，因此删除它可以节省约 220 KB 左右空间。（github.com/facebook/re…

breaking-changes

还有一些 breaking-changes 变化：

从 react-native 包中删除了 jest/preprocessor ( 0301cb285b by @motiz88 )
删除非标准Promise.prototype.done（@motiz88 的018d5cf985 ）

另请注意，Metro 的版本已提升至 0.72，其中包含 5 个重大更改：

[Breaking] Enable React 17 new JSX transform (#848 by @danilobuerger)
‌[Breaking] Add watcher.additionalExts option, enable inclusion of .cjs and .mjs files by default (c1c6d9c)
[Breaking] .json files will no longer be implicitly resolved if removed from resolver.sourceExts (a3dc30a)
[Breaking] With a default config, any .jsx files will now be resolved before .json, .ts, .tsx (1b47931)
[Breaking] Enable strict CLI validation when metro is passed an invalid subcommand or argument (19c4f7e)
[Feature] Add start alias for serve CLI command (19c4f7e)

升级

此本 0.70 还升级了一些依赖项：

将 RN CLI 升级到 v9.0.0
将 Android Gradle 插件升级到 7.2.1
将 Gradle 升级到 7.5.1
Bump RCT-Folly 到 2021-07-22
将 Metro 提升至 0.72
将 SoLoader 提升至 0.10.4

更多详细信息可以在 changelog 中查看。

最后

如果你还没升级到 Hermes 或者 0.70 版本，可以参考 React Native 的全新架构更新全面了解下有什么特性，相信从 0.70 开始 RN 的整体稳定性和迭代会更加顺畅，感觉这也是目前的主流，为了更好的体验和维护：RN 的 JS 引擎换成自研的 Hermes ，Flutter 正从通用 Skia 切换全新自研 impeller 。

就是不知道 RN 什么时候发布 1.0 🌹🐔。