手机游戏行业中，有不少厂商习惯使用cocos和unity作为引擎来快速开发游戏，cocos作为很多厂商选择的引擎之一，在调优工具以及性能检测上，并没有像unity一样完整的工具链支持，遇见卡顿往往也不太好解决，而一般小型公司的游戏测试团队可以提供的支持又比较有限，场景往往是如下情节：

测试：感觉在打怪的时候有点卡啊，帧数有点低

开发：好的，我瞅一眼。一段时间后……开发：你看看好了没

测试：感觉比之前好一点啊，但是平均帧数没什么变化

开发：我优化了下内存，你看看内存

测试：哦，内存降了，但还是卡

开发：…………

这种场景在工作中经常能遇见，开发也没有时间去细查到底哪有问题，测试也一头雾水 所以借腾讯一位同行一句话：手游性能优化是一个时空转换的艺术，就是在时间和空间上进行平衡。就像在入栈的数中找最大值一样，最快的方法就是再建一个栈。

游戏卡点:游戏中可能导致的卡顿点有很多，列举了一些在工作中遇到的：

1.内存超标，内存泄漏（也包括mono内存，mono，是C#代码的解析器，c#编写程序就存在mono内存）

2.网络引起卡顿（丢包率过大，协议解析速度过慢（可以白盒测））

3.drawcall超标（drawcall是open gl绘制次数，根据不同场景，在符合需求的前提下，越小越好，一个简单的openGL的绘图次序是：设置颜色→绘图方式→顶点座标→绘制→结束。 每帧都会重复以上的步骤。这就是一次draw call）

4.fps波动（方差，标准差，平均值，卡顿一般来源于不稳定而不是帧数过低）

5.cpu过高（场景内三角形数量过多，gpu负载过大，磁盘io过多）

6.音效加载和播放（易导致主线程阻塞）

以上检测点，是在一轮详细的性能测试过程需要注意的点，但是其中存在误导，手机过热会导致各项指标下降，所以在实际测试中，也会确保测试设备的硬件处在合理的温度范围。

解决方案：

1.动画

粒子（粒子数尽量精简）

动画timeline（控制关键帧数量）

ccb内容拆分（ccb中，包含多个对象，但是显示只显示某一个时，可以拆成多个ccb）

2.原画/UI

纹理显示（降低DrawCall数）

原画图片（图片大小，影响内存）

3.配置相关

配置文件（配置文件汇总，降低io频率）

音效音乐（码率越低，加载越快，效果越差）

4.程序相关

区分机型内存，使用etc压缩纹理方式，降低峰值内存

JSB使用检查（在update中，尽可能少的调用跨语言函数，因为需要创建多个对象，导致update时会创建很多琐碎对象）

控制gc频率，以及虚拟机vm（内存，32M或64M）

在进入游戏核心玩法（比如战斗，棋盘等）预加载音效，动画等（虽然延长了loading，但是确保第一次游戏不会出现明显卡顿）

渲染相关（检查Draw call数 ，node节点数，三角形顶点数）

控制gc频率，避开游戏核心

总结：游戏里，大部分的顿都是GC和资源加载导致主线程卡主或者cpu瞬间达到峰值造成的。内存泄漏也是经常犯得一个错误，加强资源生命周期的概念，及时回收资源，预防内存泄漏，可以有效降低崩溃的频率

在测试过程中，也可以自己编写一些统计工具，让程序在日志中打出符合测试需要的日志，比如fps的方差，标准差等等，也可以统计游戏过程中大于50ms，100ms等的帧有多少个，这样比单纯统计帧率更加准确一些。

还是开头那句话，性能调优就是时间和空间的艺术，需要平衡这两者的关系，达到自己项目的需求。