我宣布,这是使用起来毫无心智负担(甚至最好)的滚动虚拟列表,免费自取

大佬nb,如果方便的话,大佬可以补充个pageview那种吗,我总感觉使用pageview组件dc很高,但又不知道应该怎样优化

3.8.7的sorting2d应该是够用了吧

是的,我目前就是用的sorting2d,就是想看看大佬还有没有其他优化方案或者好的写法

image 大佬加下长按功能了 不然每次更新都得更改下 :rofl:

给你开github 编辑,给我你的github账号

sorting2d + mask 已经是很粗暴很好用了. 11212

ok,谢谢大佬

已加入, 已更新.

子节点自身或里面如果注册了触摸事件,滚动列表的事件会被吞噬吧.导致触摸这个子节点没办法滚动列表.
改成官方写的滚动列表在捕获阶段注册事件是不是更好:this.node.on(Node.EventType.TOUCH_START, this._onDown, this)…
这四个触摸事件改成:this.node.on(Node.EventType.TOUCH_START, this._onDown, this,true)…
还有另一个问题,就是目前给列表中的子项触摸事件,如果按住,稍微移动一下,再释放,这时候就不会触发子项的点击事件了.正常来说只要不移动超出这个子项的范围,点击事件还应该继续触发.至少官方的滚动列表添加了带按钮功能子项是能够触发的.
这样导致的后果,就是玩家点击按钮,如果不小心移动了一点,导致按钮事件没触发,会觉得是按钮失灵了.
更简单的做法,或许是直接将官方的Button添加到列表的子项的组件当中去。
比如,判断这个子项有没有添加button组件,有的话直接在clickEvents中多添加一项就好了,没有的话,就按照默认的配置去给这个子项添加一个button组件.这样做另一个好处,是玩家可以自行根据button来定义点击的行为.

sorting2d + mask 已经是很暴力很好用了. :wink: :wink: :wink:

挺好,有需求自己改。这都是额外自定义需求了。

赞一个支持吧,我用的虚拟列表还是最早的那个网上的版本。

可以来个:infinity:循环的pageview嘛? :crazy_face:

2赞

来不了了 。你要加入这个仓库的贡献者吗,提供你的账号就行。

赞赞,我要下载学习了

我用的时候有点小问题。

  1. 正常配置的情况下,我添加的 item (就是通过【子项预制体】制定的prefab)挂在content节点(图中红色方块是content节点的包围盒)上时, item的位置是从content的中心位置开始往下排布的,就导致列表的上半部分是空的,下半部分反而超出了content的范围

  2. 为了解决这个问题,我尝试把content节点的anchorY 设为1,结果item和content定位框能够正确的对齐了(但是看起来content的高度比所有item高度之和还要高,我没有设置尾部间距)。但是content和scrollView本体(蓝色方块)对不齐了。当然这也是符合预期的,因为anchorY改变了但是y没变所以就会这样。

  3. 最终通过把content的anchorY和scrollView的anchorY都设为1,就能保证content的子节点(item)和content对齐、content也和scrollView对齐了。

想问下为什么会这样啊?我不是问实现原理,是说为什么设计成item从content节点的中心位置开始往下排布,而不是从top开始往下排呢?还是说我使用的有问题?

=======后续======
我看了下你给的sample,发现示例里也是按照我摸索出来的第3步来做的:把scrollView所在的节点和content节点的anchorY 都设为1. 看来你设计的就是这么来用的。
为什么要做成这样呢?

还有一个问题
【行/列数】这个属性到底有什么用啊,我感觉这个值不能影响最终一屏出现几个item,而是由ScrollView所在的节点的高度决定能出几个item

==========
好吧,研究了一下弄明白了,原来这个行/列数并不是指的一屏上出多少行/列,一屏出多少行确实是由scrollView节点的高度决定的
这个指的是网格模式, 如果主方向是纵向的,这个值代表一行拆分多少横向的格子。感觉这个名字多少有点误导了。。。

另外“速度窗口”这是个啥概念,能控制啥?

-0-
1:因为没有单独去实现一套布局模块,所以为了简便,content直接作为容器利用节点的锚点机制就可以很方便进行这种通用的布局.
2:你做的时候出现第一问题就要去对比案例的设置.

现在这个时代,你左手有源码,右手有AI…剩下的…

如果list用了wiget,高度会动态变化,这种情况viewsize会存在计算偏差,目前我这边监听了node的尺寸变化,变化之后重新计算viewsize并且刷新列表