最近在项目中遇到并解决了一个弹窗拖拽卡顿严重的问题，解决过程还是挺有意思挺有感触的，因此记录一下。
优化前平均执行一次 mousemove 时间需要 60 ms，优化后只需要 1 ms，性能提升 60 倍
看完本篇文章，可以了解到以下内容
- 解决问题的思考方式
- 基本的调试技巧
- Vue 源码的相关知识
问题描述
由于业务内容比较敏感，我这里做了一个小 Demo 来复现问题，在线体验地址
卡顿效果如下：
然后同事还告诉我，如果表格里面没有数据，就不会卡顿了
优化卡顿问题
在进行优化前，我们首先要确定卡顿的原因，根据卡顿的原因，才能找到优化的方向
确定卡顿的原因
同事 A：既然 Table 没有数据就不会卡顿，那明显就是 Table 数据量导致的，这时候我们的优化手段，应该是通过减少一次性渲染的数据量，例如分页、虚拟滚动。
当时我听了，似乎有点道理，但其实不太对。原因如下：
- 表格数据只有 20 条，数量不多，数据量应该不是导致卡顿的核心原因。
因此我用 Chrome Performance 工具尝试查找性能瓶颈，部分内容如下：
这个图怎么看呢？
Task：代表一个宏任务，这个 Task 是由 mousemove 事件触发的，就是我们拖拽弹窗的事件回调。
纵向虚线：两条虚线间的时间代表一帧
可以看出，在一帧内，并不能完成一个 Task，由于 JS Task 的执行，和渲染是相互阻塞的，因此会导致在几帧内，仍然无法渲染出新的图像，即引起掉帧，从用户的角度看就是卡顿。
那是什么原因导致 JS 执行时间过长呢？
从图中可以看到，执行了非常多的 patch 函数。
patch 函数，是 Vue3 的补丁函数，它的作用是：在状态改变后，比对新 VNode 和老 VNode，找出差异的部分，并进行更新。
另外，Vue 会对组件进行编译优化，大部分情况下，如果组件的 props 和 slots 没有变化，是可以跳过该组件的 patch 阶段的。
理论上，我们拖拽只改变了弹窗的 style 属性，并没有改变 Table 组件的 props 和 slots，因此 Table 组件及其子组件的 patch 理论上是会被跳过的。而 Performance 工具中搜集到的函数，不应该会有这么多 patch 函数的调用.
但事实上并不如我们想象的那样，里面有非常多的 patch，我猜是因为某些特殊原因导致优化失效，patch 进入到 Table 组件内部
那接下来要做的，就是找到这个原因，这个我们可以直接到源码那里调试
恰好看过一点源码，我们直接去找 patch 函数的定义，我们直接在控制台 ctrl + shift + F 全局搜索关键字： const patch = ( ，就能找到源码了
然后打个断点
其中 n1 和 n2，就是老的 VNode 和新的 VNode，patch 函数会比对两个 VNode 的差异，找到它们的差异，然后更新，同时也会继续对它们的 children 进行 patch。
但是这样打断点，它每个元素的 patch 都会停下来，因此我们要设置条件断点，我们只关注 Table 组件，需要在 Table 组件停下来
那问题就变成了，如何设置条件断点，让在 Table 组件 patch 时停下来？
我们可以通过组件名称来判断，因此断点条件为 n1?.type?.name === 'ATable'， VNode.type 属性就是我们定义Vue 组件的那个对象
这样就停在 Table 组件上了，然后我们继续执行，会进入到这几个函数
patch > processComponent > updateComponent
const updateComponent = (n1, n2, optimized) => { const instance = n2.component = n1.component; if (shouldUpdateComponent(n1, n2, optimized)) { if (instance.asyncDep && !instance.asyncResolved) { if (true) { pushWarningContext(n2); } updateComponentPreRender(instance, n2, optimized); if (true) { popWarningContext(); } return; } else { instance.next = n2; invalidateJob(instance.update); instance.update(); } } else { n2.el = n1.el; instance.vnode = n2; } };
我们可以看到这里有个 shouldUpdateComponent 的判断，如果组件不需要 update，就说明该元素不需要更新，就不会继续往组件里面 patch 了。
实际运行可以知道 shouldUpdateComponent 返回值为 true，那我们看看 shouldUpdateComponent 函数源码（有节选）：
export function shouldUpdateComponent( prevVNode: VNode, nextVNode: VNode, optimized?: boolean ): boolean { const { props: prevProps, children: prevChildren, component } = prevVNode const { props: nextProps, children: nextChildren, patchFlag } = nextVNode const emits = component!.emitsOptions // 判断是否可以优化 if (optimized && patchFlag >= 0) { // 如果有动态的 Slots，就需要更新组件 if (patchFlag & PatchFlags.DYNAMIC_SLOTS) { // slot content that references values that might have changed, // e.g. in a v-for return true } // 如果所有的 props 都没有改变，就不需要更新组件 // 这个是组件有动态 props（传的 props 名字也是变量）的分支，如 v-bind:[key] // 需要对比所有 props if (patchFlag & PatchFlags.FULL_PROPS) { // 对比所有 props，如果没有改变，就 return false return hasPropsChanged(prevProps, nextProps!, emits) } // 如果所有的 props 都没有改变，就不需要更新组件 // 这个是组件的所有 props 的名字固定，那就值对比部分会变化的 props 即可 else if (patchFlag & PatchFlags.PROPS) { const dynamicProps = nextVNode.dynamicProps! for (let i = 0; i < dynamicProps.length; i++) { const key = dynamicProps[i] if ( nextProps![key] !== prevProps![key] && !isEmitListener(emits, key) ) { return true } } } } else { // this path is only taken by manually written render functions // so presence of any children leads to a forced update // 翻译：这条路径是手写 render 函数，才会走的路径，所有 children 都会被强制更新 if (prevChildren || nextChildren) { // $stable 是用于跳过强制更新，但 $stable 需要手动设置，一般不会设置 if (!nextChildren || !(nextChildren as any).$stable) { return true } } if (prevProps === nextProps) { return false } if (!prevProps) { return !!nextProps } if (!nextProps) { return true } return hasPropsChanged(prevProps, nextProps, emits) } return false }
从 shouldUpdateComponent 的注释中（英文那段），可以看出，手写渲染函数时，会强制更新所有 children
由于 JSX 实际上也会编译成渲染函数，因此 JSX 也会走到该分支
而 Table 组件，由于其复杂性，大多数组件库都会选择使用 JSX 去实现，Antd vue 也不例外，因此没有走优化的分支，从而对里面的元素递归进行 patch，由于 Table 组件内的元素非常的多，所以我们在 Performance 工具中会看到那么多的 patch 运行
为什么使用 template 的模板会有优化？
Vue 会在编译模板时，分析模板中，动态部分和静态部分，那么在比对 VNode 的时候，就可以只对比动态部分，跳过静态部分，从而提升性能。
我们可以看这个在线例子
从上图可以看出，模板编译后的代码，createElementBlock 函数（可以理解为 render 的 h 渲染函数）在渲染函数 h 的基础上，会多传一个参数 PatchFlag（3，二进制为 11) ，这就代表了，这个 VNode 对应的元素，动态部分为 Text 和 Class，其他内容都是静态的。
而我们写渲染函数的时候，是不会传 PatchFlag 的，因此 Vue 不知道哪些内容是动态的，哪些是静态的，因此没有优化。
JSX 也会经过编译，为什么它不能生成 PatchFlag？
我在《浅谈前端框架原理》中谈到过这个问题：
- JSX 一种 ECMAScript 的语法糖，基于 ECMAScript 语法
- Template 则是扩充了 HTML 语法
两者都能用于描述 UI，但 template 相对于 JSX，灵活性较低，但这也意味着其分析的难度更低，更容易找出动态部分和静态部分
而 JSX 基于 ECMAScript，ECMAScript 语法非常灵活**，难以实现静态分析**
例如：js 的对象可以复制、修改、导入导出等，用 js 变量存储的 jsx 内容，无法判断是否为静态内容，因为可能在不知道哪个地方就被修改了，无法做静态标记。
但也并不是完全没有办法，例如可以通过约束 JSX 的灵活性，使其能够被静态分析，例如 SolidJS。但目前 Vue 没有做。
实施优化
既然问题已经找到了：Table 组件是 JSX 写的，因此没有编译优化，Vue 会强制进入 Table 组件对立面的元素进行更新。
但我们只是拖拽一下弹窗，Table 组件的内容是完全没有变的，要想办法不要强制更新 Table 组件及其 children。
刚好 Vue3.2 出了一个新的命令 v-memo ，可以缓存一个模板的子树，只要 v-memo 依赖的值没变，就不会去 patch 组件
对于 v-memo 的更多内容，可以查看我写的文章《Vue v-memo 指令的使用与源码解析》
因此，我们只需要加入一行代码即可
<a-table v-memo="[columns, tableData]" :columns="columns" :data-source="tableData" bordered :pagination="false" :scroll="{ y: '650px' }" size="small" > <template #bodyCell="{ record, column, text, index }"> <template v-if="column.dataIndex === 'a'"> <div> <a-input v-model:value="tableData[index].a"></a-input> </div> </template> </template> </a-table>
优化后，就非常丝滑了，Gif 图就不放了，因为 Gif 录屏的时候掉帧了。。。可以直接到在线地址体验
优化后的 Performance 工具截图
可以看出，每个 Task 执行时间已经降到 1 ms 左右，每帧都能绘制出一个图像
总结
当我们遇到问题时，首先要思考造成问题的原因，因为这决定了你排查和优化的方向，如果一开始就不对，可能很难达到效果。
找到排查方向后，就可以提出猜想，然后进行验证。我这里是直接通过调试源码去验证，调试过程需要一定的技巧，可以利用好全局搜索和条件断点，如果对源码有一定的熟系，那就更事半功倍了。
最后，希望本文能对大家有所帮助，当遇到同类问题时，也能快速想到问题原因和解决方案。
如果这篇文章对您有所帮助，可以点赞加收藏👍，您的鼓励是我创作路上的最大的动力。也可以关注我的公众号订阅后续的文章：Candy 的修仙秘籍（点击可跳转）
