fastRemove应该是有问题的,组件disable的时候会从update遍历中移掉,节点destroy会同步修改active触发disableComp,不会延迟到update之后执行
然后remove是没问题的,3.x里面内置组件都是声明了order的,根本不会走fastRemove所以不会有问题
至于2.x的话,组件update一般涉及到节点移除的都会带判断,所以多执行一次少执行一次问题可能也不太大吧
remove也有少update的问题,只是不会多次update,算问题比较小吧
fastRemove应该是有问题的,组件disable的时候会从update遍历中移掉,节点destroy会同步修改active触发disableComp,不会延迟到update之后执行
然后remove是没问题的,3.x里面内置组件都是声明了order的,根本不会走fastRemove所以不会有问题
至于2.x的话,组件update一般涉及到节点移除的都会带判断,所以多执行一次少执行一次问题可能也不太大吧
remove也有少update的问题,只是不会多次update,算问题比较小吧
楼上说的没错,只有没设置executionOrder的才会进到这里,给你的自定义脚本加下不同的执行顺序也可以解决(删除执行顺序小的节点可能也会有问题)。或者试试这样改看看,
public fastRemoveAt (i: number) {
const array = this.array;
array[i] = array[array.length - 1];
--array.length;
if (i <= this.i) {
//交换下i和this.i
[array[i], array[this.i]] = [array[this.i], array[i]]
--this.i;
}
}
一般场景来说,多一帧或者少一帧,影响可能不是很大。只是这边前端跑完战斗,要根据帧时间和锁死的随机数重跑一遍战斗做验证,要求比较高,已经把脚本单独拿出来invoke了。2.x的引擎,设置executionOrder也会有点问题,i–的位置不对,造成后面的节点组件多次update。