稀土掘金技术社区 10月10日 09:55
Vue 3.6 试验性 Vapor Mode:逐步弃用 VDOM,性能再进化
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

Vue 3.6 引入了试验性的 Vapor Mode,标志着其向逐步弃用 VDOM 的方向迈进,预计 Vue 4 将彻底告别 VDOM。Vapor Mode 的核心在于将运行时 VDOM 的计算压力转移至编译时,通过生成高效的渲染 API 来实现元素级定点更新,从而打破 VDOM 模式的性能瓶颈。虽然此举有望大幅提升性能,但同时也带来了编译压力和产物体积增大的潜在挑战。本文将深入探讨 Vapor Mode 的设计理念、性能优势、跨平台解决方案以及当前面临的问题,帮助读者理解 Vue 性能进化的方向。

💥 **告别 VDOM,性能飞跃:** Vue 3.6 推出的 Vapor Mode 旨在逐步取代 VDOM,将运行时计算压力转移至编译时。通过生成高效的渲染 API,实现元素级定点更新,从而解决 VDOM 在视图更新中存在的性能瓶颈,例如不必要的计算和 DOM 操作,以无限接近原生性能。

💡 **编译时优化,运行时轻盈:** Vapor Mode 的核心是将 VDOM 的计算和转换移至编译时。这意味着在代码编译完成后,就能直接生成高效的渲染代码,运行时无需再进行 VDOM 的 diff 操作,从而显著提升渲染效率和应用响应速度。

🌐 **跨平台兼容性依然稳固:** 尽管移除了 VDOM 层,Vue 依然能保持跨平台能力。这是因为 Vue 在模板到 UI 生成的过程中,已经存在一个原子化的“抽象层渲染代码”。渲染器负责将这层抽象代码转换为特定平台的 UI,Vapor Mode 只是修改了 VDOM 到抽象代码的转换逻辑,对下层开发者影响甚微。

⚠️ **当前面临的挑战:** Vapor Mode 目前仍处于试验阶段,存在一些待解决的问题。将大量计算压力转移至编译时可能导致编译过程变长或出现问题。此外,如果渲染的组件过多,可能会生成大量重复代码,导致编译产物体积增大,这是 Svelte 等框架也面临的挑战。

原创 JamesGosling666 2025-10-10 08:30 重庆

点击关注公众号,技术干货及时达!

Vue 3.6 推试验性 Vapor Mode,逐步弃 VDOM!它凭元素级定点更新破 VDOM 性能瓶颈,借抽象代码兼容跨平台,却存编译压力与产物体积问题,带你看透 Vue 性能进化方向!

引言2025/07/25日 vue conf中提到,vue3.6将可以开启Vapor Mode,逐步取消vdom(目前vdom和vapor是兼容状态,估计vue4就彻底和vdom拜拜了)Vapor的核心思想:运行时vdom多余的计算取消,压力转到编译时;在编译后就直接生成了高效的渲染API

灵魂三问一、为什么要干掉vdom?还能是为什么,因为快啊(vdom模式有性能瓶颈)

前置解释:ok,有朋友就要问了,以前用vdom是为了快,现在取消vdom也是为了快,你这是几个意思?

「vdom为什么快?」要知道直接用原生才是性能最好的,为什么对比直接用原生,有vdom会快,因为用vdom,再diff之后,会减少很多多余的dom操作,尽管多了一层vdom,js层面计算量增大了,但是dom api的调用少了,而对比这点js计算dom操作才是最大的性能消耗点,所以有vdom会比你直接原生开发性能普遍好。(当然理论上,你的原生代码要是能做到只做必要的dom操作,那确实性能更高)

「为什么现在取消vdom会快?」因为取消vdom,不是让你直接原生写,所以至少不会更慢,然后新的Vapor Mode为什么更快,这个在下面会有详细说明。

在之前vue中视图更新的最小单位是组件,只要是render依赖的响应式数据变了,那render函数就会重新执行,重新生成vdom -> diff -> 真实渲染,这样的方式在性能上有两个瓶颈:

「重新计算的多余性能消耗」因为是整个组件一起重新计算出vdom,然后去更新,尽管在运行时vue对这块儿已经做了很多优化了,例如:组件级别的缓存与跳过等,但是无论如何都会有不必要的计算出现,最理想的情况应该是只重新计算直接依赖变化的响应式的数据的节点信息;

「多余的dom更新/生成」在重新计算出整个组件的vdom之后,这些vdom再拿去diff,然后把diff出来的vdom拿去真实渲染更新,但是尽管diff算法已经优化成这样了,但是在某些场景下依然会产生多余的dom更新/生成。

虽然vue之前也搞了特别多的优化,但是以上两个问题依然是vdom模式所无法避免的问题,所以要达到无限接近原生的最优性能,只能逐步移除vdom模式。

二、为什么Vapor Mode比Vdom 模式更快?这个问题其实比较简单,因为Vapor是元素级别的,类似svelte,响应式数据更新,会去定点更新对应的元素,而不是整个组件一起更新,所以也就没有vdom那些瓶颈。

三、没有Vdom层,Vue怎么解决跨平台问题?要知道vdom 模式的两大优点就是:

减少多余的dom更新,对比直接写原生,性能提高

作为一层抽象,去描述ui,便于跨平台

以前的跨平台框架(uniapp等)是怎么做的?直接重写Vue的渲染器,Vue默认提供的渲染器实现是浏览器api,所以其他平台只需要把渲染器这层用其他的api实现,移动端就用移动端那套来实现就行了。现在没有vdom来描述ui,那渲染器怎么搞?要理解这个的话,需要先知道vue中关于模板到渲染器去生成UI的整个运行机制

其他节点,大家都比较清楚,关于“抽象层渲染代码”这块儿,我觉得可能需要单独解释一下,之前的理解中渲染器作用应该是vdom转ui,但是实际上在渲染器之前就会生成一层原子化的抽象层渲染代码,渲染器的作用可以理解成是把这层抽象代码转成真实ui。抽象代码示意(并非真实编译产物):

    ounter(lineounter(lineounter(line
    <template>
        dkh
    </template>

      ounter(lineounter(lineounter(lineounter(lineounter(lineounter(line
      const text = createText('dkh');

      // 具体实现放渲染器中
      function createText(txt = ''){
       ....
      }

      可以看到这层抽象代码其实是原子化的,所以可以看作在渲染器中,要做的就只是实现这些渲染函数,而不是单纯的vdom转ui的逻辑。「所以本来vdom转ui这套逻辑已经是通过这层抽象渲染代码解耦了的」,所以即使移除了vdom,那些基于vue的跨端框架也无需大量的改动就能完成适配。而vue团队关于这块儿要做的也只是修改vdom转抽象代码的逻辑,这对下层开发者理论上也应该是无感的。

      Vapor Mode目前的问题OK,前面说了这么多,貌似Vapor应该是碾压Vdom,但是现在的Vapor Mode也只是试验阶段,依然也存在一些问题的。

      把运行时Vdom的计算和转换等全部取消,把压力都给到了编译时,编译过程可能出问题且时间长

      如果渲染的组件过多,可能会出现大量重复代码,导致编译产物体积过大

      其实最主要的也是第二个问题,Svelte也有类似的问题,但是就目前的观察Vapor这个问题还没有很明显出现,另外就是vapor目前只是试验阶段,目前是vapor和vdom可以兼容,后面可能尤大看市场认可度比较高的话,就会在vue4中彻底移除vdom了吧。

      最后感谢大家的阅读,以上是我个人关于Vapor的一些理解,可能有些说的不合适的地方,有不同见解的同学可以在评论一起探讨一下👍

      AI编程资讯AI编码专区指南:

      https://aicoding.juejin.cn/aicoding

      ~

      阅读原文

      跳转微信打开

      Fish AI Reader

      Fish AI Reader

      AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

      FishAI

      FishAI

      鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

      联系邮箱 441953276@qq.com

      相关标签

      Vue.js Vapor Mode VDOM 性能优化 前端 JavaScript 编译时 运行时 Vue 3.6 Vue 4
      相关文章