从 WebView 到 React Native，再到 Flutter：用 Runtime 视角重新理解跨端框架

当我们讨论 RN、Flutter、KMP 时，很多争论停留在"哪个好""性能谁高""岗位多不多"。

但真正拉开层级差距的，不是 API，而是UI 在系统中的存在方式。

当我开始从 Runtime（运行时）与 UI 系统结构 去看这些框架时，才发现：

它们的根本差异，不在语言，不在生态，而在UI 是否跨 Runtime。

一、先统一概念：什么是 Runtime（运行时）？

Runtime 不是库，也不是框架，而是：

👉 一套能独立执行代码、管理内存、调度任务、维护对象模型的系统环境。

常见 Runtime：

JS Runtime（Hermes / V8 / JSC）
Java Runtime（ART）
Dart Runtime
iOS Objective-C / Swift Runtime

每个 Runtime，本质上都是一个独立的小世界。

二、WebView 混合：最原始的「双 Runtime + Bridge」

传统 WebView + JSBridge 架构：

复制代码

JS Runtime（浏览器内核）
        ⇄ Bridge ⇄
Native Runtime（Android / iOS）

特点：

JS 操作 DOM
Native 提供系统能力
原生并不知道页面结构
UI 完全由浏览器内核掌控

👉 这是最典型的双 Runtime 架构。

问题也很明显：

UI 对原生是黑盒
高频交互性能不可控
无法纳入原生 UI 体系

三、React Native：把"网页"升级成"原生 UI 说明书"

React Native 做了一件本质性的改变：

👉 不再让 JS 操作 DOM，而是用 JS 描述"原生 UI 说明书"。

例如：

html 复制代码

<View>
  <Text>Hello</Text>
</View>

这不是创建控件，而是在生成：

👉 一份"原生 UI 说明书（虚拟 UI 树）"。

RN 的核心链路

JS 生成虚拟 UI 树（说明书）
State 变化 → 新树 → Diff
通过 Bridge 发送 UI 操作指令
原生构建 Shadow Tree
创建/更新真实控件
系统完成渲染

本质可以概括为：

👉 RN = JS UI 说明书 + 跨 Runtime UI 协议 + 原生执行器

四、RN 的本质特征：UI 是「跨 Runtime 的系统」

在 RN 中：

UI 状态 / Diff 在 JS Runtime
UI 创建 / 更新 / 绘制在 Native Runtime
每一次 UI 变化，都必须跨 Runtime 同步

👉 UI 本身是一个分布式系统。

这正是 RN 所有复杂度的根源：

Bridge 成本
调度延迟
多线程同步
调试困难

这些不是"工程没写好"，而是结构特征。

五、Flutter 为什么出现：干掉"跨 Runtime UI"

Flutter 的设计目标从一开始就和 RN 不同：

👉 不要 Bridge

👉 不要原生控件

👉 不要平台 UI 系统

Flutter 选择的是：

html 复制代码

Dart Runtime + Flutter Engine + Skia
        ↓
自己维护 UI Tree / Layout / Paint / Animation

也就是说：

UI Tree 在 Flutter Runtime
Diff 在 Flutter Runtime
布局在 Flutter Runtime
绘制在 Flutter Runtime

👉 UI 主链路在单一 Runtime 内闭环。

原生只负责：

窗口
输入
系统能力

六、关键分界线：不是"几个 Runtime"，而是"UI 在哪"

很多人会说：

Flutter 也有 Dart Runtime + 原生 Runtime，不也是双 Runtime？

从操作系统事实看没错。

但从架构意义上，这是完全不同的层级。

真正的分界线是：

RN / WebView

👉 UI 的生成与执行横跨两个 Runtime

👉 UI 是跨 Runtime 同步系统

Flutter（即使加上 KMP）

👉 UI 主循环完全在 Flutter Runtime 内

👉 跨 Runtime 的只是业务调用

所以更准确的说法是：

👉 RN 是"双 Runtime UI 系统"

👉 Flutter 是"单 Runtime UI 引擎系统"

七、KMP 的位置：业务 Runtime，而不是 UI 框架

KMP 的核心价值不在 UI，而在：

Domain / UseCase
数据层
协议层
状态机
业务一致性

它解决的是：

👉 业务 Runtime 的复用问题。

典型高阶结构是：

html 复制代码

UI Runtime（Flutter / CMP / RN）
        ↑
业务 Runtime（KMP）
        ↑
系统 Runtime（Android / iOS）

八、一句话统一所有跨端体系

WebView：双 Runtime + 黑盒 UI
RN：双 Runtime + 原生 UI 协议
Flutter：单 Runtime + UI 引擎
KMP：共享业务 Runtime

或者更狠一点：

👉 RN 是桥接架构的极致，Flutter 是去桥接架构的结果。

九、我的最终认知模型

RN：JS 写原生 UI 说明书 → Bridge → 原生绘制

Flutter：Dart 写 UI → 引擎直接绘制

KMP：Kotlin 写业务内核 → 多端复用

原生：系统能力与硬件边界