好奇移动端、桌面端是怎么实现列表控件渲染大量元素不卡顿的?

查看 94|回复 9
作者:rcocco   
网页端是有多少 DOM 元素就渲染多少元素,不管这些元素是不是用户当前视口可见的,所以元素一多就会很卡。每次都要专门把渲染的逻辑写成虚拟滚动来解决这个问题,但用过的一些虚拟滚动库总是有各种各样的限制或小毛病,例如要求元素等高,滚动到底部不对劲等等。
我就很好奇其他端,像移动端和桌面端都是怎么解决这个问题的?搜索 [安卓 虚拟滚动] 还搜不到什么东西
sduoduo233   
安卓是 recyclerview
abcbuzhiming   
移动端我不清楚。但是桌面端的话,我没听说过传统 UI 的列表控件有用虚拟滚动的,实际上,当元素量够大的时候,一样会卡的,只是桌面端大部分时候处于性能溢出的状态,且内存管够,所以一般遇不到那个能让你卡的数量级。
Irisxx   
主要是归功于对象池的重用机制,辅之以 LRU 这些缓存机制优化。
verrickt   
微软的 GUI 框架把相关的技术叫做 UI Virtualization ,有兴趣可以看看
lmw2616   
android 用 recyclerview ,也是类似于虚拟滚动
chiaf   
你搜索 iOS UITableView 应该能搜到😄
很早之前的经典面试题,说一下 UITableView Cell 的复用原理
kemchenj   
其它端不清楚,iOS 端其实就是虚拟滚动,列表会维护一个重用池,把不可见的 cell 塞进去,然后需要展示的时候从里面拿 cell 出来显示,如果发现不够就再补充新的进来
iOS 封装得还行,但也免不了各种限制和小毛病,都是需要开发者额外做一些处理去完善体验,例如预先计算每个元素的高度以便把列表撑开之类的...
感兴趣的话可以搜一下“UITableView 重用”
xiebaiyuan   
回收,重用,缓存
UnluckyNinja   
如果从只渲染可见部分的组件来看,那基本上都可以算作虚拟滚动(否则就是加硬件了)
你用的库总是有各种各样的不完美,可能是因为复杂度难以实现/怕导致库臃肿(所以固定高度),或者虚拟高度计算不正确。
根本原因在于虚拟高度需要根据内部组件的实际大小调整以正确计算滚动位置。
你看像 twitter 也是虚拟滚动,但你要是快速拉到中间再缓慢向上拉,会发现 twitter 的滚动条也在闪,(猜测)这就是在修正假定的未渲染元素的高度到渲染完后实际高度,并相应调整总高度。
如果你是想写前端的一个虚拟滚动组件,可以参考 VueUse 推荐的这个独立虚拟滚动组件 https://vue-virtual-scroller-demo.netlify.app/dynamic
您需要登录后才可以回帖 登录 | 立即注册

返回顶部