Chinaunix首页 | 论坛 | 博客
  • 博客访问: 199824
  • 博文数量: 47
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1259
  • 用 户 组: 普通用户
  • 注册时间: 2013-07-24 10:20
文章分类
文章存档

2014年(21)

2013年(26)

分类: 网络与安全

2013-09-25 13:33:11



最近做的一个游戏类似植物大战僵尸的风格,做完之后发现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%的不同。

阅读(1703) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~