从 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 说明书”。
例如：
<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 选择的是：
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 的复用问题。
典型高阶结构是：
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 写业务内核 → 多端复用
原生：系统能力与硬件边界