万分紧急，捕鱼性能调优，求助各位民间大佬和引擎大佬。

Creator 2.x
#1

目前的做法一条鱼开始的时候有三个激活节点，一个父节点放碰撞盒子，一个子节点放鱼的骨骼动画，一个子节点放鱼影子的骨骼动画：如图

GI06R9VUG7ZY]09EWQ[PMWK.png1490×385 18.7 KB

这样导致的是，同屏一百条鱼，就有300的drawcall。一般鱼阵都有250条鱼左右，drawcall就上500多了，如果不做碰撞检查的时候帧数还能有30帧左右，如果再加上40颗子弹同时同屏，卡的动都动不了，game logic 飙到几百ms。
测试手机是：小米5s，cocos creator版本：v2.0.9 p1
求大佬告知优化方法。

1赞
#2

同是做捕鱼的帮顶一下
我们用的序列帧，鱼的数量也少得多，所以情况还好，只是内存有点吃不消了
你要不找策划聊聊，少一点鱼？

#3

鱼减少，是可以减少压力，但是没从本质上解决问题。= 、=。

#4

1.碰撞的问题，可以不用碰撞盒子，根据鱼的种类和大小，画圆，多了就多画几个
2.碰撞检测，全屏划分区域，判断特定区域，不全屏判断
3,鱼的影子，可以直接copy鱼，然后色度调黑，不需要另外布置层

这样应该好一点了吧= =

1赞
#5

DrawCall过高的问题应该不是性能瓶颈。
切换材质比较费性能，单纯的调用绘制应该还好。
还是优化一下逻辑部分吧。

#6
  1. 不清楚你用的版本是否可以使用渲染组件了。
    可以的话，鱼如果可以用instance来渲染，理论上可以大幅度地减少drawcall。
  2. 骨骼动画的定制我也不太清除引擎组的进度。但是以我最近在写的骨骼动画来说，减少动画K帧的数目，应该可以减少找插值的关键帧的时间，但这个不一定是瓶颈。
  3. 有一个很值得注意的地方，不开启碰撞检测的时候，还有30ms，但是加上碰撞检测，达到了几百ms，有理由怀疑瓶颈在 碰撞检测 上，或者说，由于碰撞后逻辑导致的 骨骼动画显示，消失，导致提交的cmdbuffer需要不断重新创建，骨骼动画不断调用构造函数，析构函数的开销
    至于解决方案：
    前者好说，用上 场景管理树 ：hlbvh, quat-tree, 应该都有现成的，感兴趣可以去看看bullet物理引擎的官方文档，里面碰撞检测管线的描述很详细，这可以减少碰撞检测的开销，但是不好说减少多少，毕竟场景也没多少物体。
    后者呢，老生常谈，用 对象池 吧。如果开销瓶颈不是动画，而是创建和析构上，那么回收骨骼动画的时候，最好不要将骨骼动画的节点从节点树上拿下来，而是 将骨骼动画移动到屏幕外(移动到场景外，会破坏场景管理树的结构，需要重新创建，所以记得profile一下性能瓶颈，究竟是碰撞是瓶颈，还是渲染是瓶颈，得出结论后，再决定是否要移动骨骼动画到场景外，这是一环套一环的) ，然后可以进行一下尝试：
    1.将节点的active设置为false
    2.将节点的动画停掉，
    3.将节点的透明度设置为0
    并且这几个方案都尝试一下吧。哪一个真正能提高性能，我最近也在写游戏引擎，个人愚见，这个和引擎开发者，做出的 设计取舍 有关。最好去问问做这一块的引擎开发者。
2赞
#7

1、减少动画初次渲染计算： 骨骼动画第一次使用会有大量的帧初始化计算 放在背景下先偷偷渲染
2、减少节点数量： 碰撞框说白了就是一个相对于中心的固定偏移量的矩形，用数组记录下来各种鱼的数据检测碰撞的时候去取就行了
3、减少drawcall a、影子就是一个相对于中心的固定的偏移量的不同动画 同种类型的影子保证父节点和层架一样
b、同种类型的鱼放在同一层级
最后鱼的总drawcall应该是 鱼的总类*2
4、检测碰撞这一块一定要做区域划分 减少算法时间复杂度
5、对象池：减少new的时间 这个都知道
额 个人经验 希望对你有帮助

#8

谢谢你提的建议。有几点不是很明白：因为我碰撞是用官方提供的，你说的一二点是要自己写个碰撞检测嘛？第三点的copy是什么意思…，是接口嘛。

#9

谢谢回复，因为是新手。你提的这几点建议，都看的不是很懂。有以下疑惑，望能帮忙指点一二。
第二点和第四点的意思是要自己写个碰撞检查嘛？
第三点中drawcall优化，骨骼动画，目前不是只支持web版合批渲染嘛？
有用对象池。

#10

谢谢你的回复。
不知道我现在这样用是否合理：每只鱼我制成一个预制体，鱼的骨骼动画都是在编辑器上选择循环播放。创建节点池，要用的话就从节点池中拿，添加到鱼容器节点。鱼被子弹打死的时候，激活鱼死亡动画节点，隐藏鱼身体节点。监听鱼死亡动画，播放一次后，直接把鱼节点从父节点移除放回节点池中（这边有一个困惑，都移除节点了，还需不需要把动画先关闭掉）。
鱼阵的做法：会遍历服务端下发的鱼数组，生成鱼节点，添加到节点容器上，感觉这样做也不合理，等于一下子同时几百个节点加到容器节点上。
碰撞检查：是用的官方提供的，你提的优化，是要自己写碰撞，还是基于官方上面做优化。

#11

1、为什么不用碰撞盒子，改用圆呢？
2、划分区域：是把不在同一区域的鱼的碰撞盒子关掉嘛，这样只会做特定区域的检测，我现在的子弹是按每帧去移动距离并判断是否触碰到边缘去调整角度，那区域要怎可划分。

#12

@2495360701

捕鱼对碰撞的准确性要求不高, 一般都是使用大圆套小圆的方案, 碰撞引擎是是要自己写的.
圆的碰撞检测效率很高, 使用大圆套小圆, 就不需要分区域了. 自己写的碰撞检测, 做功能和调优都更容易.
序列帧做捕鱼, 我这边是50个drawcall以下. 骨骼动画没试过.

#13

圆形碰撞只需要知道2个圆的半径和直线距离就可以知道是否碰撞了 计算过程很简洁 速度很快

#14

骨骼动画的性能明显没有序列帧高 这种捕鱼游戏 完全可以序列帧来做

#15

我试了用官方的圆形碰撞组件，好像碰撞效率没有提高多少- -。。

#16

因为动画已经是做成骨骼动画了，

#17

骨骼动画会打断批次渲染.
enableBatch 开启合批，如果渲染大量相同纹理，且结构简单的骨骼动画，开启合批可以降低drawcall，否则请不要开启，cpu消耗会上升。
方案一：使用序列帧动画。
方案二：具有骨骼动画组件的节点不能穿插的放在节点树中，集中起来放在顶部或底部。

1赞
#18

1.用帧动画 2.尽量将鱼合成在同一张大图 3.调整 ui 层，特效层等，尽量不要打断渲染

#19

@2495360701

那就自己实现一个碰撞检测引擎, 只用圆形, 大圆套小圆.

#20

性能瓶颈是出在碰撞检查这一块，用四叉树划分区域做碰撞检查，性能妥妥的。