> 本文是关于超长列表渲染性能优化的学习笔记，这里做个总结与分享，有不足之处还望斧正\~ 长列表的优化策略主要有两种： * 分片渲染（通过浏览器事件环机制，也就是 EventLoop，分割渲染时间） * 虚拟列表（只渲染可视区域）\ 在正式优化前，先介绍一些用得到的基本概念： # 进程与线程进程是系统进行资源分配和调度的一个独立单位，一个进程内包含多个线程。人们常说的 JS 是单线程的，是指 JS 的主进程是单线程的。 ## 渲染进程渲染进程包含以下线程： * GUI 渲染线程（页面渲染） * JS 引擎线程（执行 js 脚本） * 事件触发线程（EventLoop 轮询处理线程） * 事件（onclick）、定时器和 ajax 也会开启独立线程\ 注意，GUI 渲染线程和 JS 引擎线程是互斥的，所谓的 JS 是单线程的，就是指这条共享的主线程。 ### 浏览器中的 EventLoop ![yuque\_diagram.jpg](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/52fed7e3ab8643e885034e6f03e5e36d~tplv-k3u1fbpfcp-watermark.image#?w=1424\&h=835\&s=192362\&e=png\&b=fefefe) # 分片渲染 ## 简单的长列表观察渲染时间我们先写一个有 10000 条简单数据的列表，并打印时间，注意，这个时间是 js 语句执行的时间，而不是浏览器渲染的时间。 ```html

``` 为了获得浏览器的渲染时间，根据上面的 EventLoop 可知，每次 GUI 渲染完都会执行一个宏任务，所以我们可以在后面添加一个定时器（宏任务），渲染完成后执行得到渲染时间。 ```js setTimeout(() => { console.log(Date.now() - time) }, 0) // 2800 ``` 效果如下图： ![GIF 2021-6-22 22-21-08.gif](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/53164f7648044f478071d0b54b91d9fe~tplv-k3u1fbpfcp-watermark.image#?w=404\&h=335\&s=76575\&e=gif\&f=17\&b=768288)\ 可以看到，js 执行时间为 160 ms，加上渲染总共用了 2801 ms。在渲染完成前页面一直是空白的加载状态，这是因为新版本的浏览器做了优化，会等待 for 循环执行完毕后再将 dom 节点插入到页面中，避免了频繁的重排和重绘。 ## 进行分片优化 ```js const time = Date.now() /** * index: 记录循环到哪了 * id: 往 li 里添加的内容 */ let index = 0, id = 0 function load() { index += 50 if (index < 10000) { requestAnimationFrame(() => { // 用 requestAnimationFrame（也是宏任务）代替了 setTimeout，性能更好点 const fragment = document.createDocumentFragment() // IE 浏览器需要使用文档碎片，一般可不用 for (let i = 0; i < 50; i++) { const li = document.createElement('li') li.innerText = id++ fragment.appendChild(li) } list.appendChild(fragment) }) load() } } load() console.log(Date.now() - time) setTimeout(() => { console.log(Date.now() - time) }) ``` 因为 [requestAnimationFrame](https://juejin.cn/post/7290083242018390053#heading-13) 或定时器是一个宏任务，所以每执行一次 GUI 渲染后就执行一次相关的回调，也就实现了每次添加 50 个 li 节点，从而达到了分片加载的目的。现在加载时间则如下： ![3.gif](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ededdf69bb4a4513976f9fea1f8befef~tplv-k3u1fbpfcp-watermark.image#?w=354\&h=245\&s=62349\&e=gif\&f=17\&b=768187)\ 与分片加载之前对比，确实快了许多。但这种方案有个问题：会导致页面的 dom 元素过多，依旧容易造成卡顿。解决这个问题，就要用下面介绍的第 2 种优化策略。 # 虚拟列表（只渲染当前可视区域）虚拟列表优化依据列表每一项（item）的高度是否为固定值分为两种情况： ## item 高度固定为了代码的可复用性，我们将封装一个 VirtualList 组件，先放代码（基于 vue 2.6）。 ### 用到长列表组件的页面 App.vue（父组件） ```js // App.vue ``` ### 长列表组件 VirtualList.vue ```js // VirtualList.vue ``` ### 解释说明 * **列表的数据来源是一个长度为 1000 的简单的 list 数组** * **我们的目标是只需要传递 3 个值给 VirtualList 组件，就可以正常使用：** * `size`：每一项的高度 * `keeps`：希望展示几条数据 * `arrayData`：列表数据 * **VirtualList 组件里得有 3 个部分：** * 最外层容器区域。高度固定，超出区域出现滚动条，高度为传入的 `size` 乘上 `keeps`； * 列表本应该有的高度区域，也就是列表如果全部渲染的总高度。因为只渲染 `keeps` 指定的条数的数据，就会导致没有滚动条或滚动条无法起到预告总的列表长度的功能，所以要用一个高度为列表总长度的 div 让滚动条正确显示； * 要展示的内容。展示的数据应该是总数据 `arrayData` 的某一部分。展示的数据 `item` 还得传给父组件，在父组件进行使用，这里就用到了插槽。 * **当滚动列表时（`handleScroll` 触发），我们要及时的根据滚动的距离更新应该显示的数据：** * `onscroll` 处理的是对象内部内容区的滚动事件，所以是对最外部固定高度的 wrap 容器进行监听。 * 如下图所示：蓝色矩形为可视区域，假设传入的 `keeps` 为 3 ，当滚动列表（红色矩形）时，渲染的列表区域，也就是 3 个 `item`（深蓝绿色矩形）占据的区域也会跟着滚动，如果仅仅改变渲染的内容，也就是根据滚动距离从 item1 开始渲染，那么此时这个 item1 就会替换下图的 item0 ，位于可视区域之外，无法被看见。 ![1.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/66276e6410b94fbe95e748dfb86b5d98~tplv-k3u1fbpfcp-watermark.image#?w=553\&h=372\&s=9744\&e=png\&b=e9f7ff) 所以需要根据已经滚动出可视区域的 `item` 的个数和每一项 `item` 的高度的乘积（`offset`）进行反向的移动，移动的距离为 `this.start * this.size`。注意： `offset` 的值在多数情况下不会等于 `scrollTop` 的值。 ![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c61f68be80ac4f44a38cc46c79d90b54~tplv-k3u1fbpfcp-watermark.image#?w=553\&h=372\&s=9655\&e=png\&b=e9f7ff) > 注：一个元素的 scrollTop 值是这个元素的内容顶部到它的视口可见内容（的顶部）的距离的度量。当一个元素的内容没有产生垂直方向的滚动条，那么它的 scrollTop 值为 0。解决滚动时，如果刚好渲染的第一项只显示了部分，那么可视区域的最底下就会出现相应高度的空白的问题，就如下图中，可以看到右侧滚动条的高度超过 23 那一项的区域为空白： ![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/79803740f20c444d973d01b5ef2f2005~tplv-k3u1fbpfcp-watermark.image#?w=500\&h=286\&s=9183\&e=png\&b=fefefe)\ 解决方案为在原先的渲染项数基础上，再多向前和后渲染若干项，那么决定渲染哪些数据的 `visibleData` 的计算就会发生变化，原先是定义了 `start` 和 `end` 用于标记到底切割哪一部分，代码如下： ```js visibleData() { return this.arrayData.slice(this.start, this.end) } ``` 现在则是新定义了 `prevCount`、`renderStart`、`nextCount` 和 `renderEnd` 4 个参数，另外 `offset` 也需要改变为 `(this.start - this.prevCount) * this.size`，因为假设原本渲染 8 项，往上滚动了 1 项的距离，那么渲染的 8 项由 0 \~ 7 变为 1 \~ 8，0 项被删除，这时需要把 `class="visible-wrap"` 的这个 div 往下移动 1 项，才能刚好在可视区域的顶部看到第 1 项；现在则是往上移动 1 项时，`class="visible-wrap"` 这个 div 里渲染的项数就会变为1+8+8=17 项，0 项不会被删除，不需要再往下移动 1 项，所以会有 `this.start - this.prevCount` ## item 高度不固定接下来就是实际项目中更为常见的每一项高度不确定的情况了，还是先放代码： ### App.vue 跟之前 `item` 高度固定的情况相比变化不大，只需用 **mockJS** 随机生成段落文本，模拟每项 `item` 高度不固定的情况： ```js import Mock from 'mockjs' const list = [] for (let i = 0; i < 1000; i++) { list.push({ id: i, value: Mock.Random.cparagraph(5, 10) // 随机生成有 5 ~ 10 个句子的中文段落 }) } ``` 多传给组件一个参数 `variable`，每一项的 style 也做了相应调整： ```html ``` ### VirtualList.vue 先放完整的代码如下（省略了样式部分）： ```js // VirtualList.vue ``` ### 解释说明原来对于列表如果全部渲染应该有的高度的计算 `this.arrayData.length * this.size + 'px'` 显然不合适了，因为每项 `item` 的高度 `size` 不确定了。在开始重新计算之前，先介绍一下二分法： #### 二分法 * **使用前提**：数组已经按升序排列 * **基本原理**：首先将要查找的值（value）同数组中间那一项的值（midValue）进行比较，当 `start <= end`： 1. 如果 `value < midValue`，则 `end = mid - 1`，只需要在数组的前一半元素中继续查找 2. 如果 `value = midValue`，匹配成功，查找结束 3. 如果 `value > midValue`，则 `start = mid + 1`，只需要在数组的后一半元素中继续查找 4. 如果 `while` 循环结束后都没有找到 `value`，返回 `-1` ```js const arr = [-1, 5, 6, 12, ...] const start = 0, end = arr.length -1, mid = start + (end - start) / 2 ``` **注意：** 在二分法中，计算中间项的索引时用的是 mid = start + (end - start) / 2 而不是直接使用更简单的公式 mid = (start + end) / 2，是为了防止值溢出的情况，因为 start + end 的值可能会大于 js 最大的能表示的数。（如果 start < 0 或 end < 0时，end - start 也可能会溢出） #### 利用二分法重新计算 start 1. 在页面加载完毕后，对数据数组里每一项的 `height`, `top` 和 `bottom` 的值做个缓存（此时的 `size` 为我们预估的，滚动条的高度并不准确），存放在数组 `positionListArr` 里； 2. 用二分法开始查找，我们页面滚动的距离 `scrollTop` 对应于 `positionListArr` 里的哪一项的 `bottom` 的值。之所以用二分法是因为后面会根据真实 dom 重行计算每一项的 `height`, `top` 和 `bottom`，到时候每一项的 `size` 就可能不一样了； 3. 之后对于 `end` 和 `offset` 计算原理就跟 `item` 高度固定的情况一样了。 #### 页面更新后页面渲染完成后，获取到真实的 dom，更正缓存在 `positionListArr` 里的数据，实现更新滚动条的高度。这部分代码用到了 `ref` 和 `getBoundingClientRect` 的相关知识： * 如果 `ref` 是写在 `v-for` 的元素或组件的时候，引用信息将是包含 DOM 节点或组件实例的数组。 * `Element.getBoundingClientRect()` 方法返回元素的大小及其相对于视口的位置，除了`width` 和 `height` 以外的属性是相对于视图窗口的左上角来计算的，如下图：\ ![image (1).png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/463e0812237e4c9f9002cbae6d081c7f~tplv-k3u1fbpfcp-watermark.image#?w=439\&h=181\&s=8051\&e=png\&b=ffffff) # 添加节流及效果展示 ## 滚动节流最后，给 `handleScroll` 添加个节流效果，提升性能： 1. 安装 lodash：`npm i --save lodash` 2. 在 VirtualList.vue 引入：`import throttle from 'lodash/throttle'` 3. 使用：新定义 `scrollFn` 方法，替换 `

` 里的 `handleScroll` ## 效果图 ![GIF 2021-6-27 16-06-36.gif](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f7a7f4be504e4d0d86eb91dbed7fece6~tplv-k3u1fbpfcp-watermark.image#?w=841\&h=989\&s=8070606\&e=gif\&f=159\&b=fdfbfa) # One More Thing ## 仅用 css 就搞定长列表渲染的优化最近看到一个新的 css 属性 `content-visibility`，利用这个属性（大概率还得配合 `contain-intrinsic-size`）就可以实现只渲染当前可视窗口区域内的内容，跳过不在屏幕上的内容渲染。但目前兼容性极差，只能说未来可期\~ ![感谢.gif](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d160e26986d1447e8ef2dfe783fc6eb6~tplv-k3u1fbpfcp-watermark.image#?w=1920\&h=1080\&s=1605675\&e=gif\&f=125\&b=3f7b7d)\ ![点赞.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0a7fbbcaca1c480c942b7735a7228e9f~tplv-k3u1fbpfcp-watermark.image#?w=1800\&h=363\&s=230657\&e=png\&b=ffffff)