React Native 详解：从 Legacy Bridge 到新架构

Source: Dev.to

如果你已经从事网页开发一段时间了，很可能已经依赖 React 来构建前端。你发布了一个可靠的网页应用，用户喜欢它，然后你意识到需要一个移动应用。

你开始研究，却碰到障碍：Android 需要 Kotlin，iOS 需要 Swift。真的必须学习两种不同的语言，掌握完全不同的工具链，并维护两个独立的代码库吗？

这听起来简直是噩梦。但就在你快要放弃时，你偶然进入了 跨平台开发 的世界，发现了 React Native —— 一个让你使用已经熟悉的 JavaScript 和 React 编写移动应用的框架，使用单一代码库即可原生地面向 Android 和 iOS。

突然之间，构建移动应用不再像从零开始，而像是对已有知识的延伸。

什么是 React Native？

React Native 是一个 开源框架，允许开发者使用 JavaScript 编程语言和 React 库，为多个平台（Android、iOS、macOS、Windows）构建 原生移动应用。

• 与在 WebView 中渲染（本质上是在移动应用中嵌入浏览器）的混合框架不同，React Native 渲染 真实的、平台特定的原生组件。

示例

Hello World

上面的代码 不会 转换为 HTML。

• View 会变为：

  • Android 上的 ViewGroup
  • iOS 上的 UIView

• Text 会变为：

  • Android 上的 TextView
  • iOS 上的 UITextView

这些正是你在直接使用 Kotlin 或 Swift 编写应用时会使用的相同构建块。因此，应用的体验更接近原生，提供更流畅、更灵敏的用户体验。

React（一个 Web 库）如何渲染原生组件？

是，也不是。 核心的 React 库在 Web 和移动生态系统中保持一致，但 渲染器 不同。

核心思路

• React Core：管理状态（通过 useState、useEffect 等 Hook）并通过 调和 决定需要更新 UI 的 哪一部分。
• Renderer：知道如何将该 UI 描述转换为平台能够理解的东西（HTML DOM、Android 视图、iOS 视图）。

图示（概念）

┌─────────────┐
│ React Core  │   ← manages state, reconciliation
└─────┬───────┘
      │
┌─────▼───────┐
│ Renderer    │   ← react‑dom (web) or react‑native (mobile)
└─────┬───────┘
      │
┌─────▼───────┐
│ Platform UI │   ← DOM nodes or native views
└─────────────┘

渲染器详解

关键要点： React 本身从不直接渲染任何东西。渲染器 决定你的组件是生成 DOM 节点还是原生 UI 视图。

深入探讨：React Native 架构

桥接（Legacy）架构

也称为 Legacy Architecture，在 React Native v0.76 之前是默认架构。

1️⃣ 构建阶段

1. Metro Bundler 收集所有 JavaScript 代码、React 组件和资源。
2. 它生成一个名为 JS Bundle 的单一、优化后的文件。
3. 该 bundle 在 构建时 嵌入原生应用。

应用安装后，Metro 不再参与；此后的一切都在 运行时 进行。

2️⃣ 运行时（执行）

当用户启动应用时，会启动 三个线程：

3️⃣ 交互流程（示例）

1. 用户点击一个应当改变背景颜色的按钮。
2. UI Thread 捕获点击事件。
3. 由于原生 UI 不能直接调用 JavaScript，它会把事件 序列化 为 JSON，并通过 异步桥接 发送到 JavaScript 线程。
4. JavaScript 处理事件，更新状态，并触发重新渲染。
5. React‑Native 渲染器 创建新的 UI 描述并通过桥接返回。
6. Shadow Thread（Yoga）在需要时重新计算布局。
7. UI Thread 应用更改，更新原生视图层级。

摘要

• React Native 让你使用已有的 JavaScript/React 知识编写移动应用。
• 核心 React 库 负责状态管理和调和；渲染器（react‑dom 与 react‑native）决定如何呈现 UI。
• 在 传统（桥接）架构 中，JS 包在专用的 JavaScript 线程上运行，而原生 UI 与布局在独立线程上处理，通过异步桥接进行通信。

理解这一流程可以解释为什么 React Native 既感觉熟悉（React），又真正原生（平台特定的 UI 组件）。掌握这些知识后，你可以进一步深入性能优化、新的 Fabric 架构，或开始构建你的第一个跨平台应用！

The JS Bridge

JS 桥将信息发送到 JavaScript 引擎（JSC）。
JSC 反序列化 JSON，运行 JavaScript 代码（例如，使用 useState 更新状态），React 根据这些更改计算新的 UI。

JS Thread 随后将生成的指令序列化回 JSON，并通过异步桥发送。

Shadow Thread 接收此 JSON，Yoga 库读取指令，计算每个元素的精确坐标和属性，并将布局信息传递给 UI Thread，最终绘制更新后的屏幕。

异步桥的局限性

原始的异步桥存在多个缺点，最显著的是桥本身以及对 JSON 的依赖。

1. 序列化瓶颈

• 移动平台和 JavaScript 不能直接通信，只能通过 JSON 交换数据。
• 将对象序列化为字符串以及解析 JSON 会消耗 CPU 周期，增加延迟。
• 当处理大量事件时，这一序列化/反序列化步骤会导致原生端出现卡顿和帧率下降。

2. 单一异步桥

• 每个 UI 相关的事件都必须经过桥传递，即使 JavaScript 不能直接修改原生 UI。
• 大量的 JSON 消息会堵塞桥，导致：
  • 帧率下降
  • 动画卡顿
  • 渲染大列表时出现“白屏”闪烁

3. 单一 JavaScript 线程

• 大多数应用逻辑运行在 JavaScript 线程上。
• 密集计算会阻塞该线程，导致整个应用的性能下降。

由于 React Native 避免阻塞主线程，所有工作都以异步方式执行，将每个事件转换为 Promise 或回调。

核心团队意识到，仅仅优化 JSON 桥并不能根本解决性能问题，于是用 JavaScript Interface (JSI)——一个基于 C++ 的层，直接调用原生 API，消除了序列化和消息传递的需求，取代了异步桥。

Hermes – 由 Meta 创建的开源 JavaScript 引擎 – 为 React Native 进行深度优化，并使用 JSI 直接与原生平台通信。它还带来了：

• 更快的交互时间（TTI）
• 更小的应用包体积
• 降低的内存消耗

Hermes 替代了旧的 JSC，并从 React Native 0.70 起成为默认引擎。

JavaScript Interface (JSI)

JSI 是一个轻量级的 C++ 层，使 JavaScript 能直接与原生代码通信。

• 无消息传递 – 传统桥接的异步队列已被移除。
• 同步调用 – JavaScript 可以持有 C++ 主机对象的引用并直接调用其方法。

示例

// JavaScript
nativeObjectRef.setProperty(value);   // Calls C++ method synchronously

在传统架构中，原生模块（例如蓝牙、相机）在启动时 被急切加载，即使从未使用也会常驻内存。这会增加启动时间和内存占用。

使用 Turbo Modules（新架构）时，模块 按需懒加载，仅在需要时才加载，从而降低内存使用并提升性能。

Source: …

Fabric 系统

Fabric 是一种全新的渲染系统，利用 JSI 和原生端的 Yoga 布局引擎。

在传统方案中，渲染一个大型列表意味着要序列化一个庞大的 JSON 负载、将其排队，并寄希望于 UI 线程不会掉帧——这本质上是一个异步且脆弱的过程。

使用 Fabric 时，JavaScript 通过 JSI 调用 C++ 方法来创建和更新原生视图（例如 iOS 上的 UIView、Android 上的 ViewGroup），同步完成。

Fabric 渲染流水线

Fabric 的内部工作原理超出本文范围，可能会在后续文章中进行介绍。

摘要

你现在已经对以下内容有了扎实的理解：

• 传统架构是如何运作的。
• 为什么异步 JSON 桥会成为性能瓶颈。
• React Native 核心团队如何通过基于 C++ 的 JSI、Turbo Modules 和 Fabric 渲染系统解决这些问题。

还等什么？去构建你的应用吧！