如果从架构原理来看，RN（React Native）和 Flutter 最大的区别可以概括成一句话：

RN：JavaScript/TypeScript 驱动原生 UI；Flutter：Dart 驱动自己的渲染引擎。

1. 整体架构对比

React Native ┌──────────────────────────────┐ │ React / JS / TS │ │ Component / Hooks / State │ └──────────────┬───────────────┘ │ JS ↔ Native 通信 (现代 RN: JSI) │ ┌──────────────▼───────────────┐ │ React Native Runtime │ │ Fabric / TurboModules / JSI │ └──────────────┬───────────────┘ │ Native Components │ ┌───────┴───────┐ │ │ iOS UIKit Android View

Flutter ┌──────────────────────────────┐ │ Dart App │ │ Widget / State / Business │ └──────────────┬───────────────┘ │ Flutter Framework │ ┌──────────────▼───────────────┐ │ Flutter Engine │ │ Dart Runtime + Skia/Impeller │ └──────────────┬───────────────┘ │ GPU / Surface │ ┌──────┴──────┐ │ │ iOS Android

2. 最核心的架构区别

3. RN 的核心：JS 驱动 Native

早期 RN 经常被描述成：

JS │ │ Bridge ▼ Native │ ▼ UIView / Android View

例如：

<View> <Text>Hello</Text> <Button title="OK" /> </View>

最终并不是 RN 自己画一个 Button，而是由 RN 的架构映射到平台对应的 Native View。

现代 RN 已经发生了比较大的变化：

React ↓ Fabric ↓ JSI ↓ C++ / Native ↓ UIKit / Android

所以现在讨论 RN 架构时，最好不要再简单理解成：

JS → JSON Bridge → Native

更准确的是：

React + JS/TS Runtime + JSI + Fabric + TurboModules + Native Platform

4. Flutter 的核心：自己画 UI

Flutter 的思路完全不同。

你写：

Container( child: Text("Hello"), )

Flutter 并不是把Container转换成：

UIView Android View

而是：

Widget ↓ Element ↓ RenderObject ↓ Flutter Engine ↓ Impeller ↓ GPU

也就是说：

Flutter 的 Button、Text、List、ScrollView 等大量 UI 都是 Flutter 自己实现的。

所以 Flutter 能做到：

同一份 Widget ↓ ┌─────┴─────┐ iOS Android └─────┬─────┘ ↓ Flutter Engine ↓ GPU

这也是 Flutter 跨平台 UI 一致性比较强的根本原因。

5. 两者最大的架构差异：谁负责渲染？

这是面试里非常值得讲的一点。

RN

React Component ↓ React Native ↓ Native Component ↓ UIKit / Android View ↓ 系统渲染

所以 RN 更接近：

跨平台 React 层 + 原生 UI。

Flutter

Flutter Widget ↓ RenderObject ↓ Flutter Engine ↓ Impeller ↓ GPU

所以 Flutter 更接近：

跨平台 UI 框架 + 自己的渲染体系。

6. 这会直接影响性能

假设有一个复杂列表：

1000 个 Cell ↓ 大量布局 ↓ 大量滚动 ↓ 动画

RN：

JS/React ↓ RN ↓ Native View ↓ iOS / Android rendering

Flutter：

Dart ↓ Flutter Framework ↓ Engine ↓ GPU

因此两者的性能瓶颈也不完全一样。

RN 常见瓶颈

JS 线程 ↓ JS 执行 / React 更新 ↓ JSI / Native ↓ Native UI

特别是：

• JS 计算太重

• 大量 React 重渲染

• JS 与 Native 高频交互

• 大型列表

• 复杂动画

Flutter 常见瓶颈

更多会出现在：

• Dart 逻辑

• Widget rebuild

• Layout

• Paint

• GPU 渲染

• 图片/Shader

• 大量 Widget

7. RN 为什么更容易接入原生生态？

因为 RN 的设计本身就非常接近：

React + Native

例如你已经有：

iOS SDK Android SDK

可以通过 Native Module 暴露给 JS：

JS/TS ↓ TurboModule ↓ Swift / Objective-C Kotlin / Java

所以如果一个公司已经拥有大量：

• iOS Native 代码

• Android Native 代码

• 原生 SDK

• 原生组件

RN 往往比较容易融入现有技术体系。

8. Flutter 的 Native 通信

Flutter 通常是：

Dart ↓ MethodChannel ↓ Swift / Kotlin

例如：

Flutter │ │ MethodChannel ▼ Android Kotlin │ ▼ Native SDK

或者：

Flutter │ │ Platform Channel ▼ iOS Swift

当然 Flutter 也可以通过：

FFI

直接调用 C/C++ 等 Native 能力。

9. 架构思想上的区别

可以把它们理解成两种路线：

RN：复用 Native

React │ React Native │ ┌──────────┴──────────┐ ▼ ▼ iOS Native Android Native │ │ UIKit View

重点是：

尽可能利用已有的 Native 平台。

Flutter：抽象 Native

Flutter │ Flutter Widget │ Flutter Engine │ GPU ┌─────────┴─────────┐ ▼ ▼ iOS Android

重点是：

尽可能把 UI 和渲染从 Native 平台抽离出来。

10. 如果从“大型 App 架构”来看

这时候两者差异就更有意思了。

RN 通常是：

App │ ┌─────────┴─────────┐ │ │ Native Layer RN Layer │ │ iOS / Android React / TS │ │ Native SDK JS Business

所以很适合：

Native 主体 + RN 页面/业务模块

例如一个大型 App：

原生 App Shell │ ├── 首页 —— RN ├── 商品 —— RN ├── 订单 —— RN ├── 支付 —— Native ├── 相机 —— Native └── 地图 —— Native

Flutter 更容易形成：

Flutter App │ ├── UI ├── State ├── Business ├── Network └── Navigation │ ↓ Platform Channel │ ┌─────┴─────┐ iOS Android

也就是：

Flutter 更倾向于整个 App 使用 Flutter 架构。

11. 一个非常好记的总结

如果你正在准备RN / Flutter 面试，可以直接记这张图：

跨平台方案 │ ┌─────────┴─────────┐ │ │ RN Flutter │ │ React / TS Dart │ │ Fabric Widget │ │ JSI Flutter Engine │ │ Native Components Impeller │ │ UIKit / Android GPU

一句话：

RN 的核心是“JavaScript/React 驱动 Native UI”，Flutter 的核心是“Dart/Widget 驱动自己的渲染引擎”。

如果进一步往源码和底层架构深入，最值得比较的是RN 的 Fabric + JSI + TurboModules和Flutter 的 Widget → Element → RenderObject → Engine → Impeller，这部分也是两者真正拉开架构差异的地方。