这是摘自Unity官方文档有关优化的部分，原文链接：https://docs.unity3d.com/Manual/BestPracticeUnderstandingPerformanceInUnity.html
总共分为如下系列：
- 采样分析
- 内存部分
- 协程
- Asset审查
- 理解托管堆 【推荐阅读】
5.1 上篇：原理，临时分配内存，集合和数组
5.2 下篇：闭包，装箱，数组 - 字符串和文本
- 资源目录
- 通用的优化方案
- 一些特殊的优化方案
这个部分较长，所以分成两个部分。
下篇参见
Unity开发者面对的另一个常见的问题是托管堆过大。在Unity中托管堆变大更容易，减小就没那么容易了。而且，Unity的垃圾回收策略很容易产生内存碎片，回收这些内存碎片比较困难，进一步加剧了问题的严重性。
技术细节：内存堆运作原理和扩张原因
托管堆指的是被工程中的脚本运行环境（Mono或者IL2CPP）的内存管理器控制的一块内存区域。在托管代码中创建的所有引用类型的对象都会分配到托管堆中。【严格意义来讲，所有非空引用类型对象和所有装箱之后的值对象都要分配到托管堆中】
在上图中，白色方框表示由托管堆分配的一块内存，有颜色的方框表示存储在托管堆的数据对象。当空间不足，需要添加其他对象的时候，托管堆中会分配更多的空间以满足需求。
垃圾回收器会定期运行【具体的时间由平台决定】。垃圾回收器会扫描堆中的所有对象，标记没有被引用的对象，这些对象需要被删除来释放内存空间。
需要特别指出，Unity使用的垃圾回收算法是Boehm GC algorithm，这个算法是非分代式和非压缩的。非分代式意味着GC当执行回收操作的时候，要扫描整个堆，所以堆越大，性能越差。非压缩表示内存中的对象不会被移动，进行压缩，所以会有内存碎片产生。
上面的图展示了内存碎片化的例子。当对象被释放的时候，内存会空出一块区域。但是，释放的内存空间不会成为被放到某个整块的可用内存池中。这块空余内存左右部分的内存仍然会被其他对象所使用。所以这样就会造成内存之间出现空隙，如图中的红色圆圈表示的部分。这块新释放的内存空间只能够用来分配给和这块区域相等或者更小的对象使用。
当分配对象的时候，需要记住，对象一定要占用内存空间中的某个连续块。
所以这样就会导致内存碎片化：即使整个堆总共的可用内存空间很多，但是大部分空间都是存在于已经被分配的对象之间的间隙之中。这种情况下，即使总共的空间够用，但是却找不出连续的内存空间用来满足分配的需求。
所以，当某个大对象需要被分配的时候，并且内存中没有足够的连续区域用来存放，Unity的内存管理器就会执行两个操作。
- 如果GC没有运行过，先运行GC操作，试图能够释放更多的空间满足需求；
- 如果GC运行之后，依旧没有足够的连续空间满足需求，堆就会扩大。堆扩大的具体值和平台有关，大多数的Unity平台执行的操作是双倍扩大堆内存。
有关堆的关键问题
- 当托管堆扩展之后，Unity并不会经常再去释放掉这些内存页，它会继续持有扩展加入的这部分内存空间，即使有很大的一部分并未被利用。这样是为了防止当收回内存之后继续出现再次扩展内存堆，减少这部分的开销。
- 在大多数平台上，Unity最终会释放掉托管堆中未被占用的内存页，交还给操作系统。但是什么时候，什么频率进行这些操作，无法知晓，也不应该依靠这些操作。
- 托管堆用到的寻址空间从来不会还给操作系统。
- 对于32位程序而言，如果托管堆反复扩展和收缩，会造成寻址空间被耗尽。当寻址空间被耗尽的时候，操作系统会强制关闭应用。
- 对于64位程序而言，寻址空间足够大，所以不太可能会出现寻址空间被耗尽的情况。
临时分配
很多Unity工程都被发现每帧都会有几十甚至几百KB的临时数据被分配给托管堆。这对一个项目的性能而言非常糟糕。考虑以下的数学计算：
如果一个程序在每帧都会分配1KB的临时内存，帧率60FPS，每秒就必须分配60KB的临时内存。一分钟之后，内存中就会多出3.6MB的垃圾。每秒执行GC就会影响性能，而每分钟要分配3.6MB的内存对于低端设备而言问题非常严重。
更近一步，考虑到加载操作。如果在一个重度的Asset加载操作过程中产生了大量的临时Object，直到操作完成真正的对象才会被引用，所以GC不能再加载过程中释放掉这些临时的Object，托管堆需要扩展，虽然很短之后这些临时的内存会被释放掉。
跟踪托管堆分配相对比较容易。在Unity的CPU剖析器中，Overview中有一列“GC Alloc”。这一列展示了在某一帧有多少字节分配给了托管堆。【注意，这个参数并不等同于该帧分配了多少临时字节大小。剖析器只会显示在某一帧之内分配的总内存大小，即使有部分或者所有的内存会在后面几帧被重新利用】。当在“Deep Profiling”模式下，可以追踪到是在哪些方法里面执行了这些分配。
Unity剖析器并不会追踪不在主线程中分配的内存，所有“GC”一列并不会显示用户自己创建的线程分配了多少内存。如果需要检测，最好是把这部分的代码从子线程移动到主线程中进行分析。
如果是需要在真机上进行侦测，一定要打development build包。
注意，部分脚本方法只会在Editor中运行的时候才会分配内存，当打包到真机后，这部分代码并没有分配内存。GetComponent方法是最常见的例子；这个方法在Editor中运行的时候会分配内存，但是在打包好的工程中不会分配内存。
通常来讲，当工程只要处在可交互状态下时，开发者应该尽可能减少堆内存分配。非交互的情况下，如场景加载，则很少会出现问题。
Visual Studio的Jetbrains Resharper Plugin可以找到进行分配的代码。
使用Unity的Deep Profile模式也可以找到托管堆内存分配的具体原因。在Deep Profile模式下，所有的方法调用都被记录，会提供一个更清楚的方法调用树形图，可以更方便的确定堆内存分配。Deep Profile只在Editor下面才可行，最好不要在真机设备上使用。
基本的内存保护方案
有一些非常简单易操作的技术可以用来减少托管堆的内存分配。
集合类和数组重复利用
当使用C#中的Collection类或者数组的时候，应该考虑尽可能重用或者池化管理已经分配的内存空间。Collection类虽然暴露了Clear方法用来置空某个类，但是并没有释放被分配的内存空间。
void Update() {
List<float> nearestNeighbors = new List<float>();
findDistancesToNearestNeighbors(nearestNeighbors);
nearestNeighbors.Sort();
// … use the sorted list somehow …
}
这对于为了进行某些负责运算临时分配的“helper”Collection类。下面的代码是个非常简单的例子：
在这个例子里，nearestNeighbors列表每帧都会进行分配内存，用来收集数据点。将该列表提取为这个类的私有变量就可以避免每帧进行分配List的内存。
List<float> m_NearestNeighbors = new List<float>();
void Update() {
m_NearestNeighbors.Clear();
findDistancesToNearestNeighbors(NearestNeighbors);
m_NearestNeighbors.Sort();
// … use the sorted list somehow …
}
上面的版本就是优化之后的版本，List部分的内存可以反复利用，只有列表空间不够的时候才会再次进行分配。
