Unity3D佔用內存太大的解決方法【先轉，慢慢看】

Unity3D佔用內存太大的解決方法

最近網友經過網站搜索Unity3D在手機及其餘平臺下佔用內存太大. 這裏寫下關於Unity3D對於內存的管理與優化.

Unity3D 裏有兩種動態加載機制：一個是Resources.Load，另一個經過AssetBundle,其實二者區別不大。 Resources.Load就是從一個缺省打進程序包裏的AssetBundle里加載資源，而通常AssetBundle文件須要你本身建立，運行時 動態加載，能夠指定路徑和來源的。

其實場景裏全部靜態的對象也有這麼一個加載過程，只是Unity3D後臺替你自動完成了。

詳細說一下細節概念：
AssetBundle運行時加載:
來自文件就用CreateFromFile(注意這種方法只能用於standalone程序）這是最快的加載方法
也能夠來自Memory,用CreateFromMemory(byte[]),這個byte[]能夠來自文件讀取的緩衝，www的下載或者其餘可能的方式。
其實WWW的assetBundle就是內部數據讀取完後自動建立了一個assetBundle而已
Create完之後，等於把硬盤或者網絡的一個文件讀到內存一個區域，這時候只是個AssetBundle內存鏡像數據塊，尚未Assets的概念。
Assets加載:
用AssetBundle.Load(同Resources.Load) 這纔會從AssetBundle的內存鏡像裏讀取並建立一個Asset對象，建立Asset對象同時也會分配相應內存用於存放(反序列化)
異步讀取用AssetBundle.LoadAsync
也能夠一次讀取多個用AssetBundle.LoadAll
AssetBundle的釋放：
AssetBundle.Unload(flase)是釋放AssetBundle文件的內存鏡像，不包含Load建立的Asset內存對象。
AssetBundle.Unload(true)是釋放那個AssetBundle文件內存鏡像和並銷燬全部用Load建立的Asset內存對象。

一個Prefab從assetBundle裏Load出來 裏面可能包括：Gameobject transform mesh texture material shader script和各類其餘Assets。
你 Instaniate一個Prefab，是一個對Assets進行Clone(複製)+引用結合的過程，GameObject transform 是Clone是新生成的。其餘mesh / texture / material / shader 等，這其中些是純引用的關係的，包括：Texture和TerrainData，還有引用和複製同時存在的，包括：Mesh/material /PhysicMaterial。引用的Asset對象不會被複制，只是一個簡單的指針指向已經Load的Asset對象。這種含糊的引用加克隆的混合， 大概是搞糊塗大多數人的主要緣由。
專門要提一下的是一個特殊的東西：Script Asset，看起來很奇怪，Unity裏每一個Script都是一個封閉的Class定義而已,並無寫調用代碼，光Class的定義腳本是不會工做的。其 實Unity引擎就是那個調用代碼，Clone一個script asset等於new一個class實例，實例纔會完成工做。把他掛到Unity主線程的調用鏈裏去，Class實例裏的OnUpdate OnStart等纔會被執行。多個物體掛同一個腳本，其實就是在多個物體上掛了那個腳本類的多個實例而已，這樣就好理解了。在new class這個過程當中，數據區是複製的，代碼區是共享的，算是一種特殊的複製+引用關係。
你能夠再Instaniate一個一樣的Prefab,仍是這套mesh/texture/material/shader...，這時候會有新的GameObject等，可是不會建立新的引用對象好比Texture.
因此你Load出來的Assets其實就是個數據源，用於生成新對象或者被引用，生成的過程多是複製（clone)也多是引用（指針）
當你Destroy一個實例時，只是釋放那些Clone對象，並不會釋放引用對象和Clone的數據源對象，Destroy並不知道是否還有別的object在引用那些對象。
等到沒有任何 遊戲場景物體在用這些Assets之後，這些assets就成了沒有引用的遊離數據塊了，是UnusedAssets了，這時候就能夠經過Resources.UnloadUnusedAssets來釋放,Destroy不能完成這個任 務，AssetBundle.Unload(false)也不行，AssetBundle.Unload(true)能夠但不安全，除非你很清楚沒有任何 對象在用這些Assets了。
配個圖加深理解：

Unity3D佔用內存太大怎麼解決呢?

雖然都叫Asset，但複製的和引用的是不同的，這點被Unity的暗黑技術細節掩蓋了，須要本身去理解。

關於內存管理
按照傳統的編程思惟，最好的方法是：本身維護全部對象，用一個Queue來保存全部object,不用時該Destory的，該Unload的本身處理。
但這樣在C# .net框架底下有點不必，並且很麻煩。
穩妥起見你能夠這樣管理

建立時：
先創建一個AssetBundle,不管是從www仍是文件仍是memory
用AssetBundle.load加載須要的asset
加載完後當即AssetBundle.Unload(false),釋放AssetBundle文件自己的內存鏡像，但不銷燬加載的Asset對象。（這樣你不用保存AssetBundle的引用而且能夠當即釋放一部份內存）
釋放時：
若是有Instantiate的對象，用Destroy進行銷燬
在合適的地方調用Resources.UnloadUnusedAssets,釋放已經沒有引用的Asset.
若是須要當即釋放內存加上GC.Collect()，不然內存未必會當即被釋放，有時候可能致使內存佔用過多而引起異常。
這樣能夠保證內存始終被及時釋放，佔用量最少。也不須要對每一個加載的對象進行引用。

固然這並非惟一的方法，只要遵循加載和釋放的原理，任何作法都是能夠的。

系統在加載新場景時，全部的內存對象都會被自動銷燬，包括你用AssetBundle.Load加載的對象和Instaniate克隆的。可是不包括AssetBundle文件自身的內存鏡像，那個必需要用Unload來釋放，用.net的術語，這種數據緩存是非託管的。

總結一下各類加載和初始化的用法:
AssetBundle.CreateFrom.....：建立一個AssetBundle內存鏡像，注意同一個assetBundle文件在沒有Unload以前不能再次被使用
WWW.AssetBundle：同上，固然要先new一個再 yield return 而後才能使用
AssetBundle.Load(name)： 從AssetBundle讀取一個指定名稱的Asset並生成Asset內存對象，若是屢次Load同名對象，除第一次外都只會返回已經生成的Asset 對象，也就是說屢次Load一個Asset並不會生成多個副本（singleton）。
Resources.Load(path&name)：同上,只是從默認的位置加載。
Instantiate（object)：Clone 一個object的完整結構，包括其全部Component和子物體（詳見官方文檔）,淺Copy，並不複製全部引用類型。有個特別用法，雖然不多這樣 用，其實能夠用Instantiate來完整的拷貝一個引用類型的Asset,好比Texture等，要拷貝的Texture必須類型設置爲 Read/Write able。

總結一下各類釋放
Destroy: 主要用於銷燬克隆對象，也能夠用於場景內的靜態物體，不會自動釋放該對象的全部引用。雖然也能夠用於Asset,可是概念不同要當心，若是用於銷燬從文 件加載的Asset對象會銷燬相應的資源文件！可是若是銷燬的Asset是Copy的或者用腳本動態生成的，只會銷燬內存對象。
AssetBundle.Unload(false):釋放AssetBundle文件內存鏡像
AssetBundle.Unload(true):釋放AssetBundle文件內存鏡像同時銷燬全部已經Load的Assets內存對象
Reources.UnloadAsset(Object):顯式的釋放已加載的Asset對象，只能卸載磁盤文件加載的Asset對象
Resources.UnloadUnusedAssets:用於釋放全部沒有引用的Asset對象
GC.Collect()強制垃圾收集器當即釋放內存 Unity的GC功能不算好，沒把握的時候就強制調用一下

在3.5.2以前好像Unity不能顯式的釋放Asset

舉兩個例子幫助理解
例子1：
一個常見的錯誤：你從某個AssetBundle裏Load了一個prefab並克隆之：obj = Instaniate(AssetBundle1.Load('MyPrefab」);
這個prefab好比是個npc
而後你不須要他的時候你用了：Destroy(obj);你覺得就釋放乾淨了
其實這時候只是釋放了Clone對象，經過Load加載的全部引用、非引用Assets對象全都靜靜靜的躺在內存裏。
這種狀況應該在Destroy之後用：AssetBundle1.Unload(true)，完全釋放乾淨。
若是這個AssetBundle1是要反覆讀取的 不方便Unload，那能夠在Destroy之後用：Resources.UnloadUnusedAssets()把全部和這個npc有關的Asset都銷燬。
固然若是這個NPC也是要頻繁建立 銷燬的 那就應該讓那些Assets呆在內存裏以加速遊戲體驗。
由此能夠解釋另外一個以前有人提過的話題：爲何第一次Instaniate 一個Prefab的時候都會卡一下，由於在你第一次Instaniate以前，相應的Asset對象尚未被建立，要加載系統內置的 AssetBundle並建立Assets,第一次之後你雖然Destroy了，但Prefab的Assets對象都還在內存裏，因此就很快了。

順便提一下幾種加載方式的區別:
其實存在3種加載方式：
一是靜態引用，建一個public的變量，在Inspector裏把prefab拉上去，用的時候instantiate
二是Resource.Load，Load之後instantiate
三是AssetBundle.Load,Load之後instantiate
三種方式有細 節差別，前兩種方式，引用對象texture是在instantiate時加載，而assetBundle.Load會把perfab的所有assets 都加載，instantiate時只是生成Clone。因此前兩種方式，除非你提早加載相關引用對象，不然第一次instantiate時會包含加載引用 assets的操做，致使第一次加載的lag。

例子2：
從磁盤讀取一個1.unity3d文件到內存並創建一個AssetBundle1對象
AssetBundle AssetBundle1 = AssetBundle.CreateFromFile("1.unity3d");
從AssetBundle1裏讀取並建立一個Texture Asset,把obj1的主貼圖指向它
obj1.renderer.material.mainTexture = AssetBundle1.Load("wall") as Texture;
把obj2的主貼圖也指向同一個Texture Asset
obj2.renderer.material.mainTexture =obj1.renderer.material.mainTexture;
Texture是引用對象，永遠不會有自動複製的狀況出現(除非你真須要，用代碼本身實現copy)，只會是建立和添加引用
若是繼續：
AssetBundle1.Unload(true) 那obj1和obj2都變成黑的了，由於指向的Texture Asset沒了
若是：
AssetBundle1.Unload(false) 那obj1和obj2不變，只是AssetBundle1的內存鏡像釋放了
繼續：
Destroy(obj1),//obj1被釋放，但並不會釋放剛纔Load的Texture
若是這時候：
Resources.UnloadUnusedAssets();
不會有任何內存釋放 由於Texture asset還被obj2用着
若是
Destroy(obj2)
obj2被釋放，但也不會釋放剛纔Load的Texture
繼續
Resources.UnloadUnusedAssets();
這時候剛纔load的Texture Asset釋放了，由於沒有任何引用了
最後CG.Collect();
強制當即釋放內存
由此能夠引伸出論壇裏另外一個被提了幾回的問題，如何加載一堆大圖片輪流顯示又不爆掉
不考慮AssetBundle，直接用www讀圖片文件的話等因而直接建立了一個Texture Asset
假設文件保存在一個List裏
TLlist<string> fileList;
int n=0;
IEnumerator OnClick()
{
WWW image = new www(fileList[n++])；
yield return image;
obj.mainTexture = image.texture;

n = (n>=fileList.Length-1)?0:n;
Resources.UnloadUnusedAssets();
}
這樣能夠保證內存裏始終只有一個巨型Texture Asset資源，也不用代碼追蹤上一個加載的Texture Asset,可是速度比較慢
或者：
IEnumerator OnClick()
{
WWW image = new www(fileList[n++])；
yield return image;
Texture tex = obj.mainTexture;
obj.mainTexture = image.texture;

n = (n>=fileList.Length-1)?0:n;
Resources.UnloadAsset(tex);
}
這樣卸載比較快

 

 

Hog的評論引用：

感受這是Unity內存管理暗黑和混亂的地方，特別是牽扯到Texture
我最近也一直在測試這些用AssetBundle加載的asset同樣能夠用Resources.UnloadUnusedAssets卸載，但必須先AssetBundle.Unload,纔會被識別爲無用的asset。比較保險的作法是
建立時：
先創建一個AssetBundle,不管是從www仍是文件仍是memory
用AssetBundle.load加載須要的asset
用完後當即AssetBundle.Unload(false),關閉AssetBundle但不摧毀建立的對象和引用
銷燬時：
對Instantiate的對象進行Destroy
在合適的地方調用Resources.UnloadUnusedAssets,釋放已經沒有引用的Asset.
若是須要當即釋放加上GC.Collect()
這樣能夠保證內存始終被及時釋放
只要你Unload過的AssetBundle,那些建立的對象和引用都會在LoadLevel時被自動釋放。

 

全面理解Unity加載和內存管理機制之二：進一步深刻和細節
Unity幾種動態加載Prefab方式的差別:
其實存在3種加載prefab的方式：
一是靜態引用，建一個public的變量，在Inspector裏把prefab拉上去，用的時候instantiate
二是Resource.Load，Load之後instantiate
三是AssetBundle.Load,Load之後instantiate
三種方式有細節差別，前兩種方式，引用對象texture是在instantiate時加載，而assetBundle.Load會把perfab的所有 assets都加載，instantiate時只是生成Clone。因此前兩種方式，除非你提早加載相關引用對象，不然第一次instantiate時會 包含加載引用類assets的操做，致使第一次加載的lag。官方論壇有人說Resources.Load和靜態引用是會把全部資源都預先加載的，反覆測試的結果，靜態引用和Resources.Load也是OnDemand的，用到時纔會加載。

幾種AssetBundle建立方式的差別:
CreateFromFile:這種方式不會把整個硬盤AssetBundle文件都加載到 內存來，而是相似創建一個文件操做句柄和緩衝區，須要時才實時Load，因此這種加載方式是最節省資源的，基本上AssetBundle自己不佔什麼內 存，只須要Asset對象的內存。惋惜只能在PC/Mac Standalone程序中使用。
CreateFromMemory和www.assetBundle:這兩種方式AssetBundle文件會整個鏡像於內存中，理論上文件多大就須要多大的內存，以後Load時還要佔用額外內存去生成Asset對象。

何時纔是UnusedAssets?
看一個例子：
Object obj = Resources.Load("MyPrefab");
GameObject instance = Instantiate(obj) as GameObject;
.........
Destroy(instance);
建立隨後銷燬了一個Prefab實例，這時候 MyPrefab已經沒有被實際的物體引用了，但若是這時：
Resources.UnloadUnusedAssets();
內存並無被釋放，緣由：MyPrefab還被這個變量obj所引用
這時候：
obj  = null;
Resources.UnloadUnusedAssets();
這樣才能真正釋放Assets對象
因此：UnusedAssets不但要沒有被實際物體引用，也要沒有被生命週期內的變量所引用，才能夠理解爲 Unused(引用計數爲0)
因此因此：若是你用個全局變量保存你Load的Assets，又沒有顯式的設爲null，那 在這個變量失效前你不管如何UnloadUnusedAssets也釋放不了那些Assets的。若是你這些Assets又不是從磁盤加載的，那除了 UnloadUnusedAssets或者加載新場景之外沒有其餘方式能夠卸載之。

一個複雜的例子，代碼很醜陋實際也不可能這樣作，只是爲了加深理解

IEnumerator OnClick()

{

Resources.UnloadUnusedAssets();//清乾淨以避免影響測試效果

yield return new WaitForSeconds(3);

float wait = 0.5f;

//用www讀取一個assetBundle,裏面是一個Unity基本球體和帶一張大貼圖的材質，是一個Prefab

WWW aa = new WWW(@"file://SpherePrefab.unity3d");

yield return aa;

AssetBundle asset = aa.assetBundle;

yield return new WaitForSeconds(wait);//每步都等待0.5s以便於分析結果

Texture tt = asset.Load("BallTexture") as  Texture;//加載貼圖

yield return new WaitForSeconds(wait);

GameObject ba = asset.Load("SpherePrefab") as  GameObject;//加載Prefab

yield return new WaitForSeconds(wait);

GameObject obj1 = Instantiate(ba) as GameObject;//生成實例

yield return new WaitForSeconds(wait);

Destroy(obj1);//銷燬實例

yield return new WaitForSeconds(wait);

asset.Unload(false);//卸載Assetbundle

yield return new WaitForSeconds(wait);

Resources.UnloadUnusedAssets();//卸載無用資源

yield return new WaitForSeconds(wait);

ba = null;//將prefab引用置爲空之後卸無用載資源

Resources.UnloadUnusedAssets();

yield return new WaitForSeconds(wait);

tt = null;//將texture引用置爲空之後卸載無用資源

Resources.UnloadUnusedAssets();

}

這是測試結果的內存Profile曲線圖

Unity3D佔用內存太大怎麼解決呢?

圖片:p12.jpg

很經典的對稱造型，用多少釋放多少。

這是各階段的內存和其餘數據變化

說明:
1        初始狀態
2        載入AssetBundle文件後，內存多了文件鏡像，用量上升，Total Object和Assets增長1（AssetBundle也是object)
3        載入Texture後，內存繼續上升，由於多了Texture Asset,Total Objects和Assets增長1
4        載入Prefab後，內存無明顯變化，由於最佔內存的Texture已經加載，Materials上升是由於多了Prefab的材質，Total Objects和Assets增長6，由於 Perfab 包含不少 Components
5        實例化Prefab之後，顯存的Texture Memory、GameObjectTotal、Objects in Scene上升，都是由於實例化了一個可視的對象
6        銷燬實例後，上一步的變化還原，很好理解
7        卸載AssetBundle文件後，AssetBundle文件鏡像佔用的內存被釋放，相應的Assets和Total Objects Count也減1
8        直接Resources.UnloadUnusedAssets,沒有任何變化，由於全部Assets引用並無清空
9        把Prefab引用變量設爲null之後，整個Prefab除了Texture外都沒有任何引用了，因此被UnloadUnusedAssets銷燬,Assets和Total Objects Count減6
10        再把Texture的引用變量設爲null,以後也被UnloadUnusedAssets銷燬，內存被釋放，assets和Total Objects Count減1，基本還原到初始狀態

從中也能夠看出：
Texture加載之後是到內存，顯示的時候才進入顯存的Texture Memory。
全部的東西基礎都是Object
Load的是Asset,Instantiate的是GameObject和Object in Scene
Load的Asset要Unload,new的或者Instantiate的object能夠Destroy

 

Unity 3D中的內存管理

Unity3D在內存佔用上一直被人詬病，特別是對於面向移動設備的遊戲開發，動輒內存佔用飆上一兩百兆，致使內存資源耗盡，從而被系統強退形成極 差的體驗。相似這種狀況並很多見，可是絕大部分都是能夠避免的。雖然理論上Unity的內存管理系統應當爲開發者分憂解難，讓你們投身到更有意義的事情中 去，可是對於Unity對內存的管理方式，官方文檔中並無太多的說明，基本須要依靠本身摸索。最近在接手的項目中存在嚴重的內存問題，在參照文檔和 Unity Answer衆多猜想和證明以後，稍微總結了下Unity中的內存的分配和管理的基本方式，在此共享。

雖然Unity標榜本身的內存使用全都是「Managed Memory」，可是事實上你必須正確地使用內存，以保證回收機制正確運行。若是沒有作應當作的事情，那麼場景和代碼頗有可能形成不少非必要內存的佔用， 這也是不少Unity開發者抱怨內存佔用太大的緣由。接下來我會介紹Unity使用內存的種類，以及相應每一個種類的優化和使用的技巧。遵循使用原則，能夠 讓非必要資源儘快獲得釋放，從而下降內存佔用。

 

Unity中的內存種類

實際上Unity遊戲使用的內存一共有三種：程序代碼、託管堆（Managed Heap）以及本機堆（Native Heap）。

程序代碼包括了全部的Unity引擎，使用的庫，以及你所寫的全部的遊戲代碼。在編譯後，獲得的運行文件將會被加載到設備中執行，並佔用必定內存。

這部份內存其實是沒有辦法去「管理」的，它們將在內存中從一開始到最後一直存在。一個空的Unity默認場景，什麼代碼都不放，在iOS設備上佔 用內存應該在17MB左右，而加上一些本身的代碼很容易就飆到20MB左右。想要減小這部份內存的使用，能作的就是減小使用的庫，稍後再說。

託管堆是被Mono使用的一部份內存。Mono項目一個開源的.net框架的一種實現，對於Unity開發，其實充當了基本類庫的角色。

託管堆用來存放類的實例（好比用new生成的列表，實例中的各類聲明的變量等）。「託管」的意思是Mono「應該」自動地改變堆的大小來適應你所須要的內存，

而且定時地使用垃圾回收（Garbage Collect）來釋放已經不須要的內存。關鍵在於，有時候你會忘記清除對已經不須要再使用的內存的引用，

從而致使Mono認爲這塊內存一直有用，而沒法回收。

最後，本機堆是Unity引擎進行申請和操做的地方，好比貼圖，音效，關卡數據等。Unity使用了本身的一套內存管理機制來使這塊內存具備和託管堆相似的功能。

基本理念是，若是在這個關卡里須要某個資源，那麼在須要時就加載，以後在沒有任何引用時進行卸載。聽起來很美好也和託管堆同樣，

可是因爲Unity有一套自動加載和卸載資源的機制，讓二者變得差異很大。自動加載資源能夠爲開發者省很多事兒，

可是同時也意味着開發者失去了手動管理全部加載資源的權力，這很是容易致使大量的內存佔用（貼圖什麼的你懂的），

也是Unity給人留下「吃內存」印象的罪魁禍首。

---

 

優化程序代碼的內存佔用

這部分的優化相對簡單，由於能作的事情並很少：主要就是減小打包時的引用庫，改一改build設置便可。

對於一個新項目來講不會有太大問題，可是若是是已經存在的項目，可能改變會致使原來所須要的庫的缺失（雖然說通常來講這種可能性不大），

所以有可能沒法作到最優。

 

當使用Unity開發時，默認的Mono包含庫能夠說大部分用不上，在Player Setting（Edit->Project Setting->Player或者Shift+Ctrl(Command)+B裏的Player Setting按鈕）

面板裏，將最下方的Optimization欄目中「Api Compatibility Level」選爲.NET 2.0 Subset，表示你只會使用到部分的.NET 2.0 Subset，不須要Unity將所有.NET的Api包含進去。接下來的「Stripping Level」表示從build的庫中剝離的力度，每個剝離選項都將從打包好的庫中去掉一部份內容。你須要保證你的代碼沒有用到這部分被剝離的功能，

選爲「Use micro mscorlib」的話將使用最小的庫（通常來講也沒啥問題，不行的話能夠試試以前的兩個）。庫剝離能夠極大地下降打包後的程序的尺寸以及程序代碼的內存佔用，惟一的缺點是這個功能只支持Pro版的Unity。

這部分優化的力度須要根據代碼所用到的.NET的功能來進行調整，有可能不能使用Subset或者最大的剝離力度。

若是超出了限度，極可能會在須要該功能時由於找不到相應的庫而crash掉（iOS的話極可能在Xcode編譯時就報錯了）。

比較好地解決方案是仍然用最強的剝離，並輔以較小的第三方的類庫來完成所需功能。

一個最多見問題是最大剝離時Sysytem.Xml是不被Subset和micro支持的，若是隻是爲了xml，徹底能夠導入一個輕量級的xml庫來解決依賴（Unity官方推薦這個）。

關於每一個設定對應支持的庫的詳細列表，能夠在這裏找到。關於每一個剝離級別到底作了什麼，Unity的文檔也有說明。

實際上，在遊戲開發中絕大多數被剝離的功能使用不上的，所以無論如何，庫剝離的優化方法都值得一試。

---

 

託管堆優化

Unity有一篇不錯的關於託管堆代碼如何寫比較好的說明，在此基礎上我我的有一些補充。

首先須要明確，託管堆中存儲的是你在你的代碼中申請的內存（不管是用js，C#仍是Boo寫的）。

通常來講，無非是new或者Instantiate兩種生成object的方法（事實上Instantiate中也是調用了new）。

在接收到alloc請求後，託管堆在其上爲要新生成的對象實例以及其實例變量分配內存，若是可用空間不足，則向系統申請更多空間。

當你使用完一個實例對象以後，一般來講在腳本中就不會再有對該對象的引用了（這包括將變量設置爲null或其餘引用，超出了變量的做用域，

或者對Unity對象發送Destory()）。在每隔一段時間，Mono的垃圾回收機制將檢測內存，將沒有再被引用的內存釋放回收。總的來講，

你要作的就是在儘量早的時間將不須要的引用去除掉，這樣回收機制才能正確地把不須要的內存清理出來。可是須要注意在內存清理時有可能形成遊戲的短期卡頓，

這將會很影響遊戲體驗，所以若是有大量的內存回收工做要進行的話，須要儘可能選擇合適的時間。

若是在你的遊戲裏，有特別多的相似實例，並須要對它們常常發送Destroy()的話，遊戲性能上會至關難看。好比小熊推金幣中的金幣實例，按理說每枚金幣落下臺子後

都須要對其Destory()，而後新的金幣進入臺子時又須要Instantiate，這對性能是極大的浪費。一種一般的作法是在不須要時，不摧毀這個GameObject，而只是隱藏它，

並將其放入一個重用數組中。以後須要時，再從重用數組中找到可用的實例並顯示。這將極大地改善遊戲的性能，相應的代價是消耗部份內存，通常來講這是能夠接受的。

關於對象重用，能夠參考Unity關於內存方面的文檔中Reusable Object Pools部分，或者Prime31有一個是用Linq來創建重用池的視頻教程（Youtube，須要FQ，上，下）。

若是不是必要，應該在遊戲進行的過程當中儘可能減小對GameObject的Instantiate()和Destroy()調用，由於對計算資源會有很大消耗。在便攜設備上短期大量生成和摧毀物體的

話，很容易形成瞬時卡頓。若是內存沒有問題的話，儘可能選擇先將他們收集起來，而後在合適的時候（好比按暫停鍵或者是關卡切換），將它們批量地銷燬並 且回收內存。Mono的內存回收會在後臺自動進行，系統會選擇合適的時間進行垃圾回收。在合適的時候，也能夠手動地調用 System.GC.Collect()來建議系統進行一次垃圾回收。

要注意的是這裏的調用真的僅僅只是建議，可能系統會在一段時間後在進行回收，也可能徹底不理會這條請求，不過在大部分時間裏，這個調用仍是靠譜的。

---

 

本機堆的優化

當你加載完成一個Unity的scene的時候，scene中的全部用到的asset（包括Hierarchy中全部GameObject上以及腳本中賦值了的的材質，貼圖，動畫，聲音等素材），

都會被自動加載（這正是Unity的智能之處）。也就是說，當關卡呈如今用戶面前的時候，全部Unity編輯器能認識的本關卡的資源都已經被預先加 入內存了，這樣在本關卡中，用戶將有良好的體驗，不管是更換貼圖，聲音，仍是播放動畫時，都不會有額外的加載，這樣的代價是內存佔用將變多。Unity最 初的設計目的仍是面向臺式機，

幾乎無限的內存和虛擬內存使得這樣的佔用彷佛不是問題，可是這樣的內存策略在以後移動平臺的興起和大量移動設備遊戲的製做中出現了弊端，由於移動設 備能使用的資源始終很是有限。所以在面向移動設備遊戲的製做時，儘可能減小在Hierarchy對資源的直接引用，而是使用Resource.Load的方 法，在須要的時候從硬盤中讀取資源，

在使用後用Resource.UnloadAsset()和Resources.UnloadUnusedAssets()儘快將其卸載掉。總之，這裏是一個處理時間和佔用內存空間的trade off，

如何達到最好的效果沒有標準答案，須要本身權衡。

在關卡結束的時候，這個關卡中所使用的全部資源將會被卸載掉（除非被標記了DontDestroyOnLoad）的資源。注意不只是DontDestroyOnLoad的資源自己，

其相關的全部資源在關卡切換時都不會被卸載。DontDestroyOnLoad通常被用來在關卡之間保存一些玩家的狀態，好比分數，級別等偏向文 本的信息。若是DontDestroyOnLoad了一個包含不少資源（好比大量貼圖或者聲音等大內存佔用的東西）的話，這部分資源在場景切換時沒法卸 載，將一直佔用內存，

這種狀況應該儘可能避免。

另一種須要注意的狀況是腳本中對資源的引用。大部分腳本將在場景轉換時隨之失效並被回收，可是，在場景之間被保持的腳本不在此列（一般狀況是被附 着在DontDestroyOnLoad的GameObject上了）。而這些腳本極可能含有對其餘物體的Component或者資源的引用，這樣相關的 資源就都得不到釋放，

這絕對是不想要的狀況。另外，static的單例（singleton）在場景切換時也不會被摧毀，一樣地，若是這種單例含有大量的對資源的引用，也會成爲大問題。

所以，儘可能減小代碼的耦合和對其餘腳本的依賴是十分有必要的。若是確實沒法避免這種狀況，那應當手動地對這些再也不使用的引用對象調用Destroy()

或者將其設置爲null。這樣在垃圾回收的時候，這些內存將被認爲已經無用而被回收。

須要注意的是，Unity在一個場景開始時，根據場景構成和引用關係所自動讀取的資源，只有在讀取一個新的場景或者reset當前場景時，纔會獲得清理。

所以這部份內存佔用是不可避免的。在小內存環境中，這部分初始內存的佔用十分重要，由於它決定了你的關卡是否可以被正常加載。所以在計算資源充足

或是關卡開始以後還有機會進行加載時，儘可能減小Hierarchy中的引用，變爲手動用Resource.Load，將大大減小內存佔用。在 Resource.UnloadAsset()和Resources.UnloadUnusedAssets()時，只有那些真正沒有任何引用指向的資源 會被回收，所以請確保在資源再也不使用時，將全部對該資源的引用設置爲null或者Destroy。

一樣須要注意，這兩個Unload方法僅僅對Resource.Load拿到的資源有效，而不能回收任何場景開始時自動加載的資源。與此相似的還有 AssetBundle的Load和Unload方法，靈活使用這些手動自願加載和卸載的方法，是優化Unity內存佔用的不二法則～

總之這些就是關於Unity3d優化細節,具體仍是查看Unity3D的技術手冊,以便實現最大的優化.