使用Cocos2d-JS製做遊戲新手引導(三)源碼篇

近期遊戲準備出安卓版本,在安卓上的性能表現不佳。通過一週多的優化,在性能上取得了較大的提高。遊戲採用 Cocos2d-x 3.2 + Lua 進行開發,如下將在渲染效率,CPU效率,包大小等方面進行總結。python


渲染效率
算法

紋理格式 – 運行效率 內存 包大小json

  • 全部的圖片都經過一個python腳本(調用TexturePacker的命令行工具)自動轉換爲RGBA4444編碼的格式。而後判斷當前平臺爲安卓時,將默認紋理格式轉換爲RGBA4444。緩存

1
2
3
4
--安卓啓用4444紋理
if  targetPlatform == cc.PLATFORM_OS_ANDROID then
     cc.Texture2D:setDefaultAlphaPixelFormat(cc.TEXTURE2_D_PIXEL_FORMAT_RGB_A4444)
end
  • 以上的過程會發現一種比較」反常」的現象,就是轉成RGBA4444的圖片要比原來的圖片要大。因此在腳本中不能單純的轉換,須要對比轉換先後的大小,只轉換變得更小的圖片。app

  • 還須要注意性能和表現的平衡。有些圖片轉成RGBA4444後看起來太糙,嚴重的影響了遊戲的視覺體驗。對此須要當心的針對處理。處理方法爲,在這些紋理使用前將默認紋理格式設置爲RGBA8888,而後當紋理使用後再將設置爲以前的默認紋理格式。異步

    Alt textAlt text

    左圖是沒有作處理的遊戲截圖,可見至關不平滑的光線和背景。 右圖是隻針對背景和光暈的紋理設爲RGBA8888處理,視覺體驗一會兒就回歸了。函數

  • 壓縮成RGBA4444格式的PNG圖片,還能夠用pngquant工具進一步壓縮,而視覺體驗肉眼感覺幾乎沒有變化。這樣能夠進一步的減小包的大小。工具

  • RGBA4444的紋理內存使用量要比默認的RGBA8888小一半,因此能夠很大的減輕遊戲的內存壓力。並且和PVR ETC等壓縮紋理想比,能夠一套代碼,徹底兼容iOS和Android兩大移動平臺。因此我認爲性價比仍是很高的。性能

紋理剪裁 – 內存 包大小優化

  • 遊戲採用CocoStudio來製做骨骼動畫。CocoStudio導出的骨骼動畫導出的圖片默認是POT(power of two)大小的。其實會形成不少空白像素的浪費,這些空白像素不只會讓圖片變大,還會增長紋理的內存。

  • 具體辦法是:將導出的POT圖片,通過美術或工具的剪裁掉多餘的空白像素,使之變成NPOT(non power of two),而後修改一下plist文件中<texture>中的width和height值。對實際的使用是沒有任何影響的。

  • 經過把全部POT格式的圖片裁剪爲NPOT,不只能夠縮減圖片的體積,還能減小紋理的內存佔用。

DrawCall OverDraw

  • 在同事對整個包進行DrawCall和OverDraw分析後發現,消除場景內還保留着天空背景。而這層背景實際是玩家看不到,由於它徹底被消除場景擋住了。可是它會帶來全屏的繪製形成了全屏範圍的OverDraw,並且帶來了不少額外沒必要要的DrawCall。將其隱藏後,FPS在低端機上提高明顯。

  • 須要把這些看不到的東西所有隱藏或移除掉,不然它們會形成OverDraw和沒必要要的DrawCall,增長了GPU的負擔。

  • 隱藏的辦法,有些童鞋喜歡將其透明度設爲0,可是這樣是不會下降DrawCall的。最好的方法是將其visble設爲false。

  • 還有就是場景內有不少細碎的東西,若是它們都是一張張散圖儲存的話,會使DrawCall居高不下,從而可能致使FPS降低。why are draw calls expensive?

  • 解決辦法就是儘量的將常常一塊兒出如今屏幕上的小圖合併成一張大圖


CPU計算

  • 避免在循環內作重複的運算。由於若是計算值在整個循環內都不會變的話,那麼每次循環都去計算就是浪費CPU週期,應該將計算結果緩存在循環外部。

  • 想辦法避免開銷大的函數(如:開方函數,三角函數),尋找簡單運算的替代方案。如:距離的比較能夠不用開方先求出距離,而是直接用平方運算進行比較便可。

  • 儘量的避免同時多個的cc.RepeatForever。在低端機上發如今對較多對象調用cc.RepeatForever時,FPS降低顯著。緣由多是每幀帶來的計算,和所以頻繁觸發的Lua GC。GC是很一個十分耗費CPU的操做。

  • 優化算法,剪枝,去除冗餘的計算。在遊戲內的碰撞系統是這麼進行優化的:原來對每個球,會遍歷整個空間的碰撞體和牆壁進行碰撞檢測;優化後的算法是取球當前的座標,轉換爲格子座標,而後取格子周邊6個格子內的碰撞體和牆壁進行碰撞檢測。效率提升了不少倍。

  • 避免頻繁的開闢內存,對象最好實現複用。開闢內存也是一項很耗費CPU的操做,尤爲是在移動設備上內存緊張時。對象能重用盡可能重用(創建對象池)。Lua內的表能初始化大小,儘可能先初始化大小,不然rehash的操做很費時。如何編寫高性能的Lua代碼

  • 用效率更高的庫來替換,好比用cJson來替換Lua json,用pugixml來替代tinyxml2。或者將效率低的模塊嘗試用更低級的語言進行重寫。

  • 出包時,關掉全部的print語句和cclog語句。大家都知道輸出到緩衝區的log有多卡。


其餘

異步加載

  • 預測即將用到的紋理和資源,將其進行異步加載。這樣能在用到時,減小掉紋理加載的時間,感受上會更流暢一些。

移除不用的庫

    • 因爲引擎使用的是Cocos2d-x 3.2版本,因此沒有3.3帶來的模塊精簡的功能。可是咱們也能夠本身去當心翼翼的移除掉遊戲根本不會用到的模塊。好比:物理引擎,3d模塊,CocosBuilder spine等等。

    • 具體的方法是:經過adt的打包日誌,分析有哪些庫被編譯進最終的so文件中,而後去項目內一個一個搜索這些庫的名稱。找到其對應的Android.mk文件,而後嘗試移除掉無用庫文件,而後嘗試編譯,確保遊戲能正確運行。

相關文章
相關標籤/搜索