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的技术手册,以便实现最大的优化.