unity -- GC
GC简介
在游戏运行的时候，数据主要存储在内存中，当游戏的数据在不需要的时候，存储当前数据的内存就可以被回收以再次使用。内存垃圾是指当前废弃数据所占用的内存，垃圾回收（GC）是指将废弃的内存重新回收再次使用的过程。
1. Unity内部有两个内存管理池：堆内存和栈内存
堆内存(heap) 主要用来存储较大的和存储时间较长的数据，主要是负责程序中的对象和数据。
栈内存(stack) 主要用来存储较小的和短暂的数据，主要是负责运行时的代码，例如函数调用。
2. 哪些数据在堆和栈上？
栈->值类型: bool byte char decimal double enum float int long sbyte short struct uint ulong ushort
堆->非空引用类型: class interface delegate object string，同时包含：
1) 值类型数组
2) 装箱的值类型
3. Unity托管堆简介
托管堆是由项目的脚本运行时（Scripting Runtime）——Mono或者IL2CPP内存管理器管理的一个内存片段：底层都是在C++分配内存。
(1) Unity Mono内存是只升不降，即使用后，哪怕空闲再多，也不会还给系统
(2) Il2cpp，则与一般的C++内存释放一样，释放的内存都会还给系统
4.Unity的GC机制
使用了Boehm GC算法（可以参考：https://en.wikipedia.org/wiki/Boehm_garbage_collector），是非分代（non-generational）和非压缩（non-compacting）的。
- "非分代"是指GC执行清理操作时，必须遍历整个内存，去标记哪些没有被引用并且删除，随着内存的增长，它的性能就会降低。 目前2019版本的unity在实验分代GC算法
- “非压缩”意味着内存中的对象不会被重新定位，去减小对象之间的内存空隙
堆内存分配和回收机制
堆内存上的内存分配和存储相对而言更加复杂，主要是堆内存上可以存储短期较小的数据，也可以存储各种类型和大小的数据。其上的内存分配和回收顺序并不可控，可能会要求分配不同大小的内存单元来存储数据。
堆上的变量在存储的时候，主要分为以下几步：
1）首先，unity检测是否有足够的闲置内存单元用来存储数据，如果有，则分配对应大小的内存单元；
2）如果没有足够的存储单元，unity会触发垃圾回收来释放不再被使用的堆内存。这步操作是一步缓慢的操作，如果垃圾回收后有足够大小的内存单元，则进行内存分配。
3）如果垃圾回收后并没有足够的内存单元，则unity会扩展堆内存的大小，这步操作会很缓慢，然后分配对应大小的内存单元给变量。
堆内存的分配有可能会变得十分缓慢，特别是在需要垃圾回收和堆内存需要扩展的情况下，通常需要减少这样的操作次数。
垃圾回收时的操作
当堆内存上一个变量不再处于激活状态的时候，其所占用的内存并不会立刻被回收，不再使用的内存只会在GC的时候才会被回收。
每次运行GC的时候，主要进行下面的操作：
1）GC会检查堆内存上的每个存储变量；
2）对每个变量会检测其引用是否处于激活状态；
3）如果变量的引用不再处于激活状态，则会被标记为可回收；
4）被标记的变量会被移除，其所占有的内存会被回收到堆内存上。
GC操作是一个极其耗费的操作，堆内存上的变量或者引用越多则其运行的操作会更多，耗费的时间越长。
注意:包含引用类型的结构体：struct是值类型的变量，但是如果struct中包含有引用类型的变量，那么GC就必须检测整个struct，大大增加GC工作量。
何时会触发垃圾回收？
主要有三个操作会触发垃圾回收：
1） 在堆内存上进行内存分配操作而内存不够的时候都会触发垃圾回收来利用闲置的内存；
2） GC会自动的触发，不同平台运行频率不一样；
3） GC可以被强制执行。
特别是在堆内存上进行内存分配时内存单元不足够的时候，GC会被频繁触发，这就意味着频繁在堆内存上进行内存分配和回收会触发频繁的GC操作。
GC操作带来的问题
《1》.GC操作会需要大量的时间来运行，如果堆内存上有大量的变量或者引用需要检查，则检查的操作会十分缓慢，这就会使得游戏运行缓慢。
《2》GC可能会在关键时候运行，例如在CPU处于游戏的性能运行关键时刻，此时任何一个额外的操作都可能会带来极大的影响，使得游戏帧率下降。
《3》另外一个GC带来的问题是堆内存的碎片划。当一个内存单元从堆内存上分配出来，其大小取决于其存储的变量的大小。当该内存被回收到堆内存上的时候，有可能使得堆内存被分割成碎片化的单元。也就是说堆内存总体可以使用的内存单元较大，但是单独的内存单元较小，在下次内存分配的时候不能找到合适大小的存储单元，这也会触发GC操作或者堆内存扩展操作。
堆内存碎片会造成两个结果，一个是游戏占用的内存会越来越大，一个是GC会更加频繁地被触发。
GC优化
降低GC影响的方法
《1》 减少GC的运行次数：减少托管堆内存的分配频率
《2》 减少单次GC运行的时间：涉及到对游戏的重构，减少变量和引用的分配，更少的引用会减少GC操作中的检测个数从而提高GC的运行效率
《3》 主动GC：将GC的运行时间延迟，避免在关键时候触发，比如可以在场景加载/切换的时候、关闭UI的时候lua调用GC等。
基于以上方法，可以采用三种策略：
（1） 减少堆内存的分配和引用的分配。更少的变量和引用会减少GC操作中的检测个数从而提高GC的运行效率。
（2） 降低堆内存分配和回收的频率，尤其是在关键时刻。也就是说更少的事件触发GC操作，同时也降低堆内存的碎片化。
（3）可以试着测量GC和堆内存扩展的时间，使其按照可预测的顺序执行。这样操作的难度极大，但是这会大大降低GC的影响。
减少内存垃圾的数量
《1》缓存
如果在代码中反复调用某些造成堆内存分配的函数但是其返回结果并没有使用，这就会造成不必要的内存垃圾，我们可以缓存这些变量来重复利用。
《2》不要在频繁调用的函数中反复进行堆内存分配
在MonoBehaviour中，如果我们需要进行堆内存分配，最坏的情况就是在其反复调用的函数中进行堆内存分配，例如Update()和LateUpdate()函数这种每帧都调用的函数，这会造成大量的内存垃圾。我们可以考虑在Start()或者Awake()函数中进行内存分配，这样可以减少内存垃圾。或者在Update中采用计时器，特别是在运行有规律但是不需要每帧都运行的代码中。
《3》清除链表
在堆内存上进行链表的分配的时候，如果该链表需要多次反复的分配，我们可以采用链表的clear函数来清空链表从而替代反复多次的创建分配链表。
《4》对象池
即便我们在代码中尽可能地减少堆内存的分配行为，但是如果游戏有大量的对象需要产生和销毁依然会造成GC。对象池技术可以通过重复使用对象来降低堆内存的分配和回收频率。对象池在游戏中广泛的使用，特别是在游戏中需要频繁的创建和销毁相同的游戏对象的时候，例如枪的子弹这种会频繁生成和销毁的对象。
造成不必要的堆内存分配的因素
《1》字符串
字符串是不可变的引用类型变量，每次对字符串进行一些拆分和拼接操作时，都会产生新的字符串
减少字符串影响的方法：
（1） 减少不必要的字符串的创建，如果一个字符串被多次利用，我们可以创建并缓存该字符串。
（2） 减少不必要的字符串操作，例如如果在Text组件中，有一部分字符串需要经常改变，但是其他部分不会，则我们可以将其分为两个部分的组件，对于不变的部分就设置为类似常量字符串即可
（3） 字串符拼接采用 StringBuilder，尽量避免使用 + 操作符 和 strting.Format方法，从而减少字符串产生的内存垃圾。
（4） 移除游戏中的Debug.Log()函数的代码，尽管该函数可能输出为空，对该函数的调用依然会执行，该函数会创建至少一个字符（空字符）的字符串。如果游戏中有大量的该函数的调用，这会造成内存垃圾的增加。
（5） 按时间刷新的字符串，例如：能按分钟更新，就不要按秒刷新字串符
（6） 使用string.Intern来减少字符串数量达到优化内存的效果，主要是针对固定不变的字符串，例如策划配置的文本数据
（7） 避免装箱，例如 newStr = “text” + 1 -> “text” + 1.ToString() 后者是采用非托管的方法直接操作内存完成
（8） 值类型转换字符串务必采用ToString()方法
《2》容器类
(1) 容器大小确定时，初始化时就直接设置目标大小，例如 项目中文本字符串字典初始化
(2) List集合类
1) 尽量重用，不要临时分配，例如：目前list类使用最频繁，尽量临时分配时采用 ListPool.Get , 使用完再ListPool.Release
2) 查找list中对象时，避免直接使用Find， FindAll方法，建议采用for循环查找方式丢入ListPool中
3) FindAll方法中注意千万不要有GC分配的操作
(3) 字典和枚举
将枚举作为字段的Key，会引起装箱操作，有额外的临时内存分配，因为内部是采用Object.GetHashCode(Object) 来获取哈希值来作为Key值，只要是涉及到Key操作的都会引起装箱，例如Add，TryGetValue, ContainKey, Remove等等
《3》 匿名方法（Lambda）和闭包
(1) 在C#中所有方法的引用都是引用类型，都会被分配到堆中。把一个方法作为参数传递时，都会产生临时的内存分配，不管传递的是匿名方法还是已经定义的方法。
(2) 如果一个匿名函数引用到外部变量，则会形成一个闭包，C#为了实现这一点会生成一个匿名类（记住，类都是引用类型）来保存用到的外部变量，所以当调用这个闭包时，首先会实例化一个副本，同时会采用外部变量实际值来初始化这个副本，最终导致会在堆上分配内存。
优化方法
1） 尽量避免将方法作为参数传递，如果无法避免，优先采用匿名方法
2）尽量避免使用闭包，如果无法避免，绝对不能每帧执行的函数中使用闭包
《4》Unity函数调用
在代码编程中，当我们调用不是我们自己编写的代码，无论是Unity自带的还是插件中的，我们都可能会产生内存垃圾。Unity的某些函数调用会产生内存垃圾，我们在使用的时候需要注意它的使用。
《5》装箱操作
装箱操作是指一个值类型变量被用作引用类型变量时候的内部变换过程，如果我们向带有对象类型参数的函数传入值类型，这就会触发装箱操作。比如String.Format()函数需要传入字符串和对象类型参数，如果传入字符串和int类型数据，就会触发装箱操作。
《6》协程
调用 StartCoroutine()会进行内存分配，产生少量的内存垃圾，因为unity会生成实体来管理协程。所以在游戏的关键时刻应该限制该函数的调用。基于此，任何在游戏关键时刻调用的协程都需要特别的注意，特别是包含延迟回调的协程。
yield在协程中不会产生堆内存分配，但是如果yield带有参数返回，则会造成不必要的内存垃圾，
《7》foreach循环
在unity5.5以前的版本中，在foreach的迭代中都会生成内存垃圾，主要来自于其后的装箱操作。每次在foreach迭代的时候，都会在堆内存上生产一个System.Object用来实现迭代循环操作。在unity5.5中解决了这个问题，比如，在unity5.5以前的版本中，用foreach实现循环：
《8》函数引用
函数的引用，无论是指向匿名函数还是显式函数，在unity中都是引用类型变量，这都会在堆内存上进行分配。匿名函数的调用完成后都会增加内存的使用和堆内存的分配。具体函数的引用和终止都取决于操作平台和编译器设置，但是如果想减少GC最好减少函数的引用。
返回数组的函数调用或访问器，以及返回字符串的调用都会产生临时内存分配，可以尝试其他替代方案 例如
1） Mesh.vertices Mesh.normals 等等，如果进行频繁操作，可以采用缓存数据的方式，而不是函数调用获取
-
GameObject.name，GameObject.tag 后者的比较可以采用GameObject.CompareTag()来替代
-
Input.touches 可以采用Input.GetTouch()，Input.touchCount替代
《9》 UGUI的重构
UGUI的重构会引起临时的内存分配，重点减少触发重构因素发生频率
重构因素（顶点数据变化）：
-
激活图形(Graphic)组件
-
Graphic组件的大小，父节点变化
-
任何颜色相关修改，例如：Image color, shadow effectColor等等
-
Image类型和参数修改，例如：Simple->Filled，fillCenter变化， fillAmount变化，sprite，uvRect变化等等
-
RawImage类型和参数修改，例如：texture，uvRect 变化
-
Text类型的字符串内容，字体，字体大小和对齐方式等修改，例如：text 字符串内容变化，supportRichText，resizeTextForBestFit，resizeTextMinSize，alignment，fontSize， horizontalOverflow，verticalOverflow，fontStyle变化等等
-
其他：
shadow组件 useGraphicAlpha effectDistance，effectColor变化
删除不需要的顶点数据，例如，修改UGUI VertexHelper类
当前项目我们只保留：顶点坐标，UV坐标，顶点Color和索引数据
法线，切线，UV1-3数据使用不到，直接注释掉了对这些数据的填充代码
《10》语言集成查询LINQ和常量表达式
由于LINQ和常量表达式以装箱的方式实现，所以在使用的时候最好进行性能测试。
LINQ 并不是所有的平台都完整的支持，例如IOS，并不支持部分操作，项目中是禁止使用。