背景团队目前的Web端产品中需要显示两个列表视图：卡片列表和条目列表，并且在点击切换按钮的时候，对两个列表进行切换显示。在开发完成进行简单性能测试时，发现列表数量达到数百条后，切换视图就会造成明显的页面卡顿，用户体验很差。于是着手进行性能优化。第一次优化：解决已知问题由于项目是使用Vue.js（以下简称"Vue"）来实现，所以首先查看Vue是否存在性能瓶颈，如果存在则考虑替换Vue进行优化。通过查看官方给出的benchmark结果，我们可以得知Vue的列表渲染性能在高亮和交换列表元素的时候新能较差，在创建列表和新增列表元素的时候性能都是不错的，执行时间在毫秒级别。既然Vue并没有给我们制定太低的性能天花板，那么我们可以在使用Vue的基础上继续进行性能优化。再来看看代码，点击切换的时候到底发生了什么。点击事件触发后会引起组件属性cViewType变化，然后两个视图的列表会根据cViewType的值进行渲染。部分代码如下：

sectionclass="file-card-list"v-if="cViewType==card"....../sectionsectionclass="file-line-list"v-if="cViewType==line"....../section

这里通过v-if指令来实现列表切换，每次切换时都会销毁之前的视图列表，然后创建一个新的视图列表。在列表元素非常多时，会造成大量的DOM元素创建和销毁，性能开销是很昂贵的。所以进行优化的最简单方式就是缓存已经渲染的列表。对应到代码也很简单，就是将v-if改为v-show，这样就可以通过CSS来控制两个列表的显示/隐藏，从而避免DOM元素的重复创建。改动之后效果确实也非常明显，事情似乎到此结束，但如果列表数量增加到一两个数量级，比如到达一万，是否仍旧流畅呢？第二次优化：排查可能的问题当我将列表元素数量增加到一万之后，卡顿问题果然再次出现了。而浏览器页面卡顿无外乎两个原因，要么脚本引擎在执行js代码，要么渲染引擎在渲染页面。由于前面已经对脚本引擎执行js代码的问题进行过优化，这一次我们将优化方向转向渲染引擎。渲染引擎程序需要借助CPU来执行渲染操作，而CPU本身并不擅长于处理批量图形渲染，所以可以把这部分的渲染工作交给GPU。通过设置CSS样式就可以调用GPU，下面是一种实现方式。首先将两个视图列表都设置为绝对定位，脱离文档流。然后在点击事件中动态修改视图列表的z-index属性，控制两个列表的层叠关系，通过让一个列表覆盖另一个列表来实现显示/隐藏效果。这里需要注意的是，虽然只要让卡片列表脱离文档流就可以达到效果，但由于条目列表高度超过卡片列表，导致在显示卡片列表时底部仍然出现条目列表元素，所以将两个元素都设置为绝对定位，并且让其拥有各自独立的滚动条。优化之后，万张图片可以实现毫秒级切换，非常顺滑。第三次优化：思考方案的副作用世上没有银弹，即使借用GPU来加速渲染仍会产生一些副作用。由于GPU对渲染图形数量不敏感而对渲染次数敏感，而浏览器对请求的并发数（一次并发8~6个请求）又有限制，这在一定程度上会增加GPU的渲染次数，从而影响用户体验。对于这个问题可以通过HTTP/协议提升并发能力或者采用分批预加载的方式（等一批图片资源都预加载完再更新到卡片列表）。由于这些方案还没有来得及实践，这里就不具体展开了~总结针对不同性能问题的场景，优化的手段很多，总体上我们只需要抓住两条线索就能找到合适的解决方案，分别是：做减法和做除法。做减法就是直接减少操作步骤或资源大小，比如第一次优化中通过v-show来进行缓存，就是减少创建列表的操作。做除法就是对耗时的操作进行拆分。比如第二次优化中，耗时的渲染操作转交给GPU来执行。更多精彩识别