一顿操作，我把 Table 组件性能提升了十倍

一次操作，我将Table组件的性能提升了十倍，在渲染和交互上会有一定程度的卡顿。通常我们优化表格有两种方式：一种是分页，一种是虚拟滚动。这两种方式的优化思路是减少DOM渲染的次数。在我们公司的项目中，会选择分页的方式，因为虚拟卷轴无法正确读取行数，会出现Accessibility问题。记得2019年，我在Zoom实现了基于Vue.js前后端分离的优化方案，基于ElementUI组件库开发了ZoomUI。其中，我们在重构用户管理页面时，使用了ZoomUI的Table组件来替代旧的jQuery开发的Table组件。因为大部分场景Table组件都是分页的，所以不会有性能问题。但是在一个特殊的场景：关键词搜索，可能有200*20个结果，没有分页，而且表格有一列有checkbox，也就是可以选中一些行进行操作。当我们点击其中一行的时候，发现选中它的时间比较长，而且有明显的卡顿感，但是之前的jQuery版本并没有出现这种问题，还是比较意外的。好的技术改造一定要牺牲用户体验吗？由于在Table组件的第一次优化尝试中出现了性能问题，我们首先想到的应该是找出性能问题的原因。列显示优化首先ZoomUI渲染的DOM量比jQuery渲染的Table要多，所以第一个思考的方向就是让Table组件尽量减少DOM渲染量。20列数据通常不能完全显示在屏幕上。老jQueryTable的实现很简单，底部有一个滚动条，ZoomUI在这种可滚动的场景下支持固定左右两列，这样在左右滑动的时候，可以固定一些列为一直显示，用户体验更好，但这种实现有一定的代价。ElementUI要实现这种固定列的布局，是使用了6个table标签来实现的，那么为什么我们需要6个table标签呢？首先，为了让Table组件支持丰富的表头功能，表头和表体分别实现了一个table标签。所以对于一个表格，会有2个表格标签，再加上左边的固定表格和右边的固定表格，一共有6个表格标签。在ElementUI的实现中，左边的fixedtable和右边的fixedtable从DOM中渲染出完整的column，然后通过style来控制它们的外观和隐藏：但是这种实现是比较浪费性能的，因为没有需要渲染那么多Column，其实只需要渲染固定显示的column的DOM，然后做好高层同步即可。ZoomUI就是这样实现的，效果如下：当然，仅仅通过减少固定表格渲染的列，性能提升还不够明显。有什么办法可以继续优化柱状渲染的维度？这是从业务层面的优化。对于一个20列的表，往往关键列并不多，那么我们是否可以只渲染关键列进行第一次渲染，其他列通过配置来渲染呢？根据以上需求，我在Table组件中添加了如下功能：Table组件添加了一个initDisplayedColumn属性，通过该属性可以配置首次渲染的列，当用户修改了首次渲染的列时，会保存在前端，供下次渲染使用。这样，我们可以渲染更少的列。显然，如果要渲染的列少了，整个表格渲染的DOM数量就会减少，这也会在一定程度上提高性能。更新渲染优化当然，仅仅优化列的渲染是不够的。我们遇到的问题是，当点击某一行时，渲染卡住了。为什么会导致冻结？为了定位问题，我使用Table组件创建了一个1000*7的表格，打开Chrome的Performance面板，记录下checkbox被点击前后的性能。点击几个checkbox选择框后，可以看到如下火焰图：黄色部分是Scripting脚本的执行时间，紫色部分是Rendering占用的时间。我们再截取更新过程：然后观察JS脚本执行的CallTree，发现时间主要花在了Table组件的更新渲染上：我们发现组件渲染到vnode的时间大概是600ms;vnodepatchtoDOM花费的时间大约160ms。为什么需要这么长时间？因为checkbox被选中，其维护的选中状态数据在组件内部被修改，这个状态数据在整个组件的render过程中被访问。因此，当数据被修改时，整个组件的重新渲染。并且因为有1000*7条数据，整个表需要循环1000*7次才能创建最里面的td，整个过程时间会比较长。那么循环内部还有优化的空间吗？对于ElementUI的Table组件，还有很大的优化空间。其实优化思路主要参考了我之前写的《揭秘 Vue.js 九个性能优化技巧》里面的Localvariables技巧。比如在ElementUI的Table组件中，在渲染每一个td的时候，有这样一段代码：constdata={store:this.store,_self:this.context||this.table.$vnode.context,column：columnData,row,$index}相信很多小伙伴都是随意写代码，却忽略了内部潜在的性能问题。由于Vue.js响应式系统的设计，每次访问this.store时，都会触发响应式数据内部的getter函数执行其依赖收集。当这段代码循环1000*7次时，this.store的依赖收集会被执行7000次，造成性能上的浪费，真正的依赖收集只需要执行一次。解决这个问题其实并不难。由于Table组件中的TableBody组件是用render函数写的，所以我们可以在组件render函数的入口定义一些局部变量：render(h){const{store/*...*/}=thisconstcontext=this.context||this.table.$vnode.context}然后在渲染整个render的过程中，将局部变量作为内部函数的参数传入，从而在内部的渲染中再次渲染renderingtd访问这些变量不会触发依赖收集：rowRender({store,context,/*...othervariables*/}){constdata={store:store,_self:context,column:columnData,row,$index,disableTransition,isSelectedRow}}这样，我们修改了类似的代码，实现了在TableBody组件的渲染函数内部访问这些响应变量，并且只触发一次依赖收集的效果，从而优化了render的性能。看一下优化后的火焰图：从面积上看，好像是减少了Scripting的执行时间。我们来看一次更新所需的JS执行时间：我们发现组件渲染到vnode大约需要240ms；vnodepatch到DOM花费的时间大约是127ms。可以看出，ZoomUITable组件的渲染时间和更新时间明显少于ElementUI的Table组件。渲染时间的减少是由于响应式变量依赖收集的时间大大减少，而更新时间的减少是由于固定表渲染的DOM数量减少。从用户的角度来看，除了脚本时间，DOM更新还有渲染时间。他们共享一个线程。当然，由于ZoomUITable组件渲染的DOM较少，渲染时间也较短。手写的benchmark不是一个特别准确的benchmark，单从performancepanel测试来看，我们可以给Table组件写一个benchmark。我们可以先创建一个按钮来模拟Table组件的选择操作：