Vue Vapor: 一个没有虚拟DOM的Vue版本
前言
随着Svelte
和SolidJS
的流行,无虚拟DOM模式逐渐开始火了起来。vue
也推出了无虚拟DOM模式的版本,就是我们今天要讲的Vue Vapor
。
什么是Vue Vapor
Vue Vapor
是一个无虚拟DOM模式版本的vue
。这个仓库是2023年11月9日基于vuejs/core仓库(也就是vue3仓库)新建的,项目地址为 https://github.com/vuejs/core-vapor。Vue Vapor
目前还处于实验阶段
,不过你可以通过官方提供的Vue Vapor
演练场在线体验无虚拟DOM版本的vue
。playground演练场的地址为:https://vapor-repl.netlify.app。
目前Vue Vapor
只实现了vue3
中的部分功能,KeepAlive
、Teleport
等还未实现。详情查看官方的TODO:https://github.com/vuejs/core-vapor?tab=readme-ov-file#todo
如何使用Vue Vapor
对于使用者来说无虚拟DOM模式版本的vue
和目前的vue3
用法是一样的,vue
只是对内部实现进行了修改,对外暴露出的API
还是一样的,当然关于虚拟DOM相关的API在Vue Vapor
中没有了。
我们来看看一个demo,和目前vue3
写法是一样的:
<script setup>
import { ref } from 'vue'
const msg = ref('Hello World!')
</script>
<template>
<h1>{{ msg }}</h1>
<input v-model="msg" />
</template>
我们再来看看运行效果:
从*.vue
文件渲染到浏览器真实DOM的过程
我们先来看看目前版本的vue
是如何从一个*.vue
文件渲染到浏览器真实DOM?
目前的vue
是通过webpack
或者vite
等工具先将*.vue
文件编译成一个js
文件,js
文件中主要的就是render
函数。然后执行render
函数生成虚拟DOM,再调用浏览器的DOM API
根据虚拟DOM生成真实DOM挂载到浏览器上。
我们再来看看Vue Vapor
是如何从一个*.vue
文件渲染到浏览器真实DOM?
也是一样的首先通过webpack
或者vite
等工具先将*.vue
文件编译成一个js
文件,js
文件中主要的就是render
函数。然后执行render
函数后会直接调用浏览器的DOM API
生成真实DOM挂载到浏览器上。其实就是跳过了虚拟DOM的过程。
没有虚拟DOM后,Vue Vapor
如何实现响应式
我们先来看看demo编译后的js代码中的render
函数,下面是我简化后的代码:
function render(_ctx) {
_withDirectives(n2, [[_vModelText, () => _ctx.msg]])
_on(n2, "update:modelValue", $event => ((_ctx.msg) = $event))
_renderEffect(() => {
_setText(n1, _ctx.msg)
})
}
这里的n2
变量为input输入框dom元素,n1变量为显示msg
值的h1标签dom元素。明显可以看见render
函数中没有createElementVNode
等生成虚拟DOM的函数调用。
我们先来看看_withDirectives
函数,vue3
的withDirectives
函数的功能为给虚拟DOM增加自定义指令。我们这里没有虚拟DOM,所以这里是给真实DOM(input输入框)增加v-model
的指令。
我们再来看看下面 _on
函数,这里是让input
输入框监听一个名为update:modelValue
的事件,触发事件后会将上下文中的msg
变量的值更新为输入框中的输入值。
我们最后来看看_renderEffect
函数,看名字你可能已经猜出来了。这个函数和vue3
中的watchEffect
比较相似,会立即运行一个函数。并且追踪函数中用的的依赖,这里的依赖是msg
变量。当依赖的值变化时会再次执行这个函数。
这里的_setText(n1, _ctx.msg)
,实际就是执行了n1.textContent = _ctx.msg
。textContent
属性表示一个节点及其后代的文本内容,也可能通过给它赋值的方式删除它的所有子节点,并替换为一个具有给定值的文本节点,和innerText
功能比较相似。
当msg
变量的值变了后就会执行回调函数,在回调函数中会执行_setText
函数。_setText
函数会通过更新h1标签的textContent
属性让h1标签始终显示msg
变量最新的值,从而实现响应式。
总结
这篇文章介绍了Vue Vapor
,没有虚拟DOM版本的vue
。对于普通开发者来说Vue Vapor
其实和目前的vue3
没有什么区别,前提是不涉及虚拟DOM。只是vue
在内部实现上去掉了虚拟DOM,改为直接操作真实DOM。
如果我的文章对你有点帮助,欢迎关注公众号:【欧阳码农】,文章在公众号首发。你的支持就是我创作的最大动力,感谢感谢!
推荐阅读
-
Vue-2 中虚拟 DOM 的理解和原理。
-
Vue Vapor: 一个没有虚拟DOM的Vue版本
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。