记一次unity3d 游戏帧率踩坑的过程

优化方面，除了平时顺手做的代码方面优化，对象池以外，基本上没怎么去关注过，所以这一方面蛮白痴的。今天发现游戏帧率从一开始的100左右，会随着运行时间逐渐降低，甚至降到个位数，所以只能去查阅这方面的资料进行优化了。

文章没有一点干货....没有具体的优化方法（因为我也不知道.....），旨在记录一次分析过程，以便后续碰到类似问题时不会无从下手。

首先使用的分析工具是unity的framedebugger，去对边前后drawcall的数量，发现即使已经勾选了动态批处理，但是场景中的同一种对象，竟然每个是一个drawcall。可能是因为动态批处理的种种限制，导致没办法合批处理，由于这里涉及到模型顶点数，shader属性，通道等知识（没错，我不懂），所以没有再去分析其中缘由，本打算狂补知识去优化drawcall，然后通过对比发现，随着运行时间的增加，drawcall并没有明显的起伏，所以造成帧数降低的原因并不是这个，解决问题要紧，狂补知识先作罢。

然后使用unity profiler分析。cpu那里帧数显示从一开始的200到100，再到60,30，取某一峰值帧，查看耗时，竟然达到了恐怖的80ms+，然后选择hierarchy视图，查看耗时排行，看图

发现了罪魁祸首是GameObject.ActivateAwakeRecursively，竟然耗时57ms，而这个意思是在创建物体，执行awake的操作时，里面的一系列操作所耗的时间，然后我就在疯狂搜索这个东西应该怎么去优化，直到我什么有效信息都没搜索到的时候我开始换了个思路去考虑，首先重新运行项目，在一开始的时候去获取这个的耗时，发现一直在个位数，无论我的场景里面是不是在生成对象，对比可以看出一定是项目运行过程中有什么不当的操作导致的这个耗时在不断地增加，但是游戏里面已经使用了对象池，而且分析对象池内数量和创建出的数量，一直处于平衡状态，并没有随着进程的增加，而创建出很多意外的物体。冷静下来分析之后，想到了框架本身的一个组件，记得每次创建对象时，都会去重复添加这个组件，以前一直以为无所谓的东西，所以一直没有去处理它，修改代码之后，果然，fps一直稳定在100左右，运行了很长时间之后也没有出现掉帧严重的情况。

再看上图，一个logstringtoconsole，意思很明显，log，这里耗时8ms，并且！产生了223.3k的gc，实在是过于恐怖，这个很好解决，把项目里高频率的log都删掉，然后log这块基本就没有什么消耗了。项目发布的时候，一些数据的log可以不用删，毕竟后期真机测试有时候有数据log查起来会很方便，但是高频率的log一定一定要删掉。

再次回到上面关于awake那个问题，进一步实验之后，发现addcomponnet耗时时间与对象本身的组件数量有关，一个简单的demo，场景里面有30个对象，在update里面进行循环遍历所有对象并都添加 一个空的继承mono的component，测试发现，耗时从一开始的1~2ms，一直在增加，增加到9~10ms，当然还会继续增加。有兴趣的可以实验一下，后面查下addcomponnet源码，或者能知道原因。

留坑补shader的知识，drawcall批处理那一块进行优化。