React Native

先把这个 topic 说准

React Native 不是“把网页打包成 App”。

它也不是“用 React 语法去写一个浏览器壳”。

更准确地说：

React Native 是一套让 React 组件模型可以驱动原生移动 UI 的框架与运行时体系。

这句话里最重要的是“驱动原生移动 UI”。

因为它说明了三件事：

React Native 和 Web 共享的是组件思维，不是 DOM
它的运行时边界和浏览器完全不同
前端工程师迁移过去时，能复用的是一部分思维，不是全部经验

如果这个定义讲不准，后面很多判断都会歪掉。

为什么前端工程师值得认真学

React Native 对前端工程师的吸引力，从来不只是“会 React 就能写 App”。

它更大的价值在于：

它让 Web 团队可以在不完全切换技术范式的前提下，进入移动产品交付。

这意味着：

团队组织方式会变
设计系统会变
状态管理边界会变
性能判断方法会变
工具链和发布链路也会变

所以这个 topic 不是移动端小扩展。

它本质上是在回答：

一个 Web 团队如何进入移动端，而不把自己对平台边界的理解停留在浏览器时代。

过去的 React Native 为什么容易被讲旧

很多人对 React Native 的印象，还停留在一个老说法上：

JavaScript 和原生之间隔着一条 Bridge。

这个说法在历史上有用。

但如果今天还只会这样讲，就已经明显过时了。

React Native 官方在 2024 年发布的文章里明确说明：

New Architecture 已经到来。

React Native 0.76 把 New Architecture 变成默认选项。

到了 React Native 0.82，官方进一步强调它是首个完全运行在 New Architecture 上的版本。

这意味着：

如果还把 React Native 全部理解成“旧 Bridge 模型”，就会错过今天最关键的运行时变化。

所以 New Architecture 到底在改什么

它不是单点优化。

它改的是 React Native 的几个核心边界：

渲染器
原生模块访问方式
JavaScript 与原生之间的调用模型
与现代 React 特性的对接能力

如果要用一句更容易抓住本质的话来讲：

New Architecture 的核心，不是“名字更现代”，而是它在重新定义 React Native 里 JS、原生和渲染系统之间的协作方式。

不要只背名词：Fabric、TurboModules、Hermes 分别在说什么

Fabric

可以先把 Fabric 理解成：

新的渲染系统。

它不只是一个性能补丁。

它的意义在于：

React Native 的 UI 更新方式，更好地对齐了现代 React 的调度与渲染能力。

这让并发特性、渲染一致性和原生视图更新之间的关系，比旧时代更清晰。

TurboModules

TurboModules 可以理解成：

新的原生模块访问方式。

它的价值不在于“又一个模块系统名词”。

而在于：

过去那种笨重、序列化开销更高的跨边界调用模型，被更直接的调用方式替代了。

Hermes

Hermes 是 React Native 生态里一个非常关键的 JavaScript 引擎。

官方长期把它放在移动端性能、启动速度、内存占用和运行体验的语境里讨论。

所以如果只把 Hermes 讲成“React Native 自带引擎”，也太浅。

更好的理解是：

它是 React Native 试图把移动端运行时体验做得更贴近产品现实的一部分。

为什么说这是“架构变化”，不是“参数优化”

很多人会用“更快了”“更省内存了”去概括 New Architecture。

这种说法没错，但不够。

更重要的是：

它让 React Native 终于不再那么容易被一个旧运行时故事框住。

以前大家一说 React Native，第一反应就是：

Bridge 成本
卡顿
原生能力边界
大项目难做

今天这些问题当然没有完全消失。

但官方架构的叙事重点已经明显变化了。

现在更合理的表达应该是：

React Native 仍然有跨平台框架天然的约束，但它的核心运行时基础已经和几年前不一样了。

Web 工程师迁移时，哪些能力真的能复用

这个问题特别重要。

因为很多团队会在这里产生两种相反的误判。

一种是过度乐观：

“我们会 React，所以移动端也差不多。”

另一种是过度悲观：

“移动端完全是另一门技术，我们现有经验几乎没用。”

更真实的情况在中间。

高度可复用的部分

组件拆分思维
状态管理思维
事件流和数据流的组织方式
TypeScript 建模
设计系统抽象
列表、表单、网络请求、缓存等通用工程模式

不能直接照搬的部分

DOM 相关经验
浏览器 CSS 心智
Web 路由默认假设
浏览器调试习惯
Web 性能瓶颈判断方式

也就是说，React Native 不是“Web 开发的移动壳”。

它更像是：

你把 React 作为思想骨架带了过去，但平台本身已经换了。

Expo 为什么已经不是“给新手玩的简化工具”

很多老印象会把 Expo 看成：

一个适合体验 React Native 的入门层。

今天这样讲已经不够准确。

Expo 官方文档提供的是一整套更完整的工程交付体验。

它解决的问题包括：

项目初始化
路由组织
开发客户端
云端构建
OTA 更新
原生能力接入的一致性

这意味着，Expo 在很多现代 React Native 项目里，已经不是装饰性选项。

它经常是默认工作流的一部分。

所以更成熟的理解应该是：

Expo 不只是“让你更容易开始”，它还在试图降低团队进入 React Native 生产环境的工程门槛。

Expo Router 为什么会让 Web 团队更容易进入移动端

Expo Router 之所以经常被提起，不只是因为“它像 Next.js”。

而是因为它帮 Web 团队在组织方式上获得了熟悉感。

文件系统路由这件事，本身不是移动端必须拥有的能力。

但它能降低认知切换成本。

这在团队迁移时很重要。

因为很多工程问题，不只是技术难。

还包括组织学习成本高。

React Native 的性能应该怎么理解

这是最容易被表面化的部分之一。

很多讨论会直接落在：

React Native 快不快
和 Flutter 谁更快

这种讨论太容易失真。

更靠谱的问法应该是：

具体慢在哪里
是启动问题、列表问题、动画问题，还是桥接问题
是 JS 线程压力、布局压力，还是原生视图更新压力
这个场景是否真的适合跨平台方案

也就是说，性能不是一个整体标签。

它永远是结构化问题。

React Native vs Flutter 应该怎么比较才不空泛

很多比较会把它写成一张表，然后下结论。

表可以有用。

但真正重要的是比较维度的含义。

React Native 的优势，往往在于：

Web 团队迁移成本更低
JavaScript/TypeScript 生态更熟
React 心智可延续
与 Web 团队协作更顺

Flutter 的优势，往往在于：

UI 一致性更强
渲染栈更统一
平台差异被框架吸收得更多

所以这不是“谁更先进”的问题。

而是：

你要的是平台统一性，还是团队和生态的连续性。

容易误导人的几个说法

说法一：React Native 就是原生开发

这不准确。

它最终当然能调用原生能力，也能渲染原生视图。

但它不是“写 Swift/Kotlin 的另一种写法”。

它是一个跨平台框架。

这意味着你必须接受它的抽象层和它的边界。

说法二：React Native 就是 H5 App

这也不准确。

React Native 和 WebView 包壳是两回事。

它不是在浏览器里跑网页再塞进 App。

如果把这两者混为一谈，很多性能和架构讨论都会错位。

说法三：New Architecture 出来了，所有历史问题都没了

这同样太乐观。

New Architecture 解决的是一批长期痛点。

但跨平台框架该有的复杂度并没有消失。

团队仍然需要判断：

这个模块要不要下沉原生
这个交互是不是过度吃性能
这个页面是不是更适合平台特化处理

中国互联网语境里它的价值

在中国互联网语境里，移动端产品密度很高。

团队会遇到：

高频业务迭代
多活动页和多场景入口
复杂登录与风控
与超级 App、扫码、分享、支付等链路的集成

在这种环境里，React Native 的价值通常不只是“跨平台省人”。

更常见的是：

前端团队希望在保留 React/TypeScript 生产力的前提下，尽快进入移动端业务线。

但这也意味着团队更容易在复杂真实业务里暴露平台边界。

所以中国语境下，React Native 往往更考验：

团队是否真的懂平台边界
原生协作是否顺畅
工程治理是否够强

海外语境里为什么 Expo 权重更高

海外很多产品语境更接近：

SaaS
创作者工具
协作工具
中小团队快速试错

在这种语境下，Expo 这类整合式工具链的价值会更明显。

因为团队更看重：

更低的环境成本
更统一的构建和发布流程
更快的实验速度

所以如果只从“技术纯度”看 React Native，而不看团队交付模式，很容易低估 Expo 这类生态层的价值。

面试或技术分享里怎么讲比较像成熟工程师

一个更成熟的说法可以是：

React Native 的核心价值，不在于“前端也能做移动端”，而在于它让 React 这套组件和状态组织方式进入了原生移动应用开发。

但今天讲 React Native，不能再停留在旧 Bridge 叙事上，因为官方已经把 New Architecture 作为主线推进，Fabric、TurboModules 和 Hermes 一起在重塑渲染和原生调用边界。

对 Web 工程师来说，真正可复用的是 React 思维和工程组织方式，而不是浏览器经验本身。

如果是团队落地，则 Expo 生态已经越来越像生产工作流的一部分，而不只是入门工具。

实践建议

实践一：做一个最小的 Expo 项目

不要一上来做复杂应用。

先做一个只包含：

路由
列表
表单
请求
本地状态

的最小项目。

目标不是做功能。

而是感受：

哪些 React 经验能直接复用，哪些地方已经明显不是 Web 了。

实践二：画出 React Native 的运行时边界图

自己用一页图解释清楚：

JS 在哪
原生模块在哪
渲染器在哪
Hermes 在哪
Expo 在工程链路里处于什么位置

只要这张图能画清楚，你对它的理解就会从“会用”升级到“能解释”。

实践三：选一个真实交互做性能观察

例如：

长列表
带图片的 feed
输入联动搜索
多状态表单

观察它的问题到底出在哪一层。

这样你会更快摆脱“React Native 快不快”这种空泛讨论。