无优化 效果
子弹每一帧都要和屏幕中 所有的 鱼做碰撞检测
这样大量子弹和鱼同时存在的情况下 计算量是相当可怕的
造成cpu 占用极高 fps降低 卡顿
优化后 效果
打个比方 把屏幕 分为9块(可以继续细分)
鱼和子弹移动的时候 计算出自己所在区域(同一个子弹和鱼可以存在多个区域)
子弹和鱼 只和自己所在区域内的鱼做 碰撞检测
这种方法在 大量鱼和子弹同时存在的场景 可以有效减少 碰撞检测次数
不要不动脑子就喷好么（连分group都不知道的 更不要骂我了）
鱼和子弹量少的时候 确实是比不分区域计算量大一点点， 但是这个计算量的消耗其实是可以忽略不记的， 咱们做游戏是要保证用户在所有时间段都不卡
相比鱼和子弹 很多的时候 检测区域 和 检测碰撞 相比 计算确实是比 直接检测所有鱼和子弹碰撞的效率要高很多
再骂我的同时 如果你有更好的方法，欢迎分享出来狠狠的打我脸
瞎扯淡，你这消耗还大一些
是不是每一帧都要检查一下鱼的坐标判断到那个区域了，如果到达了新的区域，是不是要把鱼从上一个区域的数组里移除，插入到新区域的数组里。同理，子弹也一样。如果你是这样的，好像消耗更大。
我喜欢用 4 X 4 16格
当你 屏幕内 同时有100条鱼 和 100个子弹的时候 你可以 算一下啊， 不要脑子都不动 就妄下结论
判断所在区域 只需要4个点， 可以隔帧检测， 鱼和子弹量大的时候，相比去做碰撞计算， 这样确实会减少很多计算量
做个分组就行了 鱼跟鱼无碰撞 子弹跟子弹无碰撞 简单方便
这个是在 分group之后 加持的方法
33只是一个基础概念， 自己觉得爽用 1212 岂不是更刺激
优化方案很多，隔帧检测，区域检测，全屏检测，引擎自带的碰撞检测(+group)，有效鱼类检测(比如鱼在屏幕范围外，还需要检测嘛？肯定不需要吧)，减少鱼类数量。
利弊：
隔帧检测减少了检测的次数，是顺畅了，但是太顺畅了，以至于从某些小鱼中穿过去而检测不到。所以隔多少帧要控制在合理范围内。
区域检测，也是为了减少循环次数，但是在鱼很大的情况下，他会存在N个区域，举个例子，大鱼A在 a,b,c三个区域，大鱼B也在这三个区域，那要检测多少次?小学数学。
全屏检测会检测所有鱼，不好评价，好的机型上，其实也不会有多卡。
引擎自带功能，不方便也不在这里评价。
有效鱼类检测，在实际操作中，我们会发现，鱼都是从屏幕外开始往屏幕内游动，轨迹波浪线弧线等各种奇怪的姿势。那势必会有大量的鱼存在于屏幕外。在屏幕外的就不要去检测了嘛。
减少鱼类数量，顺畅是真的顺畅，但是业务需求不达标啊。
综合上面的几点，我的方案是: 隔帧检测+全屏检测+有效鱼检测+合理的鱼类数量。
其实我们想想，捕鱼游戏的精灵数量，和子弹射击类的数量，谁多谁少？消灭病毒不也很顺畅嘛，那么多精灵也没见卡顿。
也许你们会有更好的方案，一起交流啊
你家捕鱼同屏100条鱼100发子弹？纯粹脑子不好，实际情况就是极限状态下的碰撞检测计算消耗 根本可以忽略不记，影响性能的根本不在这，刚做的3D捕鱼不解释了
嘴巴臭 又不长脑子， 跟个跳梁小丑一样在这骂什么呢？ 我只是提供一个思路， 用不用随你， 你自己又没说出成熟的优化方案 在这里找什么存在感？
意思国足不能喷？你行你上的节奏？自己错了还不认，死鸭子嘴硬
讲话客气点吧，楼主提供的其实就是四叉树啊，用来划分场景很常用的套路。考虑到子弹的速度，通常子弹不用分区，对鱼做分区就行，分成 8 个区域的话就能减少 87% 的开销。
同屏 20 条鱼，100 发子弹连射的话，每帧的碰撞检测次数是 2000 次。这样的优化还是有价值的。
大佬看到啦，哈哈
学习了，确实是个优化方案。原本是每一发子弹都与屏幕上所有的鱼进行碰撞检测，改成每一发子弹只与其在同一区域的鱼进行碰撞检测。问大佬一个问题，你说的 “判断所在区域 只需要4个点， 可以隔帧检测”，当数量多的时候本来每帧都有计算再隔帧去检测区域，会不会有较大误差呢。 当然了目前还没有真正去试下你说的方案，只是感觉有点疑惑问问你。
因为好像鱼和子弹的运行路径是固定的，能不能像两个方程式求解那样，当子弹运行到那个交
点或者范围，再去找那个点或者范围有没有鱼，不知可否这样
楼主的方法确实是可行的，原理和四叉树一样，本人laya开发，由于他们的引擎物理碰撞实在是没法用，只能自己写四叉树碰撞，同屏200个子弹和好几十个敌人，公司最低端的安卓测试机保证55帧以上。
分成8个区域就减少87%的开销？我也是醉了
难怪官方那么多bug
每帧检测都可能出现子弹穿过鱼而没有发生碰撞的情况，更别说隔帧检测了
