根据我的测试，现在2.2版本的问题似乎并不出在对象池上
只要调用了 removeFromParent()之后，将对象存在了任何想放的位置
复用的时候addchild()，只要有这步addchild，那就会导致源生平台jsc发送材质到底层的时间，就是这个时间是导致2.2真正变慢的罪魁祸首
如果不调用removeFromParent，尝试将sprite 移除地图之外，但在游戏场景中，大场景会有 2000-3000个sprite，外带100-200个循环animation。如果保存单几个场景，估计内存就会不堪重负。
一直使用destroyAllChildren来卸载场景，简单粗暴但有效，如果手动一个个的destory，估计会有失误导致内存泄漏出现
大佬，我现在已为优化搭进去了很多时间，始终无法优化出效果来。包括所谓池，或者保留sprite对象并复用，都无法提高切换速度
也尝试用了 将复用的sprite 移到屏幕外，甚至干脆将复用的元素就放到屏幕内，当执行到创建建筑加载sprite的时候，直接拿来复用外观sprite，（建筑是ccclass，其中有外观，底盘，阴影等node）用的时候改变下位置，也仍然无法优化切换速度
大佬有没有应急的办法，十分惆怅。ios我还能用手机不发烫来安慰新版玩家，安卓的我每天都砸着千亿的资源补偿玩家，独立游戏攒点玩家不容易，那都是宝贝心头肉啊。就像有一个loading时间，我怎么优化都无法影响到它。
我认为是不是我有什么其他耗能的操作，但也不是，我把全部元素都一点点的隐藏，仍然有加载时间，随着注释的代码越来越多，速度也随着慢慢快点，并没有发现是其他逻辑影响了速度。
看你说web差距不大，那你打web包呗，安卓套个壳就行了
66666,重度的 给力啊.好玩
首先申明，并没有使用新版2.2的版本。
根据过往的经验，说一些简单的想法
1.之前的版本 addchild本身就是会很卡。addchild、setparent的时候会有个耗时的过程。具体可以用谷歌浏览器里的工具profiler一下JavaScript引擎代码就知道了。
2.你场景的东西这么多，应该也有分帧率加载。这里有一个问题需要注意一下，如果一个预设的结构太复杂，在第一次ccinstantiate的时候，消耗时间会非常大。卡帧会很明显。
3.内存问题，2.x的前期版本我有看过。现在这个2.2的版本，你可以自己测试一下，内存是否存在泄露的问题。我们的项目使用自己添加的引用计数的处理。内存还算可以维护在一个可观的范围。
4.因为你这个是微信小游戏，不是app，感觉给不了什么建议。 因为我也不知道，是否微信小游戏用的是web还是原生渲染的接口，我也不清楚。如果是app，那么你可以用Snapdragon Profiler等工具进行探测，结合之前提到的谷歌浏览器的profiler工具。 如果是微信小游戏，使用谷歌浏览器，也可以探测出卡断的JavaScript的地方。
有这个时间还不如花时间降版本？要不然用户都流失殆尽啦。
这种情况肯定是先降版本，等解决了问题再更新，用户流失才是大敌啊
mark
同问，这个调试工具是什么？
同问，左边的时间消耗怎么显示出来的？
就跟你说一句话，2.1.2的速度要比2.2的明显快很多
当时做了引流到新版，现在退不了。现在双版同时维护
同问，左边的时间消耗怎么显示出来的？
官方文档有文章，先按着官方文档来，到浏览器的时候，输入xcode启动时提示的url到浏览器就行了，但不老好用的。
如果是直接浏览器本地调试，chrome直接调试就行，打开开发者工具，在更多工具中有个js性能测试，先录制了，再筛
擦 这调试的工具好6，，求问名字。。
擦 这调试的工具好6，，求问名字。。
经过测试和引擎团队的协助，发现是zindex的问题，2.2的zindex性能相较2.1.2（因2.2要有源生渲染交互）有了下降，下降了还不少，但这也是合理消耗
