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多帧。(2014年1月2日补充)

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章