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

查看 181|回复 13
作者:Kinnikuman   
上一个问题( /t/1059281 )我看已经讨论结束了,所以新开一个帖子来讨论下。
我的问题是,大量的列表会导致滑动卡顿吗?移动端有"回收,重用,缓存"这种策略,但如果不使用这种策略,而将大量的列表数据加载到内存中,滑动时候会卡顿吗?
我的理解是它们已经加载到内存中了,滑动只是将其展示出来,缺点是占用内存特别大。
如果使用了回收策略,只有屏幕展示的那几条列表会被加载到内存中,滑动出去的放到复用列表中,以供下次使用,这样可以节约大量内存,但在快速滚动刷新的列表中,这需要 cpu 进行大量的计算来刷新列表中的数据吧?
所以我觉得,如果不使用回收策略,那么 cpu 会在第一时间创建很多列表数据,这会导致一开始卡顿,创建完数据后,占用很大内存。但之后的刷新,不应该卡顿。
如果使用回收策略,内存压力小了,开始不需要进行大量的 cpu 计算,所以不会有开始渲染卡顿问题。但后面的快速刷新会消耗 cpu 。
大家都在讲渲染的问题。渲染不是系统框架做的工作吗?程序能够控制的,是配合这些框架来优化性能,比如使用某个快速的算法来计算每一个列表的高度,或者是固定高度,或者是简单的计算高度。
所以我的问题再优化下,对于回收策略来讲,复杂的列表,在快速滑动情况下,这样的 cpu 工作(将数据分配到可复用的列表中)也是很轻松的,已经没有可优化的空间了。对吗?
LuckyLauncher   
大家都在讲渲染的问题。渲染不是系统框架做的工作吗?程序能够控制的,是配合这些框架来优化性能,比如使用某个快速的算法来计算每一个列表的高度,或者是固定高度,或者是简单的计算高度。
所以我的问题再优化下,对于回收策略来讲,复杂的列表,在快速滑动情况下,这样的 cpu 工作(将数据分配到可复用的列表中)也是很轻松的,已经没有可优化的空间了。对吗?
jones2000   
数据是数据,展示出来是“绘制”这个动作
你把你的手机屏幕上展示的东西想象成一张静态的图,你滑动的时候这张图是被实时绘制出来的,不管数据在哪,要渲染的组件有没有创建(哪怕是已经创建了但是给隐藏了),“绘制”这个动作是跑不了的
你可以用 canvas 之类的自己写一个列表看看
IvanLi127   
虚拟表格不需要把所有数据都加载到内存, 只加载一个索引序号就可以了,滚到到哪里就请求哪一屏的数据。就算存在内存里面, 能用多少内存, 比起创建 10W 个 DOM 占用的内存,100W 条数据内存就小多了。
RightHand   
CPU: 谢谢你
GPU: 我谢谢你
weixind   
单纯数据其实还好,绘制才是卡的大头。
iOCZS   
这个场景的瓶颈首先是在渲染,而不是数据源。有定论的知识点,有啥可讨论的。
Kinnikuman
OP
  
绘制的消耗是必然存在的,在绘制间隙的 CPU 时间片可以用于计算,这是合理的,CPU 闲着也是闲着。
不使用回收策略,那么 cpu 会在第一时间创建很多列表数据。这个有待商榷,一般是分页获取数据,因此内存消耗是累计的,CPU 未必存在一开始就卡的问题。
Kinnikuman
OP
  
@LuckyLauncher
@RightHand
绘制是另一个问题了,有专门的硬件处理。
所以,我的问题有问题是吗?相对于绘制来讲,那些 cpu 计算复杂的列表如何更换数据,都是很 easy 的计算?
Chuckle   
@iOCZS "CPU 闲着也是闲着",不这么认为,能让 cpu 少工作,也算是性能优化的一部分吧。当然这个话题中是舍弃掉内存来换取 cpu 的部分工作。而且这个讨论不考虑分页获取数据,就是一个几万几十万条的数据一次性加载到 list 中。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部