Unity内存
1、Unity内存按照分配方式分为：
（1）Native Memory（本地内存）
（2）Managed Memory（托管内存）
Editor和Runtime内存管理是不同的，Editor下打开工程就会将所有资源加载进内存，而Runtime是我们调用相应的Load接口时才会加载进内存。
2、Unity按照管理者分为：
（1）引擎管理内存
（2）用户管理内存
3、Unity Native Memory管理
图3-1 Native-Memory分配流程
Unity通过重载C++的new/malloc内存分配操作符实现自己的内存管理。
3.1 Allocator与memory label
memory label区分内存类型，每一种内存类型都会对应一个Allocator,每个Allocator有各自的分配策略，每一个Allocator会跟踪一个内存池。当需要申请内存时，就会找到对应类型的Allocator进行分配。
3.2 NewAsRoot
调用NewAsRoot时会分配所有
3.3 Stack Allocator
Stack Allocator用于分配局部内存，Stack Allocator的特点就是快、小、临时。
当Stack Allocator分配内存时，一次分配一个大的Heap Block块，然后通过栈的方式管理这块Block的分配。实际分配内存时会包含一个Header和User Data，Header记录当前使用状态、User Data大小等信息。使用一个栈顶指针管理内存分配，每次分配只在栈顶顶端新分配一块内存，然后修改栈顶指针。回收时如果回收的是非栈顶内存只需要修改Header中使用状态为Deleted；如果回收的是栈顶指针指向的内存，修改标记状态同时，栈顶指针向上回弹，回弹后会查看当前指向的内存是否已标记为Deleted,如果是则继续回弹，直到栈顶指针指向一个未标记为Deleted的内存。
图3-2 Stack-Allocator示意图
当一个Block块无法分配后，会再申请一块Block。但不可能无限分配，Stack Allocator有大小限制;
Editor：16MB Main Thread，256KB workers；Runtime：1MB Main thread，64KB workers
如果我们需求内存过大导致Stack Allocator大小不够，Unity会执行Fallback机制，会使用Dynamic Heap Allocator分配内存。Dynamic Heap Allocator分配策略相对Stack Allocator复杂很多，所以耗时比较大，出现这种情况可能导致卡顿。出现这种情况时Unity会给出一个MemoryManager.FallbackAllocation的提示。所以可以分帧加载一个比较大或多的资源。
3.4 影响Native内存大小因素
（1）Scene：场景中GameObject越多占用内存越大
（2）Audio
a、DSP Buffer Size（PlayerSettings->Audio）
声音数据缓冲，太大可能导致声音延时，太小导致发送给CPU太频繁
b、Force to mono：强制改成单声道，内存相对双声道减半
c、Format
d、Compression Format
（3）Code Size
模板泛型滥用
（4）AssetBundle
a、TypeTree：保证不同版本序列化正确
如果确保Bundle版本和Unity版本一致，打Bundle时可以通过设置BuildAssetBundleOptions.DisableWriteTypeTree关闭TypeTree，减小包体、省内存、并且可以提升打包速度。
b、LZ4（trunk based）/LZMA
c、设置合适的AB大小和数量
（5）Resources文件夹
打包时会生成R-B Tree用于Resources检索
（6）Texture
a、upload buffer（Project Settings->Quality->Async Upload Buffer Size）
b、read/write
c、Mip Maps
（5）Mesh
a、read/write
b、compression
（6）Assets
4、Unity Managed Memory
图4-1 Managed Memory分配机制
4.1
Unity使用Boehm回收器，Boehm是保守式回收器。
由于分代式垃圾回收移动内存、压缩等开销较大，不适合移动平台，所以Unity选择使用Boehm回收。
Unity不论使用Mono还是IL2CPP都使用Boehm回收器，
Unity嵌入早期版本的Mono（具体原理可参考Mono自动内存管理分析），采用非分代、非压缩的保守式GC，托管内存只增不减。
IL2CPP由Unity自己重写垃圾回收机制，是升级版的Boehm。使用IL2CPP，托管内存可以降低，内存返还的条件就是当GC6次，某一个Block都是闲置时，就会将这个Block返还给系统。
图4-2 回收机制展示
4.2 Managed Memory最佳实践
（1）使用Destroy，别用Null；
（2）Class VS Struct；
（3）缓存池；
（4）Closures and anonymous methods（闭包和匿名函数）；
（5）Coroutines（协程）；
（6）Configuration（配置表）；
（7）Singleton
（8）先分配大内存再分配小内存减少碎片化
4.3 Incremental GC
Unity2019.1引入Incremental GC(渐进式GC)，在使用Boehm回收器的基础上以增量模式运行，将垃圾收集拆分到多帧进行。
大多数情况下，Incremental GC可以减少垃圾收集尖峰问题。但某些情况下，使用Incremental GC可能会产生其它问题：
（1）Incremental GC是拆分的标记阶段，当对象引用改变时，必须在下一次迭代中再次扫描这些对象，如果在标记阶段不断有引用关系的变化，可能导致标记遍历永远不能完成，这种情况下，垃圾收集会退回到进行完整的非增量收集。
（2）另外，Incremental GC时，引用发生改变，Unity就需要设置写屏障通知垃圾收集，会增加开销，对代码产生性能影响。
5、Native和Managed关系
图5-1 Native和Manager Object关系（视频地址：https://www.bilibili.com/video/BV1J64y187TW?p=3）
如图5-1，上半部分是Native Object创建过程，下半部分是Managed Object创建过程。实际上不论我们是创建一个native object还是managed object都可能同时创建一个关联的managed/native object。
比如加载一个Texture会创建一个native object实例，同时也会创建一个托管的Texture实例。
Texture _texture = Resources.Load<Texture>("Unity");
我们将_texture置为null，然后调用GC.Collect()；此时在Profiler中查看_texture实例并没有被回收，而当我们调用Resources.UnloadUnusedAssets()后_texture销毁了。
