看到这样的回复，忍不住出来吐槽下。
可视化区域外渲染增加了drawcall，影响了性能没错吧。在各家引擎都在想法设法提高引擎性能和降低能耗发热的背景下，cocos就是巍然不动，需要的功能自己写就好了，反正引擎是开源的，已然把各种问题推给开源了。
我们没本事把引擎用好是我们技术不好，但是就算自己改了引擎，新版本也不一定兼容，只能固化在某个版本。万一哪天需要升级引擎，以前的代码就的吃灰重写。
为什么要官方兼容？为了大家能用引擎开心点，不要天天想着与引擎斗其乐无穷。
要符合组件化开发思路？好的，那你们有考虑过开发一个屏幕外不渲染的组件吗？既然有呼声，肯定有需求。
抱歉，不是所有的程序都能在贵引擎的基础上大规模优化。有那个实力的人都自己做引擎了，慢慢就变成了，有实力去优化引擎的人不屑于用Cocos，没实力优化的用不好cocos。
不是针对您，只是有时候看不懂cocos在想什么。或者也有可能我的想法才是异类？
题主，我们目前是计算item的坐标，如果在屏幕外active=flase，屏幕内 active=true来实现的。目前没想到更好的解决方案，欢迎讨论
难道scrollview下面挂个mask不能解决你这需求？
Scrollview下面本身就有mask
mask实现不了：可视化区域外不渲染？
examples-case里面就已经有listview的实例，直接拿过来照着改一下就可以用，里面有实现子节点的复用这些功能。不能满足你的需求么？
论坛上也有其他用户关于scrollview以及listview，包括类似以前2d-x的tableview的实现分享，都是可以直接拿来使用或者借鉴的。
通过这些代码你可以看到，要做到这种需求，对于scrollview中content下面的item都会有特殊的业务逻辑。同时scrollview和item的耦合性会提高。并且每一种方法的实现也各不相同，对于性能上面优化的侧重点也各不相同。有优化必然会带来另一方面的牺牲，另外这种业务层面的优化留给用户不是更好么？据我了解关于scrollview的优化有很多，针对content的，有示例中listview的做法，也有更进一步使用缓冲区的做法，还有针对item使用renderTexture进行dc优化的做法，等等。我们很难统一，希望你能理解。业务层面的逻辑优化，还是针对项目情况来做会好一点
我就是照着官方listview再加上mask去做的，用下来感觉项目里面挺好的，也没觉得不方便。之前用UE4的时候也吐槽过官方怎么不弄一个类似listview的UI组件，后面也是自己实现的，也挺容易的。我觉得这种问题不太影响项目开发的，也就无所谓了。反而现在多投点力量在新功能，2.5D的开发上挺好的。省的老板让我们转其他引擎还得重头躺坑
论坛有人实现了可复用的ListView的，可以拿来用。
好吧，我只是觉得1.10的scrollview屏幕外的不渲染，2.x倒渲染了，貌似是引擎在改动，并且屏幕外渲染与否只是性能上的问题，是共性问题，跟业务逻辑没半毛钱关系吧，所以扯上“不同的项目对于scrollview会有不同的需求”更没必要了
打扰各位了，凑合用吧
呵呵，我目前用的是1.10版本，比这些2.x版本渲染性能都好，只是有些小bug 2x版本都修复了，但勉强能用
cocos 以前就做过这样的优化。不过优化效果不明显甚至是性能更差，所以从 2.0 开始才移除了这个优化。不是每个项目做这种重 CPU 的优化都能有性能提升的。
抱歉确实天干物燥火气有点大了。
这个问题不光scrollview有问题，场景稍微大一些，设计镜头移动的游戏都有这个问题。
能否指点一下这个在2.0里怎么优化比较好。感觉我们的简单优化上不了台面。
能不能让cocos和其他2家引擎一样做个性能测试，看看cocos优势到底在哪里
是啊，我说的就是移动镜头这种情况。开发者根据自己游戏的特点，以场景中的物体为单位，选择性的做可视范围的判断，是最高效的。
ScrollViewo还算好解决，mask外的就active=false就好了
想请教用大型的TiledMap (300x300)做为背景时
应该如何优化比较妥当 0.0?
复用item，用起来没有？
现在的引擎版本，没有做视图外结点不渲染这样的优化吗？
谢谢关心，用起来了。但是感觉现在的方法效率不高。正在寻求更好的优化方案
另外一些镜头外角色和怪物的drawcall居高不下，每帧都去判断是否显示在怪物和角色多的时候都是大量计算。发热耗电非常明显
cc.macro.ENABLE_TILEDMAP_CULLING = true 就行
感謝 jare 大神，我趕緊來試試