这两天想用一下listview（其他的没看过也不好说什么），然后看cpptest上的例子代码，看完我忍不住想喷两句了。本来我真不该说什么，毕竟人家是开源免费的，但是看到这么烂的设计真的忍不住想喷两句，见谅。
写ListView的人懂不懂什么叫封装？懂不懂什么叫低耦合高内聚？懂不懂设计模式？居然写出这么烂这么难用的东西的来，android有源码，去看看人家的ListView是怎么实现的，好好学学。
1赞
楼主吐槽的非常好。。。
那个测试例只是提供了一种复用的实现，暂时还没有考虑封装和复用，也没有考虑设计模式。
因为 ListView的一些接口有历史原因，所以暂时没法修改，后面我们会想办法让 ListView 更好用。
大神。。这个listview的clone的item有很多元素的时候实在是很卡，现在只好用schedule用时间来控制加载。。不知道还有没有更好的办法。。
我觉得TableView的实现方式都比现在的ListView要好，为什么当初不在那个实现方式的基础上优化优化而要新搞一套呢？
原来如此。我先继续用TableView对付一下。
相信有大神你在一定会越来越好。
先用 TableView 吧
如果是 clone 导致的卡，可以采用对象池，预先分配好一些对象，这样就不会卡了。
在cocos2dx中，你应该使用scrollview来代替列表容器，scrollview管理着一个layout对象，_innerContainer。你可以在该layout上放置自己的item项，如果你在clone的时候发生卡顿，是因为你在一帧中创建了过多的layout，正确的做法应该是分帧加载，来防止每帧任务过多而导致的卡顿
1赞
有没有对应的例子呢，我做的是分帧加载，你这种方法我想学习下
分帧加载也是可以的，对象池上网搜一下吧，应该有不少。
很简单的一个东西，没有那么复杂吧？
列表里先创建一定数量足够铺满屏幕的item项，然后在滚动的时候判断一下滚动方向，比如向下滑动时就看哪个item超出了列表就把它放到一个栈里保存起来准备复用，然后根据滚动距离判断一下第几项需要被显示了就把它跟刚刚被放到栈里item关联起来出栈，如此循环利用，总共几个item项就可以流畅运行大量数据了。
我吐槽的不是cpptest里的实现方式，而是觉得列表项复用这些东西本来是很简单很基础的一个东西，是作为一个列表组件本身就应该天然具备的性质才对，应该封装起来而不应该让用户去实现。而这么简单一个东西居然没有实现。
楼主可以尝试把你的想法融入进来去 Github 上面发一个 PR 
还是有一些挑战的。。。
呃，现在在做独立开发，没人给我发工资，还要养家，时间太不够用了，如果有时间而那个时候ListView还是现在这个样子的话我一定会做这个事情的，此外我听说cocostudio已经停了而cocostudio又没有开源，不知道这套UI还有没有维护下去的必要呢,如果cocostudio能把我这几天在论坛里反馈的动画不支持多分辨率适配的问题解决我马上停下手头的工作来尝试一下这个挑战。否则我不知道做这件事情的意义在哪里。
另外，感谢cocos团队的无偿付出，你们是伟大的团队，我吐槽归吐槽，但是一直很感谢你们的付出。
2赞
android就是这个实现了，我之前有实现过一次，但是有item增减的时候处理的不够好，cocos虽然是开源，不过有些基本功能还是要封装的啊。。。
这个ListView确实非常鸡肋。项目里也是从不碰ListView，顶多在脚本层把CCTableView封装一下使用。
几乎所有的现代UI 框架都实现了List这类控件虚拟滚动，也就是预先创建比界面显示多2个的ItemRenderer，循环利用，比如界面向上滚动时把不在显示区域的Item放到最下面。
这种实现原理很简单，不过整个UI框架就要换成完全的数据驱动形式，这意味着很多没有设计模式思考的前端人员会比较难入手理解。
so，这不是一个组件的事情，用TableView也只是打个补丁，整个UI框架都必须重新基于一个模式构建。
老实说，我受够了每次创建List都要for循环。
不老实的说，我觉得十年前Adobe Flex推出的Spark框架都比cocos现在这套好用， Flex框架设计核心就是功能、外观、布局分离，基于MVC设计的UI控件，依赖注入式功能设计，延迟属性更新（严格说cocosv3.x已部分实现）…
1赞
说的是啊，这种基本列表数据显示复用的的东西，还要用户自己去封装，各种困难和问题
2年前的帖子你也顶
分帧加载，正解，曾经面试官考过这题