问题描述
列表 (list) 是浏览器端用户交互的常见元素。一般的 select 由两个部分组成：外层的容器和内层的 list，外层的大小固定，通过滑动来调整可视列表的范围。
单页面应用（SPA）的设计理念中有一句话，视图是数据的映射。在实际生产项目中，当数据量开始凶猛增长的时候，一些性能问题就会开始出现。比如当一个选择列表的数据过多时候，更新 DOM 需要消耗更长的时间，此时用户操作会明显感到卡顿。
假设我们要渲染下面这个简单的列表 ( React 实现 )：
<div style={{ height: '200px', overflow: 'scroll' }}>
{
data.map((item) => {
return (
<div key={item}>{item}</div>
);
})
}
</div>
其中 data 是简单的数字数组，如：[1, 2, 3 ...]。
在本地测试，当 data 里面装有 100 个元素的时候，渲染这个列表只需要几个毫秒，而渲染 10000 个元素的时候需要几百毫秒。这个例子里面的元素非常简单，在实际情况中，渲染更复杂的元素，或者当用户端设备性能更差的时候，会消耗更多的时间。同时，从 DOM 中删除这个列表（比如关闭选择组件操作），也会花费一些时间。
可以看到，渲染列表的时间和元素的数量成线性关系，当数据量很大的时候，用户可以很明显地感知到卡顿。
优化手段
面对这个问题，虚拟列表是一个有效的设计思路。即永远只渲染当前用户可见，以及其前后的几个元素。监听滑动事件 (scroll event)，在滑动的时候调整当前窗口的可见元素，并渲染出来。这样可以大大节约插入和移除大量 DOM 元素的时间，可以大大加快初次渲染时间，而且渲染时间不随着数据量增加而增加。
react-window 是一个非常好用的 React 虚拟列表组件库。使用方法在文档和 demo 里面已经很详细地描述了。
该库采用了以下几点优化：
- 如前面所述，只渲染当前可视以及前后若干个元素。最外层容器采用 relative 定位，内部元素使用 absolute 定位，并计算该定位的 offset，比如：第一个元素的 top 距离应该是 itemSize * index，如果列表是垂直方向排列的，那么 itemSize 就是单个元素的高度。
- 懒计算和缓存。因为每个元素的 offset 都是不同的，需要专门计算出来。如果一次性把所有列表元素的 offset 都计算出来，那么也会占用 O(n) 的时间。所以只在每次渲染可见元素之前计算 offset，也就是懒计算。同时利用了缓存来避免重复计算，如果一个元素先被从视窗移除再重新加载，即来回滑动列表，那么这个计算结构是可以直接从缓存中取出的。
- 使用纯组件（pure component）来避免重渲染。
最后是一个小设计，列表容器可以传入一个属性 isScrolling 告诉列表元素目前是否正在滑动。开始滑动 (on scroll) 的时候改变滑动状态为正在滑动，而结束滑动的时候会稍微等一段时间 (interval)，才确定滑动停止。对这个滑动状态的更新函数有进行 debounce 处理，只有最后停止滑动一段时间才更新滑动状态为已停止，这样可以避免子元素的不必要渲染，如果子元素在滑动的时候会重绘的话。
网友评论