經驗談:遊戲性能優化的一些經驗之談

最近談瞭許多Unity相關的東西,這篇博文就將一些更加寬泛的東西,算是這段時間裡遊戲開發的一些經驗的總結吧。

優化概論

說起遊戲的優化,在遊戲開發中經常分為這幾步:

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

遊戲開發中一定是先做工具,進行Profile,再進行優化,所以,說優化就不得不再扯一下Profile

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

另外一些工具,就需要根據遊戲的需求去編寫瞭,比如一鍵關閉所有特效,一鍵更改分辨率等等,一鍵設置場上NPC數量,簡單的遊戲如啪啪三國是做成快捷鍵開啟Profile功能的,更為復雜的遊戲如神秘海域則是通過遊戲內控制臺來進行更為細致的Profie。

接著,我們再來說說遊戲優化中主要的四個考慮方向:

01

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)。最終使得以上這四個方面能達到均衡即可,切忌在某一方面優化過頭,又引發其他方面的問題,此消彼長的情況下,有時反而不如不做優化。

from:王選易的博客

Comments are closed.