最近做的乙個遊戲類似植物大戰殭屍的風格，做完之後發現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多幀。
android應用效能測試（二）FPS
這種方法官網給了詳細說明 這裡不再贅述，這種方法的優點是使用方便。但是有個很大的缺點 遊戲的fps資料獲取不到，所以不推薦大家使用這個方法，僅作了解。1 adb shell dumpsys su ceflinger latency 獲取幀延時資料 2 adb shell dumpsys su cef...
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...
效能優化 電量優化
使用battery historian來監測電量的情況，battery historian時google的乙個開源專案 具體安裝過程參見 當出現下列畫面，說明已經開啟 其開啟成功以後，訪問網頁如下所示 說明 這裡使用的是一台國外的vps伺服器，原本是想在本地虛擬機器實驗的，一直連線超時，就換成了vp...