項(xiàng)目的性能優(yōu)化主要圍繞CPU、GPU和內(nèi)存三大方面進(jìn)行。本文和大家分享內(nèi)存方面的優(yōu)化心得。
無論是游戲還是VR應(yīng)用,內(nèi)存管理都是其研發(fā)階段的重中之重。然而,在我們測評(píng)過的大量項(xiàng)目中,90%以上的項(xiàng)目都存在不同程度的內(nèi)存使用問題。就目前基于Unity引擎開發(fā)的移動(dòng)游戲和移動(dòng)VR游戲而言,內(nèi)存的開銷無外乎以下三大部分:
資源內(nèi)存占用;
引擎模塊自身內(nèi)存占用;
托管堆內(nèi)存占用。
如果您的項(xiàng)目存在內(nèi)存問題,一定逃不出以上三種情況。今天,我們就這三種情況逐一進(jìn)行解釋。
1、資源內(nèi)存占用
在一個(gè)較為復(fù)雜的大中型項(xiàng)目中,資源的內(nèi)存占用往往占據(jù)了總體內(nèi)存的70%以上。因此,資源使用是否恰當(dāng)直接決定了項(xiàng)目的內(nèi)存占用情況。一般來說,一款游戲項(xiàng)目的資源主要可分為如下幾種:紋理(Texture)、網(wǎng)格(Mesh)、動(dòng)畫片段(AnimationClip)、音頻片段(AudioClip)、材質(zhì)(Material)、著色器(Shader)、字體資源(Font)以及文本資源(Text Asset)等等。其中,紋理、網(wǎng)格、動(dòng)畫片段和音頻片段則是最容易造成較大內(nèi)存開銷的資源。
一、紋理
紋理資源可以說是幾乎所有游戲項(xiàng)目中占據(jù)最大內(nèi)存開銷的資源。一個(gè)6萬面片的場景,網(wǎng)格資源最大才不過10MB,但一個(gè)2048x2048的紋理,可能直接就達(dá)到16MB。因此,項(xiàng)目中紋理資源的使用是否得當(dāng)會(huì)極大地影響項(xiàng)目的內(nèi)存占用。
那么,紋理資源在使用時(shí)應(yīng)該注意哪些地方呢?
(1) 紋理格式
紋理格式是研發(fā)團(tuán)隊(duì)最需要關(guān)注的紋理屬性。因?yàn)樗粌H影響著紋理的內(nèi)存占用,同時(shí)還決定了紋理的加載效率。一般來說,我們建議開發(fā)團(tuán)隊(duì)盡可能根據(jù)硬件的種類選擇硬件支持的紋理格式,比如Android平臺(tái)的ETC、iOS平臺(tái)的PVRTC、Windows PC上的DXT等等。因此,我們在UWA測評(píng)報(bào)告中,將紋理格式進(jìn)行詳細(xì)羅列,以便開發(fā)團(tuán)隊(duì)進(jìn)行快速查找,一步定位。
在使用硬件支持的紋理格式時(shí),你可能會(huì)遇到以下幾個(gè)問題:
色階問題
由于ETC、PVRTC等格式均為有損壓縮,因此,當(dāng)紋理色差范圍跨度較大時(shí),均不可避免地造成不同程度的“階梯”狀的色階問題。因此,很多研發(fā)團(tuán)隊(duì)使用RGBA32/ARGB32格式來實(shí)現(xiàn)更好的效果。但是,這種做法將造成很大的內(nèi)存占用。比如,同樣一張1024x1024的紋理,如果不開啟Mipmap,并且為PVRTC格式,則其內(nèi)存占用為512KB,而如果轉(zhuǎn)換為RGBA32位,則很可能占用達(dá)到4MB。所以,研發(fā)團(tuán)隊(duì)在使用RGBA32或ARGB32格式的紋理時(shí),一定要慎重考慮,更為明智的選擇是盡量減少紋理的色差范圍,使其盡可能使用硬件支持的壓縮格式進(jìn)行儲(chǔ)存。
ETC1 不支持透明通道問題
在Android平臺(tái)上,對(duì)于使用OpenGL ES 2.0的設(shè)備,其紋理格式僅能支持ETC1格式,該格式有個(gè)較為嚴(yán)重的問題,即不支持Alpha透明通道,使得透明貼圖無法直接通過ETC1格式來進(jìn)行儲(chǔ)存。對(duì)此,我們建議研發(fā)團(tuán)隊(duì)將透明貼圖盡可能分拆成兩張,即一張RGB24位紋理記錄原始紋理的顏色部分和一張Alpha8紋理記錄原始紋理的透明通道部分。然后,將這兩張貼圖分別轉(zhuǎn)化為ETC1格式的紋理,并通過特定的Shader來進(jìn)行渲染,從而來達(dá)到支持透明貼圖的效果。該種方法不僅可以極大程度上逼近RGBA透明貼圖的渲染效果,同時(shí)還可以降低紋理的內(nèi)存占用,是我們非常推薦的使用方式。
當(dāng)然,目前已經(jīng)有越來越多的設(shè)備支持了OpenGL ES 3.0,這樣Android平臺(tái)上你可以進(jìn)一步使用ETC2甚至ASTC,這些紋理格式均為支持透明通道且壓縮比更為理想的紋理格式。如果你的游戲適合人群為中高端設(shè)備用戶,那么不妨直接使用這兩種格式來作為紋理的主要存儲(chǔ)格式。
(2)紋理尺寸
一般來說,紋理尺寸越大,則內(nèi)存占用越大。所以,盡可能降低紋理尺寸,如果512x512的紋理對(duì)于顯示效果已經(jīng)夠用,那么就不要使用1024x1024的紋理,因?yàn)楹笳叩膬?nèi)存占用是前者的四倍。因此,我們在UWA測評(píng)報(bào)告中,將紋理的尺寸進(jìn)行詳細(xì)展示,以便開發(fā)團(tuán)隊(duì)進(jìn)行快速檢測。
(3) Mipmap功能
Mipmap旨在有效降低渲染帶寬的壓力,提升游戲的渲染效率。但是,開啟Mipmap會(huì)將紋理內(nèi)存提升1.33倍。對(duì)于具有較大縱深感的3D游戲來說,3D場景模型和角色我們一般是建議開啟Mipmap功能的,但是在我們的測評(píng)項(xiàng)目中,經(jīng)常會(huì)發(fā)現(xiàn)部分UI紋理也開啟了Mipmap功能。這其實(shí)就沒有必要的,絕大多數(shù)UI均是渲染在屏幕最上層,開啟Mipmap并不會(huì)提升渲染效率,反倒會(huì)增加無謂的內(nèi)存占用。因此,建議研發(fā)團(tuán)隊(duì)在UWA的測評(píng)報(bào)告中通過Mipmap一項(xiàng)進(jìn)行排序,詳細(xì)檢測開啟Mipmap功能的資源是否為UI資源。
(4) Read & Write
一般情況下,紋理資源的“Read & Write”功能在Unity引擎中是默認(rèn)關(guān)閉的。但是,我們?nèi)匀辉陧?xiàng)目深度優(yōu)化時(shí)發(fā)現(xiàn)了不少項(xiàng)目的紋理資源會(huì)開啟該選項(xiàng)。對(duì)此,我們建議研發(fā)團(tuán)隊(duì)密切關(guān)注紋理資源中該選項(xiàng)的使用,因?yàn)殚_啟該選項(xiàng)將會(huì)使紋理內(nèi)存增大一倍。
二、網(wǎng)格
網(wǎng)格資源在較為復(fù)雜的游戲中,往往占據(jù)較高的內(nèi)存。對(duì)于網(wǎng)格資源來說,它在使用時(shí)應(yīng)該注意哪些方面呢?
Normal、Color和Tangent
在我們深度優(yōu)化過的大量項(xiàng)目中,Mesh資源的數(shù)據(jù)中經(jīng)常會(huì)含有大量的Color數(shù)據(jù)、Normal數(shù)據(jù)和Tangent數(shù)據(jù)。這些數(shù)據(jù)的存在將大幅度增加Mesh資源的文件體積和內(nèi)存占用。其中,Color數(shù)據(jù)和Normal數(shù)據(jù)主要為3DMax、Maya等建模軟件導(dǎo)出時(shí)設(shè)置所生成,而Tangent一般為導(dǎo)入引擎時(shí)生成。
更為麻煩的是,如果項(xiàng)目對(duì)Mesh進(jìn)行Draw Call Batching操作的話,那么將很有可能進(jìn)一步增大總體內(nèi)存的占用。比如,100個(gè)Mesh進(jìn)行拼合,其中99個(gè)Mesh均沒有Color、Tangent等屬性,剩下一個(gè)則包含有Color、Normal和Tangent屬性,那么Mesh拼合后,CombinedMesh中將為每個(gè)Mesh來添加上此三個(gè)頂點(diǎn)屬性,進(jìn)而造成很大的內(nèi)存開銷。正因如此,我們在UWA測評(píng)報(bào)告中為每個(gè)Mesh展示了其Normal、Color和Tangent屬性的具體使用情況,研發(fā)團(tuán)隊(duì)可以直接針對(duì)每種屬性進(jìn)行排序查看,直接定位出現(xiàn)冗余數(shù)據(jù)的資源。
一般來說這些數(shù)據(jù)主要為Shader所用,來生成較為酷炫的效果。所以,建議研發(fā)團(tuán)隊(duì)針對(duì)項(xiàng)目中的網(wǎng)格資源進(jìn)行詳細(xì)檢測,查看該模型的渲染Shader中是否需要這些數(shù)據(jù)進(jìn)行渲染。
限于篇幅,我們今天只針對(duì)紋理和網(wǎng)格資源進(jìn)行詳細(xì)介紹,對(duì)于動(dòng)畫片段、音頻片段等其他資源,建議您直接通過UWA測評(píng)報(bào)告中進(jìn)行查看。
2、引擎模塊自身占用
引擎自身中存在內(nèi)存開銷的部分紛繁復(fù)雜,可以說是由巨量的“微小”內(nèi)存所累積起來的,比如GameObject及其各種Component(最大量的Component應(yīng)該算是Transform了)、ParticleSystem、MonoScript以及各種各樣的模塊Manager(SceneManager、CanvasManager、PersistentManager等)...
一般情況下,上面所指出的引擎各組成部分的內(nèi)存開銷均比較小,真正占據(jù)較大內(nèi)存開銷的是這兩處:WebStream 和 SerializedFile。其絕大部分的內(nèi)存分配則是由AssetBundle加載資源所致。簡單言之,當(dāng)您使用new WWW或CreateFromMemory來加載AssetBundle時(shí),Unity引擎會(huì)加載原始數(shù)據(jù)到內(nèi)存中并對(duì)其進(jìn)行解壓,而WebStream的大小則是AssetBundle原始文件大小 + 解壓后的數(shù)據(jù)大小 + DecompressionBuffer(0.5MB)。同時(shí),由于Unity 5.3版本之前的AssetBundle文件為LZMA壓縮,其壓縮比類似于Zip(20%-25%),所以對(duì)于一個(gè)1MB的原始AssetBundle文件,其加載后WebStream的大小則可能是5~6MB,因此,當(dāng)項(xiàng)目中存在通過new WWW加載多個(gè)AssetBundle文件,且AssetBundle又無法及時(shí)釋放時(shí),WebStream的內(nèi)存可能會(huì)很大,這是研發(fā)團(tuán)隊(duì)需要時(shí)刻關(guān)注的。
對(duì)于SerializedFile,則是當(dāng)你使用LoadFromCacheOrDownload、CreateFromFile或new WWW本地AssetBundle文件時(shí)產(chǎn)生的序列化文件。
對(duì)于WebStream和SerializedFile,你需要關(guān)注以下兩點(diǎn):
是否存在AssetBundle沒有被清理干凈的情況。開發(fā)團(tuán)隊(duì)可以通過Unity Profiler直接查看其使用具體的使用情況,并確定Take Sample時(shí)AssetBundle的存在是否合理;
對(duì)于占用WebStream較大的AssetBundle文件(如UI Atlas相關(guān)的AssetBundle文件等),建議使用LoadFromCacheOrDownLoad或CreateFromFile來進(jìn)行替換,即將解壓后的AssetBundle數(shù)據(jù)存儲(chǔ)于本地Cache中進(jìn)行使用。這種做法非常適合于內(nèi)存特別吃緊的項(xiàng)目,即通過本地的磁盤空間來換取內(nèi)存空間。
3、托管堆內(nèi)存占用
對(duì)于目前絕大多數(shù)基于Unity引擎開發(fā)的項(xiàng)目而言,其托管堆內(nèi)存是由Mono分配和管理的?!巴泄堋?的本意是Mono可以自動(dòng)地改變堆的大小來適應(yīng)你所需要的內(nèi)存,并且適時(shí)地調(diào)用垃圾回收(Garbage Collection)操作來釋放已經(jīng)不需要的內(nèi)存,從而降低開發(fā)人員在代碼內(nèi)存管理方面的門檻。
但是這并不意味著研發(fā)團(tuán)隊(duì)可以在代碼中肆無忌憚地開辟托管堆內(nèi)存,因?yàn)槟壳癠nity所使用的Mono版本存在一個(gè)很嚴(yán)重的問題,即:Mono的堆內(nèi)存一旦分配,就不會(huì)返還給系統(tǒng)。這意味著Mono的堆內(nèi)存是只升不降的。舉個(gè)例子,項(xiàng)目運(yùn)行時(shí),在場景A中開辟了60MB的托管堆內(nèi)存,而到下一場景B時(shí),只需要使用20MB的托管堆內(nèi)存,那么Mono中將會(huì)存在40MB空閑的堆內(nèi)存,且不會(huì)返還給系統(tǒng)。這是我們非常不愿意看到的現(xiàn)象,因?yàn)閷?duì)于游戲(特別是移動(dòng)游戲)來說,內(nèi)存的占用可謂是寸土寸金的,讓Mono毫無必要地鎖住大量的內(nèi)存,是一件非常浪費(fèi)的事情。所以,我們在UWA測評(píng)報(bào)告中,為研發(fā)團(tuán)隊(duì)統(tǒng)計(jì)了測試過程中累積的函數(shù)堆內(nèi)存分配量,大家只需要通過查看堆內(nèi)存分配Top10的函數(shù),即可快速對(duì)其底層代碼實(shí)現(xiàn)進(jìn)行查看,定位是否有分配不必要堆內(nèi)存的代碼存在。
讀到這里,你可能會(huì)產(chǎn)生這樣的疑問:我知道了哪些函數(shù)的堆內(nèi)存分配大了,但是我該如何去進(jìn)一步定位不必要的堆內(nèi)存呢?
這是我們經(jīng)常遇到的問題,所以在我們的深度項(xiàng)目優(yōu)化服務(wù)中,我們都會(huì)直接進(jìn)駐到項(xiàng)目團(tuán)隊(duì),現(xiàn)場查看項(xiàng)目代碼并對(duì)問題代碼進(jìn)行定位。在經(jīng)過了大量的深度檢測后,我們發(fā)現(xiàn)用戶不必要的堆內(nèi)存分配主要來自于以下幾個(gè)方面:
高頻率地 New Class/Container/Array等。研發(fā)團(tuán)隊(duì)切記不要在Update、FixUpdate或較高調(diào)用頻率的函數(shù)中開辟堆內(nèi)存,這會(huì)對(duì)你的項(xiàng)目內(nèi)存和性能均造成非常大的傷害。做個(gè)簡單的計(jì)算,假設(shè)你的項(xiàng)目中某一函數(shù)每一幀只分配100B的堆內(nèi)存,幀率是1秒30幀,那么1秒鐘游戲的堆內(nèi)存分配則是3KB,1分鐘的堆內(nèi)存分配就是180KB,10分鐘后就已經(jīng)分配了1.8MB。如果你有10個(gè)這樣的函數(shù),那么10分鐘后,堆內(nèi)存的分配就是18MB,這期間,它可能會(huì)造成Mono的堆內(nèi)存峰值升高,同時(shí)又可能引起了多次GC的調(diào)用。在我們的測評(píng)項(xiàng)目中,一個(gè)函數(shù)在10分鐘內(nèi)分配上百M(fèi)B的情況比比皆是,有時(shí)候甚至?xí)峙渖螱B的堆內(nèi)存。
Log輸出。我們發(fā)現(xiàn)在大量的項(xiàng)目中,仍然存在大量Log輸出的情況。建議研發(fā)團(tuán)隊(duì)對(duì)自身Log的輸出進(jìn)行嚴(yán)格的控制,僅保留關(guān)鍵Log,以避免不必要的堆內(nèi)存分配。對(duì)此,我們在UWA測評(píng)報(bào)告中對(duì)Log的輸出進(jìn)行了詳細(xì)的檢測,不僅提供詳細(xì)的性能開銷,同時(shí)占用Log輸出的調(diào)用路徑。這樣,研發(fā)團(tuán)隊(duì)可直接通過報(bào)告定位和控制Log的輸出。
UIPanel.LateUpdate。這是NGUI中CPU和堆內(nèi)存開銷最大的函數(shù)。它本身只是一個(gè)函數(shù),但NGUI的大量使用使它逐漸成為了一個(gè)不可忽視規(guī)則。該函數(shù)的堆內(nèi)存分配和自身CPU開銷,其根源上是一致的,即是由UI網(wǎng)格的重建造成。
關(guān)于代碼堆內(nèi)存分配的注意點(diǎn)還有很多,比如String連接、部分引擎API(GetComponent)的使用等等,這些已經(jīng)是老生常談了,鑒于篇幅限制不在此處多作介紹,大家感興趣可以Google自行搜索。
-
cpu
+關(guān)注
關(guān)注
68文章
10702瀏覽量
209361 -
內(nèi)存管理
+關(guān)注
關(guān)注
0文章
167瀏覽量
14099 -
vr
+關(guān)注
關(guān)注
34文章
9619瀏覽量
149410
原文標(biāo)題:游戲性能優(yōu)化技術(shù)干貨分享——內(nèi)存管理
文章出處:【微信號(hào):Imgtec,微信公眾號(hào):Imagination Tech】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評(píng)論請先 登錄
相關(guān)推薦
評(píng)論