MARK.
我刚做了个水平的，不管是一千还是一万项，drawcall也就七八个.
理想情况的draw只有3或者4，相比来说4的代码可读性高，要简单一点。
不过比较好奇，透明度为0就不draw这个是creator的做法吗?
mask
哈哈
很不错，类似android listview的优化思路
item内字体弄成图片没啥必要，本身就不是常驻场景，
会优化而去优化就得不偿失了
这种思路是最简单的。之前我自己搞了个优化，来回移除添加循环几个item的方法，期间不仅要处理item的位置（这样就不能用layout了），布局，还要处理绑定事件，虚拟index映射问题。虽然效果可以，但是后期增加需求，各种类型的item，item点击展开子item，item动画过渡，页面跳转回来重新恢复到指定的item，复杂程度直接原地爆炸，后面我采用了楼主类似这种优化，瞬间我解脱了。不过楼主这种可能会遇到需要做透明度动画的问题，还有数量多了，每帧for循环个几千次消耗也是个问题（这个我也不造咋解决）
个人认为最优方案为循环列表和碰撞更新列表复合使用，在重复的item上面就可以使用循环列表，多类型item可以使用碰撞更新列表，但如果项目的list所展示的item如果不太多也可以直接使用碰撞更新列表
楼主，这套在3.0上 需要改动一下 没有_calculWorldMatrix()
rect_o.transformMat4(node_o_._worldMatrix);
当时是直接复制的cocos2.3.x内部的函数，版本不一致出现的接口不存在是很正常的，可以直接照抄对应版本的函数实现
哈哈，我愿称之为丐版优化，虽然不及listview从根源上解决问题，但是这个改动容易，更快啊。
如果item在100-200之间，我感觉你的优化方法是够的，如果item多了，还是得换listview
不要太看低js的性能，低端机型保底500左右是没问题的，现在市场上的低端机也非常少，而中高端基本能1000以上都没啥问题
mark 下
哪怕您写一个字节的代码
说话之前麻烦自己测试下，不要做云评论家，更不要云写代码，我发布的所有帖子内容都是经过实际测试的
如果按照你所说的不在可视区域不会渲染为什么官方示例里面会有 listview， 为什么有人要写几千行的 循环列表代码？
creator 3d 1.2.0是不是不适用这个方法了？
是的，这是由版本2.3.4编写，3.0及以后需要修改部分代码，晚上回去我看看