GC介绍

GC（垃圾回收）是指不再被用到（废弃、非激活状态）数据的内存回收再次使用的过程（主要针对的是堆内存的内存管理）。

Unity内存管理机制介绍

Unity的内存管理机制是采用自动内存管理的形式（减少开发者对于内存管理的关注，提高开发效率）
Unity的内存管理区分：(1)堆栈内存stack（用于存储短时数据和较小数据）(2)堆内存heap（用于存储长时数据和较大数据）
变量一旦被激活，其占用的内存块的状态标志会标记为使用状态，而变量不再被激活，其占用的内存块亦会被标记为空闲状态，则会被Unity的GC机制所检测回收（堆栈上的回收是即时以及快速的，而堆内存上并不是即时的，GC是一个定时的检测回收机制，只有GC时才会回收堆内存空间）。

堆栈上的内存分配与回收机制介绍（值类型变量）

类似于stack（栈），创建即进，无效则出，以一种顺序且可控的形式进行。（操作十分简洁，且快捷方便）

堆上的内存分配与回收机制介绍（非值类型变量）

相较于堆栈更复杂，且其回收顺序是不可控的。

变量存储在堆上的大致步骤：

Unity会首先检测堆内存，确定是否有足够的闲置内存单元来存储变量，如果有，直接分配其对应大小的内存单元。没有则跳转至第2步。
因为没有足够的存储单元，此时Unity就会触发GC（垃圾回收）机制来释放那些被标志为不再需要的堆内存块（该步骤十分缓慢）。如果此时垃圾回收后已经有了足够能存储变量的内存单元，则直接进行内存分配，否则，跳转至第3步。
因为垃圾回收后还是没有足够的存储单元，此时Unity则会直接扩展堆内存的大小（该步骤极其缓慢），然后再分配对应大小的内存单元给变量。

GC的大致操作

遍历检测堆内存上的变量。
检测每个变量的引用的激活状态。
如果变量的引用不再处于激活态，则将其标识为可回收状态。
移除被标识为可回收状态的变量，将其所占有的内存都回收到堆内存上。

GC的触发机制

在堆内存上进行内存分配而内存不够的时候，触发。
自动触发。（不同平台，运行频率不一样）
强制触发。（开发者调用相应函数）

GC会带来的问题

降低游戏帧率，使其运行缓慢。
- 因为GC操作可能会需要大量的时间来运行，尤其是在其操作不仅进行单纯的内存分配，而且后续还进行了内存回收和内存扩充操作的时候。这种影响会在游戏运行到关键时刻被放大，造成严重后果
- 如果存在大量的变量和引用，那么仅仅在第一步内存检测时，就会花费大量的运行时间。
堆内存的碎片化。
- 内存在分配时是会有不同的大小的，当它们被回收时，其大小是不会改变的，这就使得其在回收后依旧是其本身在分配后切割的大小，这就造成了一个结果——总的可使用的内存单元较大，但单独的内存单元较小。内存分配时，如果匹配不到合适大小的存储单元，则依旧会触发GC操作，甚至是堆内存扩展操作。
- 碎片化造成的实际效果：
  (1). 游戏占用内存越来越大。（经过了堆扩展）
  (2). GC会更加频繁地被触发。

降低GC影响的方法

大致从三个方面入手：

减少GC的运行次数
减少单次GC的运行时间
控制GC的触发时刻，避免关键时刻触发

降低影响的策略：

重构代码：
- 减少堆内存分配（变量和引用的创建），这样就减少了GC操作中变量的检测数量，从而提高GC运行效率。
降低堆内存分配和回收的频率：
根据测试方案，调整GC的触发时刻，使其按照可预测的顺序执行。

实用方法：

缓存：对没有改变却被反复调用分配的变量进行保存，重复使用。
不在频繁调用的函数中进行堆内存分配。
容器类，不进行多次创建，而是对单独容器把持后，使用前进行清理即可重复利用。
对象池：对需要频繁的创建和销毁的对象，将其保存在固定容器中，反复回收利用，仅需要设置状态即可。

造成不必要的堆内存分配的因素

字符串：

C#中，字符串是引用类型变量，而不是值类型变量，且其不可改变，每次对其进行变值操作，实质都是会新建一个字符串来存储，而旧的字符串会产生内存垃圾，被废弃回收。
因此可以采取一些方法来弱化字符串所带来的影响：

减少不必要的字符串创建。（缓存多次利用的字符串）
减少不必要的字符串操作，可以分离不变值字符串，以及常变值字符串。
使用StringBuilder类替代经常变动的字符串创建。
移除Debug.log()函数，该函数即使输出为空也会创建至少一个字符的字符串，如果游戏中大量调用，则会造成内存垃圾的增加。

Unity函数调用：

在调用Unity中自带的函数方法时，很容易在频繁调用时，产生大量的内存垃圾，需要根据实际来检测使用。
例如：调用GameObject.name或者GameObject.tag时也会造成预想不到的堆内存分配，这两个函数都会将结果存为新的字符串返回，这就造成了不必要的内存垃圾。
而为了避免这种情况，我们可以换用Unity中的GameObject.CompareTag函数来替代。

装箱操作：

装箱：当值类型作为引用类型来使用时，触发装箱操作，C#会将值类型通过System.Object类引用来封装。
应该尽量避免装箱操作。

携程：

调用StartCoroutine函数会产生少量的内存垃圾，因为Unity会生成实体来管理携程，所以应该在游戏的关键时刻严格限制携程的调用。
yield在携程中不会产生堆内存分配，但是如果它带有参数返回，则会造成不必要的内存垃圾。
yield return 0;
由于需要返回0，这里其实引发了装箱操作，所以产生了内存垃圾，避免措施可以这样做：
yeild return null;
另一种对携程的错误使用是，在每次返回的时候都new同一个变量。

while(!isComplete)
{
    yield return new WaitForSeconds(1f);
}

这里可以采用缓存来避免内存垃圾的产生：

WaitForSeconds delay = new WaitForSeconds(1f);
while(!isComplete)
{
    yield return delay;
}

foreach循环

在Unity5.5以前的版本，foreach的迭代中都会生成内存垃圾，因为在迭代时，都会在堆内存上生产一个System.Object用来实现迭代循环操作，在5.5版本后解决了这个版本。
所以在5.5版本前，可以采用for或者while循环来替代方案。

函数的引用

函数的引用，无论其指向的函数类型，都会在堆内存上进行内存分配，所以最好减少函数的引用。

LINQ和常量表达式

由于LINQ和常量表达式都是以装箱的形式实现，所以使用时最好进行性能测试。

重构代码来减小GC的影响

即使我们减小了代码在堆内存上的分配操作，代码也会增加GC的工作量。最常见的增加GC工作量的方式是让其检查它不必检查的对象。struct是值类型的变量，但是如果struct中包含有引用类型的变量，那么GC就必须检测整个struct。如果这样的操作很多，那么GC的工作量就大大增加。在下面的例子中struct包含一个string，那么整个struct都必须在GC中被检查：

public struct ItemData
{
    public string name;
    public int cost;
    public Vector3 position;
}
private ItemData[] itemData;

我们可以将该struct拆分为多个数组的形式，从而减小GC的工作量：

private string[] itemNames;
private int[] itemCosts;
private Vector3[] itemPositions;

简而言之，就是要减少GC检测不必要变量的次数。

定时执行GC操作。

在场景切换或是其他并不影响游戏性能的情况下，可以主动进行GC操作：

System.GC.Collec()

GC相关