3.6.0动态像一个active为true的node中加入节点消耗特别大，把active设置成false就好了
把一个拥有众多子节点的node的active设置成false消耗也特别大
在node的parent的active为true时调用node的destroy方法消耗特别大
这些问题在微信小游戏里尤为明显
项目为2D，用了两个相机，所有内容都只能在某一个相机中被看到
这些是正常的，因为会执行里面的组件的生命周期函数。开销主要在函数里面的实现上。
多消耗一些可以理解，但消耗过于大了
目前多了多方对比，基本锁定问题了，如果prefab里有cc.BoxCollider2D就会有这个问题，去掉后基本恢复正常
碰撞检测我选用的是
我觉得node.active=true变成node.active=false或者直接destroy，如果node中包含碰撞组件，对应的处理可能有些低效，而且低效到非常明显的影响性能
1赞
我个人的项目也是，不过应该是和碰撞体以及上面脚本的复杂程度有关，你可以试一下精简一些碰撞组，没必要勾上的就不勾上，可以有较大的性能提升。不过如果有相关需求，开销还是会很大。我现在也是卡在这个问题上，无论是直接destroy还是active=false，都会有巨大开销。
我已经精简到最小了，没啥用，100个碰撞对象，pc浏览器active=false的开销在400ms左右，发布到微信小游戏直接21s，而且还没有啥替代方案
那只能自己手搓脚本碰撞器了，反正我现在也是卡在这里很难受，我是一个对象有大概三四个碰撞器，目前碰撞组情况下是只要8ms左右，但是加多一个碰撞组就会40ms，我都在想后面有关碰撞的功能要不要全部交给代码来实现算了，感觉官方这个碰撞器还有待提升TAT
我就一个碰撞体，还是设置的sensor，运行还行，就卡在销毁这一块，手搓也行，就是现在改挺麻烦。
发布webmobile都能忍受，不发布微信小游戏都不知道这么大影响，哎~~
刚才实验了一下 把碰撞器顺序放到最下面，可能有一点改善效果
删成一个空节点效果也不大
改box2d吧，buildin问题太大，box2d基本可以接受
我试了一下你的方案，理论上可行，但是因为我的寻路模块的每个节点都有碰撞体，所以反而加大了平时帧的消耗，所以对我来说还是不行。
我已经找到一个强行解决问题的办法了，我发现就是物体移动是不会产生什么消耗的，我直接把要destroy的物体移到坐标(99999,99999)去，并且把这些原本要destroy的节点放到另一个节点里面作为子节点，然后直接隔一段时间再清除这个节点的所有子节点。在清除之前提示玩家游戏正在保存或者之类的操作，纯纯的用局部的卡顿换整体的卡顿了。等官方优化destroy之前，我感觉我只能这样了TAT 
毕竟那样的方案的话，是真物理系统，每一帧都会有真物理开销的。即使已经把各种摩擦力重力什么的移除。
这个适合走地图的游戏，如果是跑酷类的话，销毁一个节点卡一下，巨影响体验，而且我是换场景的，在换场景的时候想不销毁都不行。
真不明白box2d这种物理的消耗没问题一个简单的碰撞检测居然出这么大问题。
为了改成box2d，要改动很多代码，发生碰撞直接让节点消失的逻辑在box2d里有问题，需要放在下一帧让消失，很多逻辑在碰撞的同时不能处理，也挺麻烦
您好，请问builtin碰撞系统destroy的开销能不能改进一下？比如不需要在一帧内全部destroy完，只需要让系统让他先消失，后面慢慢释放这些资源呢？
我试了一下3.6.3社区版，似乎并没有修复，是还没上线嘛？
老哥 请问有修好吗这个修复pr，我不太知道怎么搞这个修复pr下来测试
我没测，以为3.6.2会合并，哎