相同V8引擎与Skia渲染下，ReactNative为何比WebView性能更优？

• 渲染链路开销差异
  WebView的渲染需要完整走Web内核的标准流程：先解析HTML/CSS构建DOM树、CSSOM树，合并为渲染树后再进行布局计算（重排）、绘制（重绘）、图层合成，额外多了整个DOM层的计算开销，哪怕是简单的文本渲染也需要经过多层校验和计算。而React Native（以下简称RN）的JS侧仅输出原生视图的描述信息，直接映射为Android平台的原生View组件，完全没有DOM相关的计算开销。
• 线程调度逻辑差异
  WebView中JS线程和UI渲染线程是互斥的，JS执行长任务会直接阻塞UI渲染，滚动、动画等高频操作非常容易出现掉帧。RN的JS线程和原生UI线程是独立运行的，仅在需要同步视图更新时才会进行少量数据交互，新版本RN引入JSI架构后甚至可以实现原生侧直接调用JS方法、UI更新无序列化开销，线程阻塞的概率大幅降低。
• 交互响应延迟差异
  WebView的用户触摸事件需要先经过Web内核的事件捕获、冒泡、代理等完整事件流处理，再回调到JS逻辑，单次交互的延迟普遍比原生高100~300ms，快速连续操作很容易出现无响应、响应顺序错乱的问题。RN的事件直接绑定到原生View的触摸回调，大部分基础交互（比如点击、滚动）可以直接在原生侧响应，不需要等待JS层处理，延迟和原生开发基本一致。
• 资源复用与内存占用差异
  WebView本身的内核初始化就会占用至少100M以上的额外内存，多WebView实例内存会成倍增长，且长列表等场景下Web内核的节点复用效率极低，滚动时频繁创建销毁DOM节点很容易导致内存抖动。RN复用Android原生的视图复用机制，长列表场景下仅渲染可见区域的组件，内存占用远低于同复杂度的WebView页面，也不会出现频繁GC导致的卡顿。
• 原生能力调用开销差异
  WebView调用原生能力需要通过JSBridge进行数据的序列化/反序列化，高频调用（比如实时获取传感器数据、逐帧动画控制）的开销非常大，很容易导致数据传输延迟。RN的JS和原生通信通过JSI或者原生Bridge实现，不需要经过字符串序列化，数据传输效率是JSBridge的数倍甚至数十倍，原生能力调用的延迟几乎可以忽略。

哪怕二者同样使用V8作为JS引擎、同样基于Skia做底层渲染，差异核心在于有没有Web内核的额外 overhead：

WebView的能力边界是Web标准，必须完整兼容所有Web前端的语法规范、事件机制、API标准，哪怕很多特性在App开发场景完全用不到，也要保留完整的处理逻辑，这部分冗余开销是WebView性能上限低的根本原因。

而RN本质上是用JS写原生应用，所有JS逻辑最终都会映射为原生平台的API、组件调用，不需要兼容Web标准的冗余逻辑，相当于直接跳过了Web内核这一层的所有额外计算，自然性能表现更接近原生开发，远优于WebView。

内容的提问来源于stack exchange，提问作者JensenChen