Cocos2d-x遊戲的性能檢測

貼一篇舊文,若是之後有更多有趣的經驗會更到原博客上:
http://galoisplusplus.coding....html

前段時間本渣負責了一些優化咱們cocos2d-x遊戲性能方面的工做,在這裏作一點記錄。node

OpenGL指標

在debug版的cocos2d-x遊戲裏,一般會在左下角顯示三個指標(固然,是否顯示這三個指標是能夠配置的):linux

  • GL verts: 繪製的頂點數量android

  • GL calls: 繪製次數git

  • FPS: 幀率github

可千萬別小看了這三個不起眼的指標,對從它們入手進行分析經常能找到一些性能問題的癥結。xcode

FPS算是其中最容易理解的指標了,這個值固然是越高越好。根據FPS咱們能夠對性能問題作一些初步判斷,肯定是在哪一個地方開始掉幀。此外,咱們每每會碰到卡幀的狀況,這時候畫面像是忽然被凍住了通常,這種狀況其實與繪製渲染無關,而是由於在同一幀的計算量過大,CPU成爲了瓶頸。針對這個問題就能夠去定位計算的部分,對它進行優化或者將它拆到多幀裏去作。性能優化

GL callsGL verts都和繪製渲染有關,不過本渣之前在學校是作GPGPU的,並不以爲這主要是GPU的性能問題,而是數據或命令在CPU和GPU間傳輸時總線(bus)的問題。當數據量過大時,總線就成爲了瓶頸。async

先說下GL calls,這個值越小越好,合理使用[auto batching]()能夠下降這一指標。最近本渣還經過這一指標意外地解決了咱們遊戲裏的幾個和UIListView相關的問題。這些問題都有一個共同點:滾動列表越滾越卡。本渣爲此作了以下測試操做:在滾動列表處於初始位置時記下當前的GL calls(比方說記爲x),在執行了若干次滾動操做後,讓滾動列表回到初始位置,記下GL calls(比方說記爲y)。此時先後二者的畫面基本一致,繪製的開銷應該也是一致的,也就是說xy應該相等(固然,若是界面上有動畫或者新加入的UI元素的話,可能會有些許誤差),然而有問題的地方y老是比x大,並且隨着滾動操做的增長而增加。這就基本能夠確認是沒釋放資源致使內存泄露了,review了下對應的代碼果真如此:quick-cocos2d-x的UIListView有所謂的async模式,與cocos2d-x的TableView類似,並不會產生列表中的全部cells,而只產生顯示區域的cells,當滾動產生新的cell時會先重用不在顯示區域的cell實例(instance),從而下降開銷;而有問題的代碼(固然是本渣的隊友小夥伴挖的坑啦,哈哈)在重用舊的cell實例時並無把沒用的UI資源釋放掉,從而致使了這一問題。雖然咱們碼農經過代碼並不難排查,可是GL calls這一指標提供了一種不須要看代碼就能定位此類問題的方式,特別適合測試人員採用。工具

最後說下GL verts,這個值也是越低越好。這裏順帶提醒下,有些人想要隱藏某些UI元素時會把它們的透明度設爲0、或者把它們徹底遮擋住,cocos2d-x對於徹底透明或者徹底被遮擋的node仍是會作繪製的,這時經過GL verts這一指標就能夠看出放不放這些「隱藏」UI元素的開銷是不一樣的了。此外還有隱式產生這一問題的狀況,例如cocostudio中放入一個帶顏色的徹底透明的Panel,須要注意避免踩坑(BTW. cocos2d-x對於帶顏色的Panel是用LayerColor類來處理的,在咱們所用的v3.2版本中,這個類的渲染代碼還會引發遊戲crash!)。固然,要下降GL verts仍是須要和美術大大溝通好的。例如美術大大絞盡腦汁出了一張很精緻的大圖,但遊戲裏用不到那麼大,還要縮放成0.3倍,這張圖不只不少細節在手機上徹底看不清,並且還增長了GL verts開銷。要避免這種狀況,仍是要團隊裏成員合做好,在美術資源方面要定好合適的大小,控制好圖片細節的精細度。

性能檢測器(Profiler)

本渣以前玩過gprof和CUDA的nvprof,深知藉助於專業的profiler能夠給性能檢測帶來許多方便,因而前段時間也花了很多精力在找cocos2d-x相關的profiler。

Android

官方文檔提到ARM的streamline工具,但本渣看下來後並無採用:一者是須要編譯內核,對於咱們這種小廠,這種可能玩壞測試機的咱們仍是玩不起的;兩者是這篇文檔很舊,當時cocos2d-x只有v2,不肯定在咱們v3.2的版本上是否能跑起來,並且本渣也沒查到其餘人在cocos2d-x v3.0以上版本試水的資料。

本渣最後用的是android-ndk-profiler,這個工具確實能正常運行併產生性能檢測報告的。在cocos2d-x項目配置android-ndk-profiler基本照着leenjewel大神這篇文章就能夠,由於leenjewel寫得很詳細,本渣的作法和他差很少,因此這裏就不贅述了。android-ndk-profiler的輸出基本和gprof同樣,若是你不知道如何分析gprof報告的話能夠參考文檔
不過android-ndk-profiler一個很大的問題是採樣:若是採樣率過低,收集到的數據可能不具備表明性;但調高採樣率每每會致使crash——像本渣就遇到過在遊戲剛啓動、畫面還沒出來時就崩潰了orz...這無疑帶來了很多麻煩,目前本渣還木有好的解決方案。

另外還有一些大神推薦高通的Adreno Profiler,本渣暫時還木有嘗試~

iOS

iOS下固然是用強大的Instruments啦!不過本渣更熟悉Instruments的內存檢測工具,以前也曾用Leaks解決了一些C++代碼的內存泄漏問題,在用Instruments作性能檢測方面暫時沒有什麼心得~

Android開發者模式的性能檢測工具

Android開發者模式裏也有許多如檢測GPU Overdraw等的工具,能夠在作Android真機調試時進行性能檢測和分析。固然,如何使用這些工具就不是本渣這裏所要討論的問題了哈~

參考資料

ARM Streamline:

android-ndk-prof

Adreno Profiler

Instruments:

相關文章
相關標籤/搜索