关于"好奇移动端、桌面端是怎么实现列表控件渲染大量元素不卡顿的？"引申的问题

[Kinnikuman]

上一个问题( https://www.v2ex.com/t/1059281 )我看已经讨论结束了，所以新开一个帖子来讨论下。

我的问题是，大量的列表会导致滑动卡顿吗？移动端有"回收，重用，缓存"这种策略，但如果不使用这种策略，而将大量的列表数据加载到内存中，滑动时候会卡顿吗？

我的理解是它们已经加载到内存中了，滑动只是将其展示出来，缺点是占用内存特别大。

如果使用了回收策略，只有屏幕展示的那几条列表会被加载到内存中，滑动出去的放到复用列表中，以供下次使用，这样可以节约大量内存，但在快速滚动刷新的列表中，这需要 cpu 进行大量的计算来刷新列表中的数据吧？

所以我觉得，如果不使用回收策略，那么 cpu 会在第一时间创建很多列表数据，这会导致一开始卡顿，创建完数据后，占用很大内存。但之后的刷新，不应该卡顿。

如果使用回收策略，内存压力小了，开始不需要进行大量的 cpu 计算，所以不会有开始渲染卡顿问题。但后面的快速刷新会消耗 cpu 。

[mcluyu]

不触发离屏渲染的前提下， 渲染问题解决了， 但是上面提到了，即便是不停的判断元素在不在屏幕范围内也是不小的开销

[superkeke]

移动端性能优化，早年面试必谈的问题，这个点就太多了，能做的点也很多。数据重用、异步绘制、布局优化、预加载，还可以涉及到操作系统层面，太多了。

[Chuckle]

@crz 原生的滚动条确实应该隐藏掉，要的话应该再写个虚拟滚动条，小红书也是把滚动条隐藏了，demo 不直接展示 2000 条，也是因为实时计算是找最小高度的列，以其为基准，所以肯定是少于 2000 条的，确保体验，不然有些列长度太短了，留白难看，因为是不定高，所以每次加入元素只能找最短列，但不知道当前加入的元素实际高度。

[Chuckle]

@DOLLOR 主要还是小红书、抖音这种无限往下滑动的场景，快速找到并滚动到最后一次看的视频也是个算法题（

[iapplebear]

@Chuckle 请教下你这个能处理带日期分类的那个虚拟滚动吗？ 1 行是某天日期下一行是该天所有的照片，照片是横向排列的一行摆不下就自动换行

[Chuckle]

@iapplebear 每个列表元素的 dom 结构可以通过插槽自定义，你可以通过二维数组实现这个功能，外面是一层不定高虚拟列表，用于区分每一天，然后每个元素里面又是一个不定高虚拟瀑布流来展示该天的所有照片，通过这样嵌套两层虚拟列表，应该可以满足你的需求。

[Chuckle]

@iapplebear 不过这毕竟只是个 demo ，我感觉嵌套起来用应该会有些问题，性能上或者是布局计算上

[ko1haha]

虚表控件十分重要，尤其是移动设备上，重要程度仅次于 webview 。不像 PC 你可以仗着电脑性能好随便写。

怎么分页也是一种策略，包括界面和数据的分页。

有的分页，需要手动翻页。有的虽然不需要，但是加载分页的速度很慢。。


c++虚表也不难，但是优化比较难。（我就写过，模仿安卓的 ListView 扩展 duilib ，几百行代码，就把这些试了一遍：item 不同高度，按行滚动 vs 按像素滚动，平滑滚动动画）

体验最好的当数浏览器。然而浏览器其实也没有原生的虚表控件，需要用库或者自己写。

小红书网站确实是虚表，然而那体验实在太差了，和抖音不能比。

> @Chuckle 快速找到并滚动到最后一次看的视频也是个算法题

p 的算法题，主页视频就算千万个，直接 for 循环查找下去也是很快的，不要低估 CPU 的运行速度。（我就写过用户脚本，把小红书变成抖音模式，近似）

---

基于浏览器做个文件管理器，取代老古董 explorer：就类似书签管理器的那套分页 UI ，运用到文件管理里，加载图片也是可以的。直接复用框选多选等逻辑了，爽。

浏览器最棒的是 css ，可以各种粉饰，轻松转换网格和列表布局。

说一下我的分页方法：先分块，再分页

分三个块，滚动到末尾的时候，搬动块。

每个块又分十个页面，每个页面管 30 行。约定一个最小行高度，视口外的页面不含 dom 元素，只有一个最小的高度。然后滚动的时候，触发 bind 函数，渲染视口内的页面。

瑕疵：1. 原生滚动条的位置不准。2. 网格模式下，会有空缺。

优点：1. 降低渲染压力。2. 恢复列表位置

[iapplebear]

@Chuckle 谢谢，不过我这边是 React ，还有个难点是要支持浏览器 resize 之后重排，照片的比例不变宽高是动态变化的