Libgdx画面FPS性能优化经验

 最近做的一个游戏类似植物大战僵尸的风格，做完之后发现FPS一直不高，打无尽模式就相当的卡了，所以就研究了一下到底是什么原因导致的。目前优化完FPS提高了35%，效果还是比较理想的，记录一下经验供分享。

【性能定位】

1. 可重现的DEMO

 先写了个一可以重现问题的demo，另外还准备了一个看起来效果类似却不出现问题的demo。这样有比更容易找到问题。

2. 时间消耗在哪

 开启jvirtualvm进行测试，很明显内存是一切正常的，但是CPU消耗就异常了。反复对比发现CPU消耗主要就是在“org.lwjgl.opengl.GL11.nglDrawElements”方法上，对比正常的demo，主要时间消耗是在“org.lwjgl.opengl.GL11.glDrawElements”方法上。前者调用了jni，后者就是直接调用，所以性能上有较大差距。但是这个时候还是很难知道到底为什么会这样，这些代码也都是被封装了的，看不到源码。

3. 定位代码

 还是要找到大致问题代码是在哪一块，其实目前已经知道肯定是绘制的地方出问题了，所以用时间打印的方法很快找到代码，但是跟到最后就是一个内部的函数调用，外层方法完全看不出来有啥特别的。

4. 替换比较法

 还好准备了两个有对比性的demo，不停的替换不一样的地方去看看到底是哪里引起的。这是一个笨办法，但是通常都很奏效，但是也要点运气，搞了几个小时总算发现了端倪。

【性能优化结论】

1. 绘制的性能与次数有关，与绘制最终所占屏幕面积无关。也就是说你把100个图片覆盖整个画面的性能和100个图片绘制在同一个位置看起来像一个图片的性能是相当的。

2. 图片绘制的面积大到一定程度才影响性能。绘制工作肯定还是与面积有关，但是25%屏幕大小以内的图片对性能影响几乎没有，但图片达到80%屏幕覆盖时会有大约40%的性能影响，不是成同等比例关系。

3. 图片用Linear比Nearest要更消耗性能。当需要用到的Linear打包图片数量达到几十个的时候就需要注意性能，尽量改用Nearest算法，性能会有10%的提升。

4. 同一个打包合并的图片连续使用可以大幅度提升性能(注：同一个pack下合并在不同图片性能和2个pack是一样差的)。在同一个pack的图片，注意在addActor的时候连续添加，性能可以极大提升，甚至连续绘制几百张图片都不会对fps有太大影响，这也是为什么在libgdx有一个actor测试的时候有许多图片感觉都不掉fps的原因。这个优化性能提升是在100%以上。

5. 画面简单，透明度较多的图片性能更好。这个会减少绘制的负担，当然图片大到一定程度才会感觉到差别，根据画面复杂度可能会有20%的不同。

6. 大量的GROUP对象影响绘制性能。当GROUP对象使用达到几十个的时候，哪怕只是包含一个Image的Group都会比简单的Image绘制要消耗更多时间，帧数下降了10多帧。

本文转自passover 51CTO博客，原文链接：http://blog.51cto.com/passover/1300034，如需转载请自行联系原作者