基于Unity3D的內(nèi)存優(yōu)化的研究

劉克，李建方

(中國(guó)傳媒大學(xué) 計(jì)算機(jī)學(xué)院，北京 100024)

?

基于Unity3D的內(nèi)存優(yōu)化的研究

劉克，李建方

(中國(guó)傳媒大學(xué) 計(jì)算機(jī)學(xué)院，北京 100024)

近年來(lái)，Unity3D游戲引擎已經(jīng)成為手機(jī)游戲行業(yè)最為流行的制作平臺(tái)之一，但是很多游戲都存在卡頓，耗電速度快，占用內(nèi)存過(guò)多等現(xiàn)象，影響了玩家體驗(yàn)。Unity的內(nèi)存分為程序代碼段，托管堆和本機(jī)堆。本篇論文重點(diǎn)討論了在這三種內(nèi)存上優(yōu)化的方案，以及一些經(jīng)驗(yàn)和技巧。通過(guò)內(nèi)存優(yōu)化，可以有效的提升內(nèi)存的利用率，減少內(nèi)存碎片和占用的空間。這樣的方法有效的減少了像智能手機(jī)這樣內(nèi)存空間十分有限的移動(dòng)設(shè)備負(fù)擔(dān)，提高了開(kāi)發(fā)效率，增強(qiáng)了玩家游戲體驗(yàn)。

內(nèi)存優(yōu)化；Unity3D；托管堆；本機(jī)堆

1 引言

Unity Technologies在2005年發(fā)布了Unity1.0版本，截至2014年底，Unity全球注冊(cè)用戶(hù)已經(jīng)達(dá)到300萬(wàn)，Unity編輯器每月活躍開(kāi)發(fā)者數(shù)量達(dá)到100萬(wàn)，Unity的PC插件安裝量達(dá)到2億。在十年的時(shí)間里，Unity游戲引擎已經(jīng)演變成一個(gè)跨平臺(tái)的、高度集合的、方便易用的集成開(kāi)發(fā)環(huán)境，成為手機(jī)游戲市場(chǎng)的主流的開(kāi)發(fā)引擎之一[1]。然而，Unity在內(nèi)存占用上一直被開(kāi)發(fā)者所詬病，這一點(diǎn)在移動(dòng)設(shè)備上表現(xiàn)得尤其突出，動(dòng)輒內(nèi)存就會(huì)飆升至上百兆，輕則導(dǎo)致游戲卡頓，影響游戲體驗(yàn)，重則加快手機(jī)耗電速度，導(dǎo)致游戲被系統(tǒng)強(qiáng)制退出。

雖然Unity官方文檔給出了一些內(nèi)存管理的方法，并聲稱(chēng)Unity內(nèi)存全部都是由系統(tǒng)托管，但在實(shí)際項(xiàng)目中面臨的問(wèn)題復(fù)雜多變，欠缺經(jīng)驗(yàn)的開(kāi)發(fā)者通常不能正確使用內(nèi)存，有的使游戲場(chǎng)景產(chǎn)生很多不必要的內(nèi)存占用，有的產(chǎn)生的內(nèi)存碎片使內(nèi)存千瘡百孔，這些都是造成內(nèi)存占用過(guò)多的原因。因此只有正確的使用內(nèi)存，才能確保Unity的回收機(jī)制正確運(yùn)行。

本篇論文在編程方式，資源管理，以及動(dòng)態(tài)內(nèi)存加載機(jī)制研究了內(nèi)存的優(yōu)化，并在實(shí)際項(xiàng)目中產(chǎn)生了良好的反饋，使游戲在不損失效果的情況下將內(nèi)存的消耗降低。

2 Unity3D游戲引擎概述

Unity3D是基于組件式的游戲引擎，在引擎中，任何一個(gè)物體的存在都可以被看作為一個(gè)游戲?qū)ο?，它們都繼承自Monobehaviour類(lèi)，在不同的游戲?qū)ο笊细街隙喾N組件，會(huì)使游戲?qū)ο蟊憩F(xiàn)出豐富的行為，這是各種各樣游戲物體的本質(zhì)。譬如：在一個(gè)空的游戲?qū)ο笊细街粋€(gè)攝像機(jī)組件，此時(shí)游戲物體會(huì)表現(xiàn)成為一個(gè)攝像機(jī)；在一個(gè)空的游戲?qū)ο笊细街粋€(gè)人物蒙皮網(wǎng)格、動(dòng)畫(huà)控制機(jī)、剛體以及一個(gè)角色控制腳本組件，則會(huì)使游戲物體表現(xiàn)為一個(gè)人物角色。(圖1)所有的組件都是繼承于Component類(lèi)，開(kāi)發(fā)者可以將組件自由的拖拽到游戲物體上，這使得游戲物體變得非常容易擴(kuò)展和管理。

Unity3D還采用了所見(jiàn)即所得的開(kāi)發(fā)方式，開(kāi)發(fā)者可以在游戲場(chǎng)景中通過(guò)拖拽和擺放游戲?qū)ο髞?lái)構(gòu)建自己的游戲世界。在菜單中點(diǎn)擊游戲播放按鈕即可進(jìn)入游戲，對(duì)參數(shù)做出的調(diào)整能夠看到即時(shí)的變化效果。

圖1 組件組合圖

Unity提供了擴(kuò)展接口供開(kāi)發(fā)者使用，開(kāi)發(fā)者可以根據(jù)自己的實(shí)際情況開(kāi)發(fā)出插件來(lái)擴(kuò)展引擎，提高開(kāi)發(fā)效率。提供的諸多方便成為這款引擎流行的主要原因，但同時(shí)也使得引擎的管理成為一個(gè)麻煩，使之易于上手，難于精通。

3 Unity3D中內(nèi)存的種類(lèi)

Unity3D使用的內(nèi)存類(lèi)型共有三種：程序代碼段、托管堆(Managed Heap)以及本機(jī)堆(Native Heap)[2]。

3.1 程序代碼段

程序代碼包括了Unity引擎使用的庫(kù)，以及開(kāi)發(fā)者所寫(xiě)的所有的游戲代碼。在編譯后，得到的運(yùn)行文件將會(huì)被加載到設(shè)備中執(zhí)行，并占用一定內(nèi)存。這部分內(nèi)存實(shí)際上是沒(méi)有辦法去進(jìn)行優(yōu)化的，它們將在程序運(yùn)行開(kāi)始一直占用內(nèi)存，直到程序的結(jié)束才將內(nèi)存釋放。一個(gè)空的Unity默認(rèn)場(chǎng)景，沒(méi)有任何游戲物體和代碼，在IOS設(shè)備上占用內(nèi)存為17MB左右，而加上一些自己的代碼很容易就上升到20MB左右。

3.2 托管堆

托管堆是被Mono使用的一部分內(nèi)存。Mono項(xiàng)目是一個(gè)開(kāi)源的.net框架的一種實(shí)現(xiàn)，在Unity項(xiàng)目開(kāi)發(fā)中，它充當(dāng)了基本類(lèi)庫(kù)的角色。托管堆用來(lái)存放類(lèi)的實(shí)例，比如通過(guò)new生成的列表，實(shí)例中的各種聲明的變量等。托管堆能自動(dòng)地改變堆的大小以滿(mǎn)足程序所需要的內(nèi)存，并且在定時(shí)進(jìn)行垃圾回收來(lái)釋放不再使用的內(nèi)存。若程序員忘記清除對(duì)已經(jīng)不需要再使用的內(nèi)存的引用，會(huì)導(dǎo)致Mono認(rèn)為這塊內(nèi)存一直被程序使用，從而無(wú)法進(jìn)行垃圾回收。

3.3 本機(jī)堆

本機(jī)堆是Unity引擎進(jìn)行申請(qǐng)和操作資源的地方，比如網(wǎng)格模型，貼圖，關(guān)卡數(shù)據(jù)，音效等。Unity使用了自己的一套內(nèi)存管理機(jī)制來(lái)使這塊內(nèi)存具有和托管堆類(lèi)似的功能。基本理念是，如果在某個(gè)關(guān)卡里需要某個(gè)資源，那么在需要時(shí)進(jìn)行加載，之后在沒(méi)有任何引用時(shí)進(jìn)行卸載。雖然看上去和托管堆一樣，但是由于Unity自身的一套自動(dòng)加載和卸載資源的機(jī)制，讓兩者差異仍然很大。自動(dòng)加載資源可以為開(kāi)發(fā)者提供了方便，但是同時(shí)也意味著開(kāi)發(fā)者失去了手動(dòng)管理所有加載資源的權(quán)利，這是導(dǎo)致大量?jī)?nèi)存占有的罪魁禍?zhǔn)住?/p>

4 Unity3D的內(nèi)存優(yōu)化

4.1 程序代碼段優(yōu)化

在程序代碼段上可做的優(yōu)化并不多，主要是通過(guò)減少打包時(shí)引用庫(kù)的數(shù)量。

當(dāng)使用Unity開(kāi)發(fā)時(shí)，默認(rèn)的Mono包含庫(kù)可以說(shuō)大部分用不上，在Player Setting(Edit->Project Setting->Player)面板里，將最下方的Optimization欄目中“API Compatibility Level”選為.NET 2.0 Subset，表示你只會(huì)使用到部分的.NET 2.0 Subset，不需要Unity將全部.NET的API包含進(jìn)去

這部分優(yōu)化的力度需要根據(jù)代碼所用到的.NET的功能來(lái)進(jìn)行調(diào)整，有可能不能使用Subset或者最大的剝離力度。如果超出了限度，很可能會(huì)在需要該功能時(shí)因?yàn)檎也坏较鄳?yīng)的庫(kù)而導(dǎo)致程序崩潰。比較好地解決方案是仍然用最強(qiáng)的剝離，并輔以較小的第三方的類(lèi)庫(kù)來(lái)完成所需功能。

在此部分的優(yōu)化收效甚微，還增加了程序崩潰的概率，應(yīng)該是最后考慮的內(nèi)存優(yōu)化方案。

4.2 托管堆優(yōu)化

托管堆存儲(chǔ)的是程序在代碼中申請(qǐng)的內(nèi)存，在Unity中，托管堆為其新申請(qǐng)的內(nèi)存分配空間，如果空間不足，則向系統(tǒng)申請(qǐng)更多空間。

當(dāng)使用完一個(gè)實(shí)例之后，通常來(lái)說(shuō)在腳本中就不會(huì)再有對(duì)該對(duì)象的引用了。這包括將變量設(shè)置為NULL或其他引用，超出了變量的作用域，或者對(duì)游戲?qū)ο蟀l(fā)送Destroy()。在每隔一段時(shí)間，Mono的垃圾回收機(jī)制將檢測(cè)內(nèi)存，將沒(méi)有再被引用的內(nèi)存釋放回收。總的來(lái)說(shuō)，程序員要做的就是在盡可能早的時(shí)間將不需要的引用去除掉，這樣回收機(jī)制才能正確地把不需要的內(nèi)存清理出來(lái)。但是內(nèi)存清理過(guò)于頻繁可能會(huì)造成游戲的瞬時(shí)卡頓，影響了玩家的游戲體驗(yàn)。因此，最好選擇合適的時(shí)機(jī)，對(duì)內(nèi)存進(jìn)行批量清理，比如當(dāng)玩家暫停游戲，或者在場(chǎng)景切換的時(shí)候。

在游戲中，會(huì)遇到反復(fù)多次創(chuàng)建并銷(xiāo)毀實(shí)例的情況，比如在打飛機(jī)游戲中，按理來(lái)說(shuō)，飛機(jī)每次發(fā)射子彈時(shí)就要用Instantiate接口來(lái)實(shí)例化一個(gè)子彈，子彈離開(kāi)屏幕后又要對(duì)其調(diào)用Destroy()進(jìn)行垃圾回收，如此頻繁的開(kāi)辟內(nèi)存導(dǎo)致的后果是：內(nèi)存碎片增多，內(nèi)存的再分配會(huì)變得越來(lái)越吃力；造成游戲卡頓。一種解決方案是：將經(jīng)常反復(fù)調(diào)用的對(duì)象在不需要的時(shí)候?qū)⑵潆[藏并放到一個(gè)重用數(shù)組中，之后需要時(shí)，再?gòu)闹赜脭?shù)組中取出并恢復(fù)顯示。雖然消耗了部分內(nèi)存，但是將極大的改善游戲的性能[3]。

一般建立可重用對(duì)象的機(jī)制叫做可重用對(duì)象池，其組織結(jié)構(gòu)見(jiàn)表1。

重用對(duì)象池的使用方法為：創(chuàng)建一個(gè)類(lèi)并應(yīng)用單例模式，因?yàn)樵谶壿嬌现荒鼙３执嬖谝粋€(gè)對(duì)象池。將寫(xiě)好的腳本掛載到場(chǎng)景中。在Get方法中，程序首先會(huì)在objPool中查詢(xún)是否存有需要得到的游戲物體，若沒(méi)有則通過(guò)Instantiate接口實(shí)例化一個(gè)新的游戲物體，若存有則在列表中直接取出游戲物體并將其激活。在Save方法中，程序首先判斷objPool是否存在此類(lèi)游戲物體的鍵值對(duì)，若沒(méi)有則創(chuàng)立此類(lèi)物體鍵值對(duì)，并將游戲物體存入列表中，若有則將游戲物體直接存入列表中，并將游戲物體隱藏。在優(yōu)化前調(diào)用Instantiate接口的地方全都改成Get方法，調(diào)用Destroy接口的地方全都改為Save方法[4]。

表1 對(duì)象池

4.3 本機(jī)堆的優(yōu)化

當(dāng)Unity加載完成一個(gè)場(chǎng)景的時(shí)候，場(chǎng)景中所有的資源(模型，材質(zhì)，貼圖，腳本，聲音等)都會(huì)被自動(dòng)加載到內(nèi)存中。這樣做的好處是：由于場(chǎng)景中的資源都被預(yù)先載入到內(nèi)存中，在一個(gè)場(chǎng)景中用戶(hù)會(huì)擁有良好的游戲體驗(yàn)。但這樣的代價(jià)是將內(nèi)存的占用增多。由于Unity最初的設(shè)計(jì)目的是面向臺(tái)式機(jī)，對(duì)于臺(tái)式機(jī)來(lái)說(shuō)，這樣的占用絲毫沒(méi)有任何問(wèn)題，但是這樣的內(nèi)存管理策略遷移到移動(dòng)平臺(tái)后會(huì)出現(xiàn)大量的弊端，因?yàn)橐苿?dòng)設(shè)備的內(nèi)存空間非常有限，若不加優(yōu)化很可能造成游戲的崩潰。

一般內(nèi)存占用的峰值會(huì)發(fā)生在從一個(gè)游戲場(chǎng)景載入到另一個(gè)游戲場(chǎng)景的時(shí)候。由于當(dāng)前場(chǎng)景的一些數(shù)據(jù)(玩家生命值，玩家等級(jí)，玩家物品欄等)需要保存到下一個(gè)場(chǎng)景繼續(xù)使用，為了對(duì)這些數(shù)據(jù)進(jìn)行保護(hù)，Unity通常會(huì)先加載新的場(chǎng)景，然后將舊場(chǎng)景中需要保留的數(shù)據(jù)復(fù)制到新場(chǎng)景后，再將舊場(chǎng)景所占用的內(nèi)存釋放，這樣在某一時(shí)刻會(huì)導(dǎo)致兩個(gè)場(chǎng)景同時(shí)占用內(nèi)存，是內(nèi)存占用成倍增加，這對(duì)于移動(dòng)設(shè)備是非常危險(xiǎn)的，移動(dòng)設(shè)備很可能會(huì)因內(nèi)存不足導(dǎo)致游戲卡死或者崩潰。為了避免這樣的問(wèn)題，可以設(shè)置一個(gè)過(guò)度場(chǎng)景，過(guò)度場(chǎng)景只包含很少的資源(進(jìn)度條，背景圖片)，在切換場(chǎng)景時(shí)，可以先加載到過(guò)度場(chǎng)景，然后由過(guò)度場(chǎng)景加載到所需切換的場(chǎng)景，可以有效避免內(nèi)存暴漲。

在進(jìn)行場(chǎng)景切換時(shí)，當(dāng)前這個(gè)場(chǎng)景中被標(biāo)記為DontDestroyOnLoad的資源不會(huì)被卸載掉。一般這個(gè)借口用來(lái)保存玩家的一些狀態(tài)比如分?jǐn)?shù)，級(jí)別等偏向文本的信息。此時(shí)這個(gè)資源所攜帶的組件也不會(huì)被釋放掉，若這個(gè)資源包含了很多占用內(nèi)存的組件(聲音、網(wǎng)格、貼圖等)，它們將一直占用內(nèi)存，應(yīng)盡量避免這種情況[5]。

另外一種值得注意的情況是腳本中對(duì)資源的引用。大部分腳本將在場(chǎng)景轉(zhuǎn)換時(shí)隨之失效并被回收，但是，某些游戲物體由于調(diào)用了DontDestroyOnLoad接口不會(huì)被銷(xiāo)毀，這包括附著在游戲物體上的腳本。而這些腳本很可能含有對(duì)其它物體或者物體上的組件以及資源的引用，這樣相關(guān)的資源就都得不到釋放。另外，被聲明static的腳本或者采用單例模式的腳本在場(chǎng)景切換時(shí)也不會(huì)被銷(xiāo)毀，如果這個(gè)腳本含有大量對(duì)其它資源的引用，也會(huì)出現(xiàn)很多奇怪的問(wèn)題，有些是資源得不到釋放，有些是彈出空指針異常。因此，對(duì)代碼進(jìn)行解耦和減少對(duì)其它腳本的依賴(lài)是十分有必要的。如果確實(shí)無(wú)法避免這種情況，那應(yīng)當(dāng)顯式的對(duì)這些不再使用的引用對(duì)象調(diào)用Destroy接口或者將其設(shè)置為NULL。這樣在垃圾回收的時(shí)候，這些內(nèi)存將被認(rèn)為已經(jīng)無(wú)用而被回收。

Unity3D提供給開(kāi)發(fā)者兩個(gè)動(dòng)態(tài)加載的接口，一個(gè)是Resources.Load，另一個(gè)是AssetBundle。兩者的實(shí)質(zhì)區(qū)別并不是很大，Resources.Load只能加載來(lái)自Resources文件夾目錄下的資源，一般用來(lái)加載本地資源。在Resources文件夾下存放的資源，無(wú)論是否會(huì)被加載到場(chǎng)景中，都會(huì)被打包到本地，增加游戲文件的大小，對(duì)游戲的下載量起到一定的副作用。因此，應(yīng)控制Resources文件夾下資源的數(shù)量和所占空間。在Unity中，幾乎可以將任何物體封裝成為AssetBundle文件，將其存儲(chǔ)在服務(wù)器端，通過(guò)客戶(hù)端下載即可使用。把游戲資源從網(wǎng)絡(luò)讀取到本地內(nèi)存時(shí)，此時(shí)文件只是一個(gè)內(nèi)存鏡像數(shù)據(jù)塊，當(dāng)調(diào)用AssetBundle.Load接口時(shí)，才將內(nèi)存鏡像數(shù)據(jù)塊中的數(shù)據(jù)資源復(fù)制并反序列化成游戲可用資源，內(nèi)存分布如圖2所示。

圖2 內(nèi)存分布

如圖可知，在游戲場(chǎng)景調(diào)用Instantiate接口時(shí)，實(shí)際上是將存儲(chǔ)在區(qū)域2中的內(nèi)容復(fù)制一份到區(qū)域3中，因此調(diào)用Destroy接口回收內(nèi)存時(shí)，只是釋放掉的區(qū)域3的內(nèi)存，若游戲中不再使用此類(lèi)對(duì)象，那么區(qū)域1和區(qū)域2的內(nèi)存成為沒(méi)有用的游離數(shù)據(jù)塊，為了釋放區(qū)域1和區(qū)域2的內(nèi)存，應(yīng)當(dāng)調(diào)用AssetBundle.Unload接口，當(dāng)調(diào)用AssetBundle(false)，釋放的是區(qū)域2的內(nèi)存，當(dāng)調(diào)用AssetBundle(true)時(shí)，釋放的是區(qū)域1和區(qū)域2 的內(nèi)存，若再次想使用此類(lèi)資源，只能在服務(wù)器或本地重新加載。

使用動(dòng)態(tài)加載機(jī)制可以減少內(nèi)存占用，但是也增加了處理的時(shí)間，可以根據(jù)自身的特點(diǎn)需要在處理時(shí)間和空間上尋找一個(gè)平衡點(diǎn)。在小內(nèi)存環(huán)境中，內(nèi)存的初始化占用十分重要，因?yàn)樗鼪Q定了游戲關(guān)卡能否被正常加載，使用動(dòng)態(tài)加載機(jī)制能夠有效減輕這種壓力。

5 Unity3D資源優(yōu)化

如果只重視程序優(yōu)化而不注重資源優(yōu)化，有時(shí)會(huì)使優(yōu)化事倍功半。曾經(jīng)有一款手機(jī)游戲，在代碼上幾乎沒(méi)有做任何改動(dòng)，在不損失游戲效果的前提下，通過(guò)資源重制使占用的空間縮小為原來(lái)的十分之一。以下將介紹優(yōu)化資源的主要方法。

5.1 制作并整理圖集

一張圖片除了包含本身的色彩紋理信息外還包括了自身某些額外信息，若單獨(dú)一張圖片上有很多空余的地方，它們都會(huì)增加內(nèi)存的占用，如果將很多圖片合并在一張較大的圖片上，則會(huì)減少很多不必要的浪費(fèi)。同時(shí)圖片的數(shù)量越少，能夠減少Unity中DrawCall(相當(dāng)耗費(fèi)性能的操作)次數(shù)，減少CPU性能消耗。

在制作圖集中應(yīng)減少圖集中的空白地方。圖集中完全透明的像素和不透明的像素所占的內(nèi)存空間其實(shí)是一樣的。因此在素材量不變的情況下，要盡量減少圖集中的空白。有時(shí)一張1024×1024的圖集中，素材所占的面積還沒(méi)超過(guò)一半，這時(shí)可以考慮將這張圖集切成兩張512x512的圖集。但是應(yīng)該盡量避免使用1024×512的圖集，因?yàn)檫@樣會(huì)降低兼容性(某些平臺(tái)要求貼圖必須為方形)。

需要注意的是，假設(shè)界面A上的有一個(gè)圖標(biāo)，在界面B也需要一個(gè)一模一樣的圖標(biāo)，不要因?yàn)樵谥谱鲿r(shí)貪圖方便，在界面B中直接引用界面A的圖標(biāo)，因?yàn)檫@樣會(huì)將這個(gè)界面B也載入內(nèi)存，造成不必要的浪費(fèi)。圖3給出了一個(gè)制作標(biāo)準(zhǔn)圖集的圖集提供參考。

圖3 圖集

5.2 模型優(yōu)化

在移動(dòng)設(shè)備上，每個(gè)網(wǎng)格模型控制在300-1500個(gè)多邊形會(huì)達(dá)到比較好的效果。對(duì)于桌面平臺(tái)，理論范圍在1500-4000個(gè)面。如果游戲中任意時(shí)刻屏幕出現(xiàn)大量角色，那么應(yīng)該降低每個(gè)角色的面數(shù)。

盡可能的復(fù)制物體。譬如：一個(gè)400面的物體，在場(chǎng)景中復(fù)制50次，所消耗的性能和一個(gè)物體消耗的性能幾乎相等。

6 總結(jié)

如何在Unity3D中有效的優(yōu)化內(nèi)存是本文討論的重點(diǎn)，本篇論文主要介紹了在程序代碼段，托管堆以及本機(jī)堆優(yōu)化內(nèi)存的經(jīng)驗(yàn)和方法。通過(guò)對(duì)象池技術(shù)，可以減少申請(qǐng)內(nèi)存和回收內(nèi)存帶來(lái)的性能開(kāi)銷(xiāo)。動(dòng)態(tài)申請(qǐng)內(nèi)存機(jī)制可以避免游戲場(chǎng)景初始化時(shí)對(duì)設(shè)備帶來(lái)壓力。內(nèi)存優(yōu)化的方式并不是一成不變的，無(wú)論使用什么內(nèi)存優(yōu)化方式，都要預(yù)期游戲運(yùn)行的環(huán)境，然后定制與運(yùn)行環(huán)境相符合的內(nèi)存優(yōu)化策略，提高內(nèi)存優(yōu)化效率。

[1]劉鋼，孫文濤.Unity 官方案例精講[M].北京：中國(guó)鐵道出版社，2015.

[2]王巍.Unity3D中的內(nèi)存管理[EB/OL].http：//onevcat.com/2012/11/memory-in-unity3d/，2012.

[3]金璽曾.Unity3D手機(jī)游戲開(kāi)發(fā)[M].北京：清華大學(xué)出版社，2013

[4]Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides.設(shè)計(jì)模式[M].北京：機(jī)械工業(yè)出版社，2000.

[5]陳泉宏.Unity API 解析[M].北京：人民郵電出版社，2014

[6]Ken CF.Advanced 3D Game Programming All in One [M].Course Technology PTR，2005.

(責(zé)任編輯：馬玉鳳)

Research of Memory Optimization Based on Unity3D

LIU Ke，LI Jian-fang

(School of Computer Science，Communication University of China，Beijing 100024，China)

In recent years，Unity3D game engine has become one of the most popular platforms in mobile game industry，but lots of games exist the problem that including bad feedback，power consumption too fast，too much memory occupation，which impulse a bad affect on user experience.The memory of Unity is divided into program code，the managed heap and native heap.This paper mainly discussed the strategy，experience and skills in memory optimization.Which can effectively improve memory utilization，have less memory fragmentation and occupation.This method effectively reduces the memory burden in the device like smart phone which have a very limited memory space，improved the development efficiency，and enhanced the gaming experience.

memory optimization；unity3D；managed heap；native heap

2016-03-04

劉克(1990-)，男(漢族)，山東德州人，中國(guó)傳媒大學(xué)碩士研究生.E-mail：kobeliuke@163.com

TP311.5

文章編號(hào)：1673-4793(2016)05-0056-06