unity在移動設備上的優化

http://www.cnblogs.com/123ing/p/4130034.html

http://www.cnblogs.com/123ing/p/4130034.html

轉自:UNITY3d在移動設備上的一些優化實戰(一)-概述 http://blog.csdn.net/leonwei/article/details/39233921

項目進入了中期之後,就需要對程序在移動設備上的表現做分析評估和針對性的優化了,首先前期做優化,很多瓶頸沒表現出來,能做的東西不多,而且很多指標會憑預想,如果太后期做優化又會太晚,到時發現一些問題改起來返工量就有太大。前一陣子花了大量時間從 cpu gpu 內存 啓動時間 到發熱量對項目做了一翻大規模的體檢和優化,效果還是顯著的,在這裏做個筆記,以後開發項目時可以作爲經驗和提前關注

      1.項目情況:筆者所在項目是一個非常重度的手遊,甚至開始就是瞄着端遊做的,3D世界,2.5D視角,RPG,即使戰鬥,美術品質要求極高(模型 貼圖精度高 ,超過目前市場同類產品)。對於目前大多數移動設備來看,挑戰不小,對手機的各種硬件都是挑戰。、

     2.目標機型:偏中高端,儘量兼容低端,android至少sumsung S3能流暢,ios至少iphone4s流暢。

     3.性能指標:內存佔用250M以下(這樣大量512的機器不會掛掉),初始包100m之內(太多運營不幹,太少實在是裝不下。。)

 

用於分析和測試性能的一些利器:

 1.首先是unity在編輯器下的statics窗口:提供了dc和頂點數這兩個重要指標的查看。缺點在設備看不到,但是對於dc數和頂點數來說,設備和編輯器差不多,用它可以大體看出渲染的壓力。

 2.unity自帶的profiler:可以連接設備看到設備上cpu gpu mem的信息,使用的時候需要勾選development模式。有點是cpu的佔用在腳本的層面看的非常仔細,哪個函數佔用了太多時間一眼就能看出,基本是分析腳本效率的最佳工具,但是gpu大部分設備不支持看不到,顯示的mem信息不太準確,基本上偏離實際佔用的內存

3.unity的internal profiler:在playersetting上可以勾選這個選項,勾選後,連接設備,在android的adb或者mac的xcode裏會每隔幾秒打印出很多關鍵指標,這個其實非常有用,不過這個功能直到很後期才發現,詳細文檔見http://docs.unity3d.com/Manual/iphone-InternalProfiler.html

4.android上的adb:adb提供了一組非常強大的分離android程序的工具,http://developer.android.com/tools/help/adb.html

而最常用的是用adb的dumpsys 指令,https://source.android.com/devices/tech/input/dumpsys.html

最常見的包括: adb shell dumpsys meminfo appname  查看實時的內存佔用,android的內存分爲ps rs,我們一般看ps爲準,關於ps rs這些概念可參看http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android

adb shell dumpsys cpuinfo appname 查看實時的cpu佔用,注意這裏的cpu可能過百,這是因爲多核的原因

adb shell dumpsys gpuinfo appname 查看實時的gpu情況

5.android  的monitor

安裝adt後,在sdk\tools\monitor.bat下面有個monitor,是我認爲android看性能最好的工具之一,因爲它是圖形化的,而且基本集成了adb的功能,從內存到cpu到gpu,還有很有用的網絡流量使用情況,它的cpu佔用是c++層面的統計,看不到腳本,這需要突破那個profilor結合。

6.android上的mongkey測試:它可以模擬隨機的用戶輸入,用來驗證你的程序的強壯性吧

adb shell monkey -p -v packname 1000
隨機模擬1000條用戶事件

7.ios:ios上的工具則顯得更加專業更加統一一些,ios就用xcode自帶的instruments了

這裏有個詳細的文檔https://developer.apple.com/library/mac/documentation/developertools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html

看來這麼多工具,其實很多是要配合使用的,做u3d開發,其實不只是學會U3D的事情,要讓U3D在手機上運行的好,還需要對各個平臺有較深的瞭解。

 

 利用這些工具法線了一些瓶頸,同時也採取了各種策略來提高性能,反正目標就是cpu佔用降低,內存佔用減少,啓動快,發熱小,幀率高,GPU佔用少,發現的一些問題和做出的具體的一些努力列舉如下:

1.使用assetbundle,實現資源分離和共享,將內存控制到200m之內,同時也可以實現資源的在線更新

2.頂點數對渲染無論是cpu還是gpu都是壓力最大的貢獻者,降低頂點數到8萬以下,fps穩定到了30幀左右

3.只使用一盞動態光,不是用陰影,不使用光照探頭

粒子系統是cpu上的大頭

 

4.剪裁粒子系統
 
5.合併同時出現的粒子系統
6.自己實現輕量級的粒子系統
animator也是一個效率奇差的地方
7.把不需要跟骨骼動畫和動作過渡的地方全部使用animation,控制骨骼數量在30根以下
8.animator出視野不更新
9.刪除無意義的animator
10.animator的初始化很耗時(粒子上能不能儘量不用animator)
11.除主角外都不要跟骨骼運動apply root motion
 
12.絕對禁止掉那些不帶剛體帶包圍盒的物體(static collider )運動
 
NUGI的代碼效率很差,基本上runtime的時候對cpu的貢獻和render不相上下
13每幀遞歸的計算finalalpha改爲只有初始化和變動時計算
14去掉法線計算
15不要每幀計算viewsize 和windowsize
16filldrawcall時構建頂點緩存使用array.copy
17.代碼剪裁:使用strip level ,使用.net2.0 subset
18.儘量減少smooth group
19.給美術定一個嚴格的經過科學驗證的美術標準,並在U3D裏面配以相應的檢查工具
 
後面的文章會對這些點做以更詳細的討論

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章