游戲性能問題，往往是我們游戲程序員最關心的問題，對於這個問題，我在這里總結一下我關於游戲性能優化的八個理念：
理念一：善於從問題的表象上出發進行優化
游戲出現問題時，最直接的表現就是卡，造成卡頓的問題又有很多不同的情況。在解決卡頓問題前，我們應該最先排除是否是外部問題造成的卡頓，外部問題：網絡差，硬件差，系統問題等。排除是外部問題導致的卡后，我們可以根據卡頓的現象來定位問題。
1.輕微的較頻繁卡頓
1）幀率
根據游戲自身來設定幀率范圍，一般游戲建議30幀就夠了
2）Drawcall
在了解什么是drawcall后，我們知道，過高的drawcall會導致卡頓，這里就介紹一些減少drawcall的方法：
A.查看drawcall
在layabox中，添加代碼DebugTool.showStatu = true;
B.連續渲染相同圖集里的圖，只會執行一次drawcall
C.UI上drawcall優化
優化的思路就是盡可能讓相同圖集里的圖一次性連續渲染完，舉例來說：在layabox中打開一個UI，層級窗體里看到界面里的子對象，如下圖：
我們可以看到看每一個子對象前邊，都有一個小圓點，這個圓點的顏色代表了他來自哪個圖集，相同顏色的圓點代表是同一個圖集。渲染UI時，UI上的每個子對象是按照自上而下的順序去渲染的。在不影響界面的情況下，把界面里各元件的層級調整一下，可以達到減少drawcall的目的。調整后，如圖所示：
優化前：會有6次drawcall
優化后：只有3次drawcall
D.場景上的drawcall優化
拿場景中的人物來舉例：
假設一個人物的某套裝資源在一個圖集里。
那么場景里連續渲染穿這個套裝的人物，只用1次drawcall。實際上在游戲里，穿着相同套裝的人不會理想的按順序出現。一個場景里會有許多穿着不同套裝的人物，而每個套裝在一個圖集。也就是說，場景里，渲染N個這樣的人物就需要無限接近於N次drawcall。
當每個人物還有影子，影子的資源，肯定是在不同於各個套裝資源的圖集里。
情況1：人物和影子是在同一個容器里處理，每一個容器就是一個人物，這種情況就會出現，渲染單位A，會使用兩個圖集套裝圖集+影子圖集有兩次drawcall。當渲染N個人物，就有N*2次drawcall。
情況2：把渲染影子拆出來，當渲染完所有人物后，再根據所有人物的位置，繪制影子。這種情況，渲染N個人物，只會有N+1次drawcall顯然情況2的處理方式更優。
當每個人物還有名字、稱號、血條等等元素，若這些元素是按照上面情況1的處理，那drawcall就有N*M次。把這些元素按照上面情況2的處理，顯然可以減少大量的drawcall。
E.其他減少drawcall的方法
如：減少被遮擋的單位渲染
圖集的控制
3）有較高消耗運算，特別是enterframe和for循環里面的
注意代碼邏輯優化，減少算法復雜度
4）資源加載緩存有問題/資源太零散，造成I/O過高
優化資源加載策略
5）日志打印
減少日志打印
6）限制底層繪制分辨率
2.突然大卡頓
某些不定時的操作，循環里復雜度高
可能是執行到一些復雜度高的循環處，導致突然大卡頓
協議包過大
注意協議包優化，優化方式諸如：
1.刪除不用字段
2.整合小字段
如某協議中的字段
var a:int;
var b:int;
var c:int;
假如上述a,b,c的值只會是十位數以下時，可以整合成一個字段:
var d:int;
d的每一位為ABCDEF
AB為a的值，CD為b的值，EF為c的值
比如d = 123456
那么a為12，b為34，c為56
這樣做的好處，原來需要12個字節的數據，現在只用4個字節就可以了。
3.字段類型選擇
如用int還是short
只有兩個值的情況選擇用boolean
4.盡量避免使用字符串
協議中的字符串，盡量通過ID發送
ID對應的字符串在代碼里做好映射或配置
垃圾回收負荷過重
單位是否是頻繁初始化，用完后就銷毀？
是否需要使用對象池
如果卡頓發生UI上：
面板內容初始化分幀處理
圖片和特效尺寸，圖集依賴規划是否合理
UI面板是否分頁簽
UI內特效，3D模型等次要元素延遲初始化
List優化，動態初始化，循環使用
3.持續地越來越嚴重卡頓
是否有對象/物件用完了隱藏掉，而沒有被刪除，越積越多
如：飄血、事件監聽等
內存泄漏，GC越來越頻繁
4.卡頓到閃退
內存過高，內存有泄漏
檢測是否有報錯或死循環等問題
理念二：內存為主
很多能感知的較大卡頓都是垃圾回收引起的；
內存問題往往比CPU問題更難解決，甚至需要大規模重構；
降低內存會使得游戲更加輕快，可以緩解其他較小問題。
理念三：內存使用策略比內存釋放策略更重要
關於內存使用的策略，往往在項目的初期就應該制定好，下面有幾點建議：
new對象必須由Factory或者Manager進行統一管理，這點做好了，對后期排查內存問題尤為重要；
View和Model要完全分離；
View的創建細化到每幀，根據性能情況創建；
FpsManager按照幀率動態調整閥值；
合理地運用對象池：“頻繁創建和銷毀”的“小型”對象采用對象池。
理念四：重視資源壓縮
游戲程序中，大量的內存來自於資源，合理的壓縮資源是減小內存行之有效的辦法。關於資源壓縮，這里提一些建議：
重視制定制作流程，技術標准
資源的制作不能隨心所欲，必須擁有一定的標准，例如：
原始圖片資源使用jpg還是png
是否是可以用鏡像處理的圖片資源
相似的資源是否可以統一
避免程序上使用濾鏡和灰化等
一些圖片資源上不起眼的光效或羽化效果等是否可以不用
美術字體圖片中，相同文字的拆分與組合
九宮格拉伸圖片的概念
合理優化動作、特效等資源序列幀
許多人物動作、特效等資源，美術給出的效果十分精細。在處理內存問題上，可以考慮對這些資源做如下處理：
1.抽幀
一些影響不大的關鍵幀是否可以刪除。
2.縮小再放大
一些不起眼的部位，序列幀可以按比例縮小，程序使用時，再放大。
3.砍方向
人物向左和向右的資源是否可以通過旋轉其中一個動作實現？
是否所有方向的資源都要用到？
對稱的資源砍半/四分之一鏡像使用
序列幀特效用IDE制作替代
UI全屏分辨率選擇 1024像素
icon盡量使用 64*64 的格式
使用pvrtc etc ，png8格式
UI背景使用最接近的某個2的次方的尺寸
背景圖不要打到圖集中，並且盡量用jpg
少用遮罩
音效使用單聲道
理念五：屏蔽策略
在游戲出現性能瓶頸的時候，我們不得不考慮屏蔽一些游戲內容的顯示，比如一些次要的場景單位、特效等。屏蔽必然會減弱玩家的游戲體驗，但是，比起卡頓甚至是閃退，適當的屏蔽規則是必要的。
加入屏蔽設置，性能差的時候自動開啟
屏蔽策略要覆蓋各類顯示對象
某些場景使用統一模型
理念六：不要忽略看起來小的地方
正所謂積少成多，一些看起來小的地方，卻用了不太合理的處理方式，往往也影響着游戲的性能，在《大天使之劍H5》中，我們就對如下這些地方做了些優化：
配置表數據優化
String數組方案
相似String的處理
版本號文件，采用樹形存儲減少URL字段的重復度
數值類型廣泛使用變長
解析戰報，分段解析
理念七：深入學習開發者工具的使用
在調試游戲時，我們往往要依賴開發者工具來獲悉游戲的內存變化、CPU的使用、游戲內對象的整體情況、資源的應用情況、甚至是我們關注的變量值等等。善於使用各種開發者工具能讓我們事半功倍。
使用谷歌瀏覽器的開發者工具
layabox開發的H5游戲默認是用谷歌瀏覽器調試的，這里我們稍微講下谷歌瀏覽器的開發者工具的運用。游戲運行在谷歌瀏覽器時，按F12可以打開開發者工具，他的一些常用功能有：
1.console的使用
Console的界面如上圖所示，它主要顯示着我們游戲運行時的日志等信息。每條日志的后面，有鏈接可以快速跳轉到輸出日志的代碼處，在console的下方，有輸入框功能，我們可以通過這里輸入代碼改變當前游戲內的數值、用不同方式打印日志等。
2.調試
我們可以在工具的Sources選項卡下找到我們要調試的JS，進行斷點或條件斷點調試。
3.NetWork
NetWork面板提供了有關已經下載和加載過的資源的詳細信息。
在這里我們可以很直觀的找到一些加載耗時較長的資源進行優化。
4.TimeLine
TimeLine界面中，我們可以看到關於時間開銷的完整概述。
如圖所示，通常我們在游戲性能表現差的情況下，在TimeLine界面點擊左上角的錄制按鈕，錄制一段時間后，點擊完成，它會幫我們搜集到在錄制的這段時間里，游戲每一幀的運行狀況。
綠色的幀是在幀時間內處理完需求處理的事情的。
紅色的幀是處理時間大於幀應該有的時間的，也就是卡了的幀。
我們可以重點看下紅的幀，在下邊可以看到是哪個方法占了多少時間，以及這個文件里又是調用哪些方法，分別調多少時間。
在圖中左下部分，我們還可以看到代碼邏輯和渲染的比重，可以用來判斷可以做什么優化，怎么優化。這個功能，對程序的參考決不止我提到這些，這里有很多信息幫我們分析找到問題，可以對我們優化提供很多幫助。
5.Profiles
Profiles界面中，我們可以使用快照功能。最常用的還是Take Heap Snapshot功能。它可以記錄當前內存分布的詳細信息，多張內存快照還可進行比對，分析在不同的時間點，內存具體有哪些變化。
理念八：抓大放小，先抗住再優化
沒有一個性能問題是由單一問題造成的；
單次單點修改，注意記錄便於前后對比找到關鍵問題；
調試崩潰的時候一定要注重日志，一行一行看總會找到Keyword。
轉載地址：https://mp.weixin.qq.com/s/4UUM6YBf33iOpp5jQqbGcQ
作者：哈森森
鏈接：https://www.jianshu.com/p/00913bbf3e86
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。