- item 数量不够多
- this.node.scroll_view.content.parent 尺寸错误
感谢，我用力拉出屏幕dc可以下降，回弹回来又恢复了，数量刚好超出屏幕80多个像素吧
mark一下
有个疑问啊，难道滚动子控件的循环利用 不会比你这种方法好吗？例如 可视区域内最多显示8个item ，我用10个item 通过修改位置 数据刷新的方式 达到和tableview一样的效果，这种方式不会更好吗 ？，你这样隐藏显示的 实际上还是创建了，我有100条数据，难道就一定要创建100个item？
不过你这种检测碰撞思路是很好的 点个赞
当你项目已经开发完了，发现很多列表都需要替换成自定义循环列表组件，那你就会发现工程量的巨大，这个可以在不影响项目原本代码的情况下使用
这个可以使用【循环列表+item分层】实现，如果是新项目，你这个item节点可以优化到6，7个，drawcall也能降低到10个左右
使用碰撞优化的代价只需要添加组件，循环列表和分层呢
分层修改源码就好了，连组件都不用添加。循环列表的话可能要做一下封装，只不过我这是针对新项目来说的，如果只是对老项目来说的话，你这个优化方案确实不错
渲染分层
- 修改源码不管渲染前后次序？
- 每个 creator 版本都能通用？
循环列表
- 需要按照规定添加组件，配置属性，固定代码使用
- 那种几千行代码的出现问题排查困难
- 横竖网格支持不好
适用方向不一样，前面我早就说过了
1赞
总的来说，个人推荐
新项目
- 横竖网格列表
- 循环列表
- bmfont 加图集
- 无方向限制拖动列表：使用碰撞列表
- 快速开发：使用碰撞列表
老项目
- 快速优化：使用碰撞列表
- 慢慢迭代：
- 循环列表
- bmfont 加图集
在 creator 没有将修改渲染次序的 api 放在用户层的时候，不建议使用渲染分层，因为可能一个版本一个接口，对于商业项目是硬伤
追求极限 dc 的，可以去商店买插件将 label 和 texture 合批
mark一下
实际上，这个draw call优化，可到1
实际开发过程中特别是移动端不可能同时打开很多的UI界面，而且大家似乎过分在意drawcall了，使用循环列表在+延迟加载效果我相信可以满足绝大多数的使用场景了
可以，你用一个正方形头像，用系统默认字体资源，不依赖商城的插件，可以做个帖子效果图的 demo 吗？
希望各位不要口嗨哈，如果各位要口嗨，请拿出成品来打脸，用正方形头像，默认字体，做个效果图的 demo，不要依靠商店里面的label texture合批插件
1赞
还可以优化一下，这部分可以放到循环前
let rect1_o = this._get_bounding_box_to_world(this.node.scroll_view.content.parent);
rect1_o.width += rect1_o.width * 0.5;
rect1_o.height += rect1_o.height * 0.5;
rect1_o.x -= rect1_o.width * 0.25;
rect1_o.y -= rect1_o.height * 0.25;
1赞
3.6.x 好像失效了，Opacity 属性对drawcall 无效了？？？
+1十分认同
看你的逻辑，我在你的基础上 做了另外一个操作，透明度设置这个是一个操作 ，等于将屏幕外部的node 隐藏， 在这个基础 可以对 listview 上面的item 进行 二次拆分， 比如 你的item 上面分别对应的是
【文本1 头像1 文本2】【文本1 头像1 文本2】【文本1 头像1 文本2】【文本1 头像1 文本2】
通过改变渲染顺序，变成 所有文本1 统一渲染 ，然后统一 头像1，然后再文本2 ，最终所有的文本1 drawcall 是 1 所有的文本2 drawcall 也是1 ，头像的话 如果是同一个图集，那么也是1，最终就是3
如果头像属于不同的图，那么就是2+ 头像资源数量
考虑到mask + 2