关于列表性能分析与标准-优快云博客

尽量少用table布局，使用table布局的话，每次有单元格布局改变，都会进行整个tabel的回流重绘；
最好别频繁去操作DOM节点，把需要操作的样式，提前写成class，之后需要修改，只需要修改一次，并且直接修改className，做成一次性更新多条css DOM属性，一次回流重绘总比多次回流重绘要付出的成本低得多；
动画实现速度的选择，动画速度越快，回流次数越多，也可以选择使用 requestAnimationFrame；
每次访问DOM的偏移量属性的时候，例如获取一个元素的scrollTop、scrollLeft、scrollWidth、offsetTop、offsetLeft、offsetWidth、offsetHeight之类的属性，浏览器为了保证值的正确也会回流取得最新的值，所以如果你要多次操作，最好取完做个缓存；更加不要通过for循环中访问DOM偏移量属性，而且使用的时候，最好定义一个变量，把要需要的值赋值进去，进行值缓存，把回流重绘的次数减少。

主要核心点就是减少DOM操作和DOM数量。

列表真实场景

我们打开以上连接的列表，会发现卡顿现象比较严重

这个时候使用performace进行分析

performace使用工具

ctrl+e后，在页面中操作一下，然后点击关闭

然后会看到操作过程的性能分析，可以看到有一段一段的红色进度条，出现红色的进度条说明操作过程，是超出长任务（大于50ms）的，一般出现这种是频繁的操作了DOM元素，触发了浏览器的layout，也会是js的宏微任务运行过多导致。

点击任意一个红色的长任务条，选择事件日志

这个时候我们发现这个长任务耗时173.6ms，而这个v-lazy方法就全占满了，当放大图片后可以清晰看到：

这个操作已经强制了浏览器的重排，在得出了一个结论，v-lazy影响我们列表滚动的速度。

接着点击下一个红色任务条：

由于列表是采用虚拟列表的形式，导致内部是动态计算startIndex和endIndex，然后再去更新组件，从而去触发了vue中flushSchedulerQueue异步更新的方法，导致微任务暴增，从而使得长任务变红。在这里我们又得出了一个结论：把现有列表的虚拟滚动给去掉。同时下面还有一个updateStyle的方法，这是列表中更新样式的方法，通过源码解读可以发现，在内部处理了空白区域的高度和top，这个方法是在开启了虚拟滚动才会调用的，所以更加坚定了干掉虚拟滚动的想法。剩下的红色任务条也同理了。