Libgdx畫面FPS性能優(yōu)化經(jīng)驗

 最近做的一個游戲類似植物大戰(zhàn)僵尸的風(fēng)格，做完之后發(fā)現(xiàn)FPS一直不高，打無盡模式就相當(dāng)?shù)目耍跃脱芯苛艘幌碌降资鞘裁丛驅(qū)е碌?。目前?yōu)化完FPS提高了35%，效果還是比較理想的，記錄一下經(jīng)驗供分享。

【性能定位】

1. 可重現(xiàn)的DEMO

 先寫了個一可以重現(xiàn)問題的demo，另外還準(zhǔn)備了一個看起來效果類似卻不出現(xiàn)問題的demo。這樣有比更容易找到問題。

2. 時間消耗在哪

 開啟jvirtualvm進(jìn)行測試，很明顯內(nèi)存是一切正常的，但是CPU消耗就異常了。反復(fù)對比發(fā)現(xiàn)CPU消耗主要就是在“org.lwjgl.opengl.GL11.nglDrawElements”方法上，對比正常的demo，主要時間消耗是在“org.lwjgl.opengl.GL11.glDrawElements”方法上。前者調(diào)用了jni，后者就是直接調(diào)用，所以性能上有較大差距。但是這個時候還是很難知道到底為什么會這樣，這些代碼也都是被封裝了的，看不到源碼。

3. 定位代碼

 還是要找到大致問題代碼是在哪一塊，其實目前已經(jīng)知道肯定是繪制的地方出問題了，所以用時間打印的方法很快找到代碼，但是跟到最后就是一個內(nèi)部的函數(shù)調(diào)用，外層方法完全看不出來有啥特別的。

4. 替換比較法

 還好準(zhǔn)備了兩個有對比性的demo，不停的替換不一樣的地方去看看到底是哪里引起的。這是一個笨辦法，但是通常都很奏效，但是也要點運氣，搞了幾個小時總算發(fā)現(xiàn)了端倪。

【性能優(yōu)化結(jié)論】

1. 繪制的性能與次數(shù)有關(guān)，與繪制最終所占屏幕面積無關(guān)。也就是說你把100個圖片覆蓋整個畫面的性能和100個圖片繪制在同一個位置看起來像一個圖片的性能是相當(dāng)?shù)摹?/p>

2. 圖片繪制的面積大到一定程度才影響性能。繪制工作肯定還是與面積有關(guān)，但是25%屏幕大小以內(nèi)的圖片對性能影響幾乎沒有，但圖片達(dá)到80%屏幕覆蓋時會有大約40%的性能影響，不是成同等比例關(guān)系。

3. 圖片用Linear比Nearest要更消耗性能。當(dāng)需要用到的Linear打包圖片數(shù)量達(dá)到幾十個的時候就需要注意性能，盡量改用Nearest算法，性能會有10%的提升。

4. 同一個打包合并的圖片連續(xù)使用可以大幅度提升性能(注：同一個pack下合并在不同圖片性能和2個pack是一樣差的)。在同一個pack的圖片，注意在addActor的時候連續(xù)添加，性能可以極大提升，甚至連續(xù)繪制幾百張圖片都不會對fps有太大影響，這也是為什么在libgdx有一個actor測試的時候有許多圖片感覺都不掉fps的原因。這個優(yōu)化性能提升是在100%以上。

5. 畫面簡單，透明度較多的圖片性能更好。這個會減少繪制的負(fù)擔(dān)，當(dāng)然圖片大到一定程度才會感覺到差別，根據(jù)畫面復(fù)雜度可能會有20%的不同。

6. 大量的GROUP對象影響繪制性能。當(dāng)GROUP對象使用達(dá)到幾十個的時候，哪怕只是包含一個Image的Group都會比簡單的Image繪制要消耗更多時間，幀數(shù)下降了10多幀。（2014年1月2日補(bǔ)充）