飞道的博客

万张图片,流畅体验——记一次 Vue 列表渲染

436人阅读  评论(0)

简介: ### 背景 团队目前的Web端产品中需要显示两个列表视图:卡片列表和条目列表,并且在点击切换按钮的时候,对两个列表进行切换显示。 ![条目列表](https://ata2-img.oss-cn-zh
背景
团队目前的Web端产品中需要显示两个列表视图:卡片列表和条目列表,并且在点击切换按钮的时候,对两个列表进行切换显示。

在开发完成进行简单性能测试时,发现列表数量达到数百条后,切换视图就会造成明显的页面卡顿,用户体验很差。于是着手进行性能优化。

第一次优化:解决已知问题
由于项目是使用 Vue.js (以下简称 “Vue”)来实现,所以首先查看 Vue 是否存在性能瓶颈,如果存在则考虑替换 Vue 进行优化。

通过查看官方给出的benchmark结果,我们可以得知 Vue 的列表渲染性能在高亮和交换列表元素的时候新能较差,在创建列表和新增列表元素的时候性能都是不错的,执行时间在毫秒级别。

既然 Vue 并没有给我们制定太低的性能天花板,那么我们可以在使用 Vue 的基础上继续进行性能优化。

再来看看代码,点击切换的时候到底发生了什么。

点击事件触发后会引起组件属性 cViewType 变化,然后两个视图的列表会根据 cViewType 的值进行渲染。部分代码如下:

......
......
这里通过 v-if 指令来实现列表切换,每次切换时都会销毁之前的视图列表,然后创建一个新的视图列表。在列表元素非常多时,会造成大量的 DOM 元素创建和销毁,性能开销是很昂贵的。

所以进行优化的最简单方式就是缓存已经渲染的列表。对应到代码也很简单,就是将 v-if 改为 v-show,这样就可以通过 CSS 来控制两个列表的显示/隐藏,从而避免 DOM 元素的重复创建。

改动之后效果确实也非常明显,事情似乎到此结束,但如果列表数量增加到一两个数量级,比如到达一万,是否仍旧流畅呢?

第二次优化:排查可能的问题
当我将列表元素数量增加到一万之后,卡顿问题果然再次出现了。

而浏览器页面卡顿无外乎两个原因,要么脚本引擎在执行 js 代码,要么渲染引擎在渲染页面。

由于前面已经对脚本引擎执行 js 代码的问题进行过优化,这一次我们将优化方向转向渲染引擎。

渲染引擎程序需要借助 CPU 来执行渲染操作,而 CPU 本身并不擅长于处理批量图形渲染,所以可以把这部分的渲染工作交给 GPU。

通过设置 CSS 样式就可以调用 GPU,下面是一种实现方式。

首先将两个视图列表都设置为绝对定位,脱离文档流。
然后在点击事件中动态修改视图列表的 z-index 属性,控制两个列表的层叠关系,通过让一个列表覆盖另一个列表来实现显示/隐藏效果。
这里需要注意的是,虽然只要让卡片列表脱离文档流就可以达到效果,但由于条目列表高度超过卡片列表,导致在显示卡片列表时底部仍然出现条目列表元素,所以将两个元素都设置为绝对定位,并且让其拥有各自独立的滚动条。

优化之后,万张图片可以实现毫秒级切换,非常顺滑。

第三次优化:思考方案的副作用
世上没有银弹,即使借用GPU来加速渲染仍会产生一些副作用。

由于 GPU 对渲染图形数量不敏感而对渲染次数敏感,而浏览器对请求的并发数(一次并发8~6个请求)又有限制,这在一定程度上会增加 GPU 的渲染次数,从而影响用户体验。

对于这个问题可以通过 HTTP/2 协议提升并发能力或者采用分批预加载的方式(等一批图片资源都预加载完再更新到卡片列表)。

由于这些方案还没有来得及实践,这里就不具体展开了~

总结
针对不同性能问题的场景,优化的手段很多,总体上我们只需要抓住两条线索就能找到合适的解决方案,分别是:做减法和做除法。

做减法就是直接减少操作步骤或资源大小,比如第一次优化中通过 v-show 来进行缓存,就是减少创建列表的操作。
做除法就是对耗时的操作进行拆分。比如第二次优化中,耗时的渲染操作转交给 GPU 来执行。
原文链接
本文为阿里云原创内容,未经允许不得转载。


转载:https://blog.csdn.net/yunqiinsight/article/details/111310934
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场