Description
一次插槽带来的性能问题
在一次正常的业务代码里面使用了 element-plus 的 el-tooltip 组件，结果用 performance 调试的时候发现，操作时候该部分的性能异常的差，能阻塞 1ms。考虑到用户是连续操作背景下，无疑会带来明显的卡顿。代码简化如下
<button @click="count++">update</button>
count: {{ count }}
<el-text>
<div> {{ Date.now() }} </div>
</el-text>
<div v-for="item in 10" :key="item">
<el-tooltip>
<div> {{ item }} {{ Date.now() }} </div>
</el-tooltip>
</div>就是上面这段看起来没有问题的代码，通过遍历生成了 10 个 el-tooltip 组件，是正常不过的用法了。可是这里却又一个奇怪的问题，在 count 发生更新时候，下面的 el-tooltip 这里会也会自动更新，不仅 Date.now() 值会随着 count 更新而更新，而且通过 performance 调试可以发现 el-tooltip 组件本身也重新渲染了，按照响应式更新的方式，el-tooltip 是不应该更新的，比如上面的 el-text 组件就很正常的不会更新，难道是 el-tooltip 组件里面有什么魔法操作？
从 el-tooltip 开始排查，里面实现大致通过多层包装最后通过 OnlyChild 来包装生成返回
export const OnlyChild = defineComponent({
name: 'onlyChild',
setup(_, { slots, attrs }) {
return () => {
const defaultSlot = slots.default?.(attrs)
const forwardRefDirective = useForwardRefDirective(
NOOP
)
if (!defaultSlot) return null
const firstLegitNode = defaultSlot?.[0]
const newNode = cloneVNode(firstLegitNode!, attrs);
const result = withDirectives(newNode, [
[forwardRefDirective],
])
return result
}
},
})可以看到该 OnlyChild 组件内部使用了 cloneVNode 方法，将传入的 slots.default 中的第一个节点进行克隆，element-plus 组件里面的属性特别的多，直接 cloneVNode 会有不少性能损耗的，尤其对于用户侧的项目，能少用 element-plus 这种面向中后台为主的组件库还是比较好。排查看这里确实不应该是触发更新的源头。
于是查看编译后的 sfc 代码
// _sfc_render 函数主要内容
_createVNode(_component_el_text, null, {
default: _withCtx(() => [
_createElementVNode(
"div",
null,
_toDisplayString(Date.now()),
1 /* TEXT */
),
]),
_: 1 /* STABLE */,
}),
(_openBlock(),
_createElementBlock(
_Fragment,
null,
_renderList(10, (item) => {
return _createElementVNode(
"div",
{
key: item,
},
[
_createVNode(
_component_el_tooltip,
null,
{
default: _withCtx(() => [
_createElementVNode(
"div",
null,
_toDisplayString(item) +
" " +
_toDisplayString(Date.now()),
1 /* TEXT */
),
]),
_: 2 /* DYNAMIC */,
},
1024 /* DYNAMIC_SLOTS */
),
]
);
}),
64 /* STABLE_FRAGMENT */
)),上面代码是生成的渲染函数的主要部分，可以看到都是通过 _createVNode 的方式来创建新的节点，不过可以看到主要的不通电， _component_el_text 里面 patchFlag = 0，而 _component_el_tooltip 是 patchFlag = 1024 /* DYNAMIC_SLOTS */，而这导致的变化是在 patch 阶段，判断组件是否更新会调用 shouldUpdateComponent，而 patchFlag = 1024 会返回 true，patchFlag = 0 则为 false。从而导致了 el-tooltip 的会更新，而 el-text 不会更新。从 patchFlag = 1024 可以看到，这个 flag 表示的是动态插槽，也就是插槽内容有变化，需要重新渲染。只是为什么是动态的？
如果这个时候再模版代码里面最后面添加
<el-tooltip>
<div> {{ count2 }} {{ Date.now() }} </div>
</el-tooltip>
<!-- 生成的sfc -->
_createVNode(_component_el_tooltip, null, {
default: _withCtx(() => [
_createElementVNode(
"div",
null,
_toDisplayString($setup.count2) + " " + _toDisplayString(Date.now()),
1 /* TEXT */
),
]),
_: 1 /* STABLE */,
});可以发现生成的 sfc 是不带有 DYNAMIC_SLOTS 标识的，同时和 el-text 一样，不会触发内部插槽更新。对比一下发现明显的不同点在于前者通过 v-for 的形式生成，进而导致最后编译 patchFlag 不同。
**这样可以基本确定问题了，在 v-for 循环中，如果传入了动态内容作为插槽一部分，则该节点的 patchFlag = 1024 组件会随着父组件一起更新。**这就导致了如果父组件一直更新，子组件不管如何都会更新的情况，那要如何避免呢？其实对于上述案例，**用 v-once 就能直接解决，避免只是为了快速生成一组 el-tooltip。**对于 el-tooltip 其更新的机制会重新执行 cloneVNode 在叠加繁杂的参数，导致性能下降。
这里的 patchFlag = 1024 的逻辑可以在深入一下，在 transform 阶段会对 v-for 元素进行专门处理
// postTransformElement 处理
const shouldBuildAsSlots = isComponent && vnodeTag !== TELEPORT && vnodeTag !== KEEP_ALIVE;
if (shouldBuildAsSlots) {
const { slots, hasDynamicSlots } = buildSlots(node, context);
vnodeChildren = slots;
if (hasDynamicSlots) {
patchFlag |= 1024;
}
}
//buildSlots
let hasDynamicSlots = context.scopes.vSlot > 0 || context.scopes.vFor > 0;
hasDynamicSlots = hasScopeRef(node, context.identifiers);其中 hasScopeRef 会对于当前元素里面是否包含表达式的方式，而我们组件代码里面用了 <div> {{ item }} {{ Date.now() }} </div> 里面包含表达式内容，因此最后 patchFlag = 1024。
v-memo 使用
前面提到的 v-for 的插槽如果含表达式则会导致 patchFlag = 1024，从而导致性能问题，但是 v-for 还有非常容易忽略的问题，虽然正常都是添加 :key 来添加唯一标识，让 vue 能正确更新 vnode，但是如果组件状态发生更新变化，整个组件都会被重新渲染，可以看下面的例子：
<script setup lang="ts">
import { ref } from 'vue';
const count = ref(0)
</script>
<template>
<button @click="count += 1">更新{{ count }}</button>
<div v-for="item in 100" :key="item">
{{ item }} {{ Date.now() }}
</div>
</template>当点击 button 的时候，整个组件都会重新渲染，包括 v-for 里面的部分，普通情况下 vnode 节点的更新，并不会消耗太多性能，然而当 v-for 存在大量节点的时候，并且每个节点更新都包含不少逻辑，就会导致性能问题，而这一点往往很容易被忽略。
最好的优化方式是采用子组件，比如下面：
<script setup lang="ts">
import { ref } from 'vue';
import ItemComponent from './ItemComponent.vue'
const count = ref(0)
</script>
<template>
<button @click="count += 1">更新{{ count }}</button>
<ItemComponent v-for="item in 100" :key="item" />
</template>由于 props 未发生变化，shouldUpdateComponent 返回 false，ItemComponent 则不需要更新，从而避免了数据过大导致的性能问题。
还有一种方式是，采用 v-memo 的方式，官方介绍到：
v-memo 仅用于性能至上场景中的微小优化，应该很少需要。最常见的情况可能是有助于渲染海量 v-for 列表 (长度超过 1000 的情况)
<script setup lang="ts">
import { ref } from 'vue';
const list = ref([...new Array(100)].map(() => ({ count: 0 })))
const test = ref(0)
</script>
<template>
<button @click="list[0].count += 1">更新{{ test }}</button>
<div v-for="(item, index) in list" :key="index" v-memo="[item.count]">
{{ item.count }}{{ +Date.now() }}
</div>
</template>上面例子中，点击按钮，只会触发遍历中的第一个节点更新，当传入的依赖数组没有变化时，甚至虚拟 DOM 的 vnode 创建也将被跳过，达到完美优化的方式。
在生成的 sfc 里面，可以看到 v-memo 的主要作用是会有一个 _isMemoSame 的判断，如果是 true 的话，都不会进入 patch 直接返回，这对大量数据的渲染是非常有帮助的，减少了不必要的是否更新判断。
v-memo 的特别适合在数据量特别大，但是节点简单无需做组件封装，或者因耦合过深组件无法封装的业务里面。其使用也非常类似 react 里面的 memo 方式，都是通过依赖来缓存是否需要更新。