完整长列表的渲染优化

1 .不做优化的情况下，耗时是怎样滴呢？
2 .https://zhuanlan.zhihu.com/p/26022258
3 .结论就是，不同的插入DOM方法，只有innerHtml会有10%的优势，也就是说性能瓶颈不在调用DOM API的阶段，无论使用哪种DOM API添加元素，性能几乎都差不多。
4 .大致就是1w个阶段需要500ms，如果一个列表选项至多有20个节点，那么就是500ms可以渲染500个左右的列表项
5 .综合对性能的要求，我们可以算出来第一次最大加载的数量。也就是说，一次性加载时肯定不能满足我们的需要的，他是有一个最大值的

非完整渲染长列表

1 .方法1 懒渲染：每次之渲染一部分，剩余部分等滚动到可见区域就在渲染另一部分

1 .这个比较符合加载数据的方式，就是一个websocket连接不停的接收数据
2 .

2 .方法2 可视区域渲染：只渲染可见部分，不可见部分不渲染

1 .只渲染可见区域，非可见区域完全不渲染，在滚动条滚动的时候动态更新列表项
2 .适合场景：每个数据的展现形式需要高度一致
3 .一次加载的数据量比较大1000+
4 .产品设计上，滚动条需要挂载在一个固定的区域

3 .针对自己的进行优化，主要是一次显示的数据

1 .现在默认显示的数据是最小元素的高度和显示宽度算的8个，也就是如果现在的8个元素有一个是文字是大于两行显示的，那么就会出现多渲染一个元素问题。
2 .所以可以根据每次算的高度来计算当前显示的count数目，动态调整
3 .不过这个最多也就是多显示3个或者4个元素，不知道是不是没有必要