遊戲開發性能優化經驗總結

優化概論

提及遊戲的優化，在遊戲開發中常常分爲這幾步：

1. 首先要肯定遊戲中常常會出現哪些問題 – Profile
2. 而後肯定在哪些方向進行性能優化 – Analyze
3. 最後再儘量將問題逐個解決 – Solve

遊戲開發中必定是先作工具，進行Profile，再進行優化，因此，說優化就不得再也不扯一下Profile

常見的工具備一些是引擎和IDE自帶的，好比Unity自帶的Profiler，就包含了CPU，GPU，Memory等等各式各樣的性能分析工具，其餘的好比GPA，Xcode Instrument和Visual Studio，Intel自帶的內存管理工具在必要的時候也使須要去學習和使用的。

另一些工具，就須要根據遊戲的需求去編寫了，好比一鍵關閉全部特效，一鍵更改分辨率等等，一鍵設置場上NPC數量，簡單的遊戲如啪啪三國是作成快捷鍵開啓Profile功能的，更爲複雜的遊戲如神祕海域則是經過遊戲內控制檯來進行更爲細緻的Profie。

接着，咱們再來講說遊戲優化中主要的四個考慮方向：

CPU

引起的問題：

• 因爲短期內的計算量太大，致使畫面流暢性下降，俗稱跳幀
• 發熱嚴重，耗電量高

常見的優化手段：

• 將計算分到多個邏輯幀中進行計算，避免短期內的性能超過負荷，俗稱「分幀」（time-slice）。
• 將能夠緩存的數據儘量的緩存起來，避免重複計算和重複分配內存，常見的示例爲「內存池」。
• 使用合理的算法和數據結構，好比：冒泡排序和直接插入排序在總體數組比較有序的狀況下效率大大好於快速排序。把快排替換成是優化程序排序效率的一個常見的思路。

GPU

引起的問題：

• 發熱嚴重，耗電量高
• FPS下降

常見的優化手段：

• 優化美術資源，好比合理規劃圖集，約定好模型的最大三角形面數，制定合理的粒子效果規範。這個能夠說是遊戲優化中最重要的一個，所以，技術美術在遊戲開發中做用巨大。
• 簡化或者優化着色器（shader），如在遊戲開始前就對Shader進行編譯和加載。
• 使用Batching，儘可能減小DrawCall
• 使用平臺推薦的壓縮格式，好比安卓平臺的ETC1和IOS平臺的PVRTC

IO和網絡

引起的問題：

• 網絡延遲甚至掉線
• 加載資源致使的跳幀
• 加載時間過長

常見的優化手段：

• 使用獨立的線程進行加載，有些引擎如Unity中還能利用協程
• 減小網絡包裏面的冗餘數據
• 合併小包，減小請求數據的次數
• 分幀對回包進行處理
• 限制必定時間內的發包頻率

內存

引起的問題：

• 閃退和卡死，好比安卓的Low Memory Killer會在低內存狀況下殺掉內存佔用過大的程序。

常見的優化手段

• 動態加載和卸載資源，好比在遊戲內的時候，咱們能夠把遊戲外的一些UI圖集卸載掉。
• 下降資源質量或屏幕分辨率，這是有損優化，通常做爲最後的手段

對作過項目的一些思考

須要關注非功能性需求

這一點思考是我從爲何不少看起來不是很複雜的網站，好比 Facebook 須要大量頂尖高手來開發？這個答案中想到的，正如這位答主所說：

事實上，從個人經驗來看，通常來講，不少軟件項目及產品，其在非功能性需求上的成本，難度和工做量，是要超過功能性需求的。在特定的軟件領域，例如網站（尤爲是淘寶，facebook這樣海量用戶規模的網站），金融（銀行證券），電信領域，其非功能性需求實現的重要性，工做量，技術難度要遠遠遠遠大於功能性需求的實現。並且，功能性的需求的實現，其實在大多數狀況下，更依賴於業務的高手（或者好的產品經理）而不是技術的高手，而非功能性需求的實現，偏偏是挑戰技術高手的重要課題。

在遊戲前端這邊作了一段時間，你們都在抱怨遊戲前端技術含量低，只能寫業務邏輯，可是其中的陷阱就是，做爲前端，你應當儘可能少寫業務邏輯，你關注過一下的模塊嗎？

• 性能：你有沒有在本身的遊戲中進行Profile，觀察在以上各個參數有沒有達到指標
• 安全：你的遊戲前端代碼的Release版本是否還能被別人輕易反編譯，你的遊戲是否還能輕易被玩家截取網絡包或修改內存數據
• 可測試性：你的前端代碼能不能進行單元測試，能不能在QA測試以前就把Model層的全部bug解決掉
• 數據驅動：你能不能作出更優秀的工具來給美術和策劃使用，解放他們的生產力？

須要善於劃定範圍，縮小問題區間

我在過去幾個月裏，參加了全民突擊和崩壞學園2兩個Unity3D項目的開發，也遇到了一些性能優化相關的問題，在程序出現問題時，不少時候咱們會經過所謂的「經驗」去解決問題，好比，上面提到的安全問題，有些開發者就會提早意識到安全的重要性，在遊戲推出市場前選擇加密這種安全有效的方法，崩壞學園就及時採起了愛加密的遊戲加密解決方案，保證了安全性！其實這種Quick Link的能力天然是很是重要，但經驗並不是萬能。

可是從另外一方面來說，當咱們沒法從本身過往的經驗中找到答案的時候，咱們就要經過劃分範圍，縮小問題區間來解決問題了，許多人每每只是在本身的經驗中死守一個局部的視野去處理問題，最後的結果就必定不能盡如人意。

總結

其實這四個方面的優化老是相互制衡的，你把一個方面的優化作好了，另外一個方面的問題又會出現了，好比，咱們若是使用動態加載和卸載資源，這就雖然減小了內存佔用量，會在IO上形成加載時間延長的問題。

因此，咱們在作遊戲優化的時候，不能太追求完美，剛恰好就是真的好（Good Enough Is Fine）。最終使得以上這四個方面能達到均衡便可，切忌在某一方面優化過頭，又引起其餘方面的問題，此消彼長的狀況下，有時反而不如不作優化。