mark
###经过分析，消耗热点主要集中在设置材质属性上，由于2.2采用原生渲染，所以需要将材质参数上传至c++，就涉及到jsb接口的调用，2.2.1 将会对材质进行缓存，避免同种材质需要重复创建。另外开发者也可通过对象池对对节点对象进行缓存，这样不仅可避免材质的重复创建，还可减少大量的jsb接口的调用，创建过程可以得到很大程度上的优化。
###感谢反馈，我们将在 2.2.1 以不牺牲其它模块性能的情况下对节点创建性能进行优化。
这是我们工作没做到位，非常抱歉。其实我们有测试并优化过 2.2.0 的场景加载时间，优化后基本是持平的，所以才敢发布。最终这个版本会有这样的副作用，是因为其实 2.2.0 是一个前后延期了一整年的项目，在这段时间里我们对优化方案进行了几次升级，在最后的升级过后我们没有再次进行性能回归测试，导致这个问题并没有及时发现，非常抱歉！
为什么最后没有进行性能回归测试？因为之前我们每个版本发布时都有一整套的性能测试用例，刚好最近由于公司又跳闸，导致该用例的服务器虚拟机数据受损，无法启动，才在这个版本采取了手动测试，因此流程上把控不够严格。我们今天已经对测试用例进行重新修改，之后会采用更加简单可靠的方式进行发布流程上的严格测试，希望此类惊喜不再重演。
解释这么多并不是要卖情怀，而是想要表明我们对引擎方方面面性能的关注。
2赞
2.2不是说垃圾回收机制改了么.你的demo确定进行这块操作了吗.
我看了下,这块内容我还真没留意过,可能我的项目太小了,没感觉!
那奇怪了,我这边都是cc,instantiate 瞬间创建50个,比以前快,没卡过的说,…
2.1.3等以前的,瞬间创建50个预制 每个预制 是5个spine 5个node 1个mask 会很卡
现在2.2.0我这边实测是秒建没卡过… 所以我也挺意外的,你们会出现慢的问题.
我同时也是2个场景互跳 一个场景每次瞬间创建200个节点 1个场景1000个节点. 并未发生卡的问题的说
起初, 我从大厅界面进入游戏打鱼场景的时候, 感觉比2.1有了一丝卡顿, 主要表现在logic frame的短时间大幅度增加, 过场的加载界面logic frame 峰值大约是从之前的 50ms 提升到 150ms 左右, 但是由于是载入界面, 卡顿并没有实际的影响, 所以并没有过多关注这个问题.
后来我研究了一下创建节点的地方, 发现确实复杂了很多, 还涉及到js层与native层的互相调用
根据我的测试，现在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的明显快很多