我已经精简到最小了，没啥用，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会合并，哎
3.6.3都没并，我估计是改这个遇到的问题太多了，不过我看了一下改的代码，似乎也没很多行，只能等后续了。不过老哥你知道修复pr怎么用嘛？
3.6.3后面会合入，3.7已经合入。
兄弟可以测试一下3.7，论坛出测试版了，不管解决没都回复一下哈
我是3.5.1用了你这个方法，反而变得更卡了。不知道为什么
用了一下 项目直接跑不动了
[Preview]Cannot read properties of undefined (reading ‘getProbes’)errorInfo.stack ? '/n TypeError: Cannot read properties of undefined (reading ‘getProbes’)
at ReflectionProbeFlow.render (http://localhost:7456/scripting/engine/bin/.cache/dev/preview/bundled/index.js:254696:65)
at ForwardPipeline.render (http://localhost:7456/scripting/engine/bin/.cache/dev/preview/bundled/index.js:40957:32)
at Root.frameMove (http://localhost:7456/scripting/engine/bin/.cache/dev/preview/bundled/index.js:2768:28)
at Director.tick (http://localhost:7456/scripting/engine/bin/.cache/dev/preview/bundled/index.js:18756:24)
at Game._updateCallback (http://localhost:7456/scripting/engine/bin/.cache/dev/preview/bundled/index.js:19640:22)
at updateCallback (http://localhost:7456/scripting/engine/bin/.cache/dev/preview/bundled/index.js:95892:23)’ : ‘’
似乎是什么探针错误，我研究一下