NO IMAGE

一、CPU效能優化

1、減少重複計算

  • 換高效的演算法
  • 避免多次運算, 例如減少迴圈中計算
  • 利用空間換時間,將常用運算結果快取

2、合理使用資料結構

不同資料結構的增刪改查消耗得效能是不同的,合理利用資料結構,避免計算上的浪費。

3、減少複雜呼叫

  • 將輪詢方式修改為事件驅動,比如將在update中狀態監聽,改為事件觸發
  • 將節點遞迴更新修改為有效路徑更新,例如UI樹
  • 不同物件和狀態有不同的邏輯幀數,比如小兵的邏輯幀數有60幀,而建造中的建築邏輯幀只有10幀
  • 降低耗時運算,例如深度排序和視野計算都可以降低到一般人覺察不到的頻率
  • 預處理結果,比如在遊戲啟動階段或者loading階段預先計算
  • 拆分運算量,比如載入200個建築,可以拆分到多個幀去完成。接收到大量的伺服器包也可以同樣這樣處理,防止卡頓。
  • 按需載入,比如只載入一個建築的某一方向的資源
  • 非同步運算,如多執行緒收發訊息包,多執行緒載入資源,非同步解壓,非同步渲染

4、丟棄部分效果

  • 丟棄部分效果,減少戰鬥特效
  • 自動動態調整FPS,以低幀率效能消耗表現高幀率效果

二、記憶體效能優化

記憶體效能原因主要有這幾點:記憶體碎片過多 、記憶體頻繁建立銷燬、記憶體載入慢、記憶體佔用過高。

1、使用記憶體池,減少記憶體碎片

使用一個全域性的記憶體池,所有物件的分配和回收都由記憶體池來控制。

2、採用物件池,減少頻繁建立銷燬

遊戲在場景切換時,需要銷燬和建立大量的建築,因此,將建立出的建築使用物件池來進行管理,建立建築時會先從池子裡面取,臨時不使用的建築會根據池子大小選擇回池或者銷燬。

物件池適用於頻繁建立和銷燬的物件,現在大部分遊戲都有自己的物件快取機制,例如打飛機遊戲中的滿屏的子彈和敵機,酷跑遊戲中的金幣。有關物件池的介紹請自行谷歌。

3、及時釋放無效記憶體

  • UI介面關閉時,場景切換時釋放
  • 採用LRU動態淘汰快取

三、資源優化

  • 圖片壓縮,ios為pvr,android為etc1,考慮方形圖和alhpa貼圖,記憶體佔用大概是原來的1/4左右。
  • 表格壓縮,非常用的表格資料使用lzma格式壓縮,在使用時才進行解壓縮,對字串效果特別好
  • 指令碼壓縮
  • 九宮格圖片
  • 降低模型面數
  • 減少幀動畫幀數
  • 沒有Alpha通道的圖片使用jpg替換

四、GPU優化

1、減少渲染批次

cocos 的 auto-batching 只會對render queue 相鄰且同材質的 command 進行合併。因此在拼UI時儘量讓相同的控制元件相鄰。

2、使用render to texture

對UI這種不常更新的元素,可以將其渲染到一張貼圖上,這樣整個介面就只有一個drawcall,僅當UI發生變化時才重新生成。

五、IO優化

  • 壓縮,pvr和etc可以直接被GPU讀取
  • 預載入,將用到的資源在loading階段載入,壞處是有些資源可能極少被使用到,白白佔用記憶體
  • 非同步載入,但當載入量過大時仍會造成卡頓
  • 大檔案支援按需部分讀取
  • 資源整合打包,避免過多小檔案操作。現在大部分遊戲的UI資源都採用打包成大圖,一是可以減少IO,二是可以利用工具裁剪圖片的空白區域
  • 將解析複雜的資料轉化成易於讀取的二進位制資料

六、網路優化

手遊網路存的問題是網路流量有限和是網路波動大,經常中斷。

  • 合併小包,減少傳送請求頻率。
  • 合理的資料結構定義,儘量使用佔用少的資料結構,能用bool、char就不要用int
  • 網路包壓縮
  • 伺服器網路包合併下發,客戶端分幀解析,防止大量網路包解析時出現卡頓
  • 手遊網路不穩定,因此需要有自動重連與協議重發機制,提供較為順暢的遊戲體驗
  • 合理的互動方式設計(避免頻繁互動的方案),比如客戶端和伺服器使用相同的演算法進行展示,或者讓客戶端進行演算,而伺服器只是做檢驗

七、耗電優化

  • 丟棄部分效果,丟棄特效降幀
  • 降低亮度