Unity3D 项目优化-CPU方面
DrawCall是什么？简单来讲其实就是对底层图形程序（比如：OpenGL ES）接口的调用，以在屏幕上画出东西。所以，是谁去调用这些接口呢？CPU。
Fragment是什么？经常有人说vf这样的术语，其中的v代表了vertex即我们都知道是顶点。那f所代表的fragment是什么呢？说它之前需要先说一下像素。通俗的说，像素是构成数码影像的基本单元。那fragment呢？是有可能成为像素的东西。为什么叫有可能呢？就是最终会不会被画出来不一定，是潜在的像素。所以这会涉及到谁呢？GPU。
Batching是什么？同样，我相信各位读者应该都知道批处理的作用是什么。没错，将批处理之前需要很多次调用（DrawCall）的物体合并，之后只需要调用一次底层图形程序的接口就行。听上去这简直就是优化的终极方案啊！但是，理想是美好的，世界是残酷的，一些不足之后我们再细聊。
内存的分配。记住，除了Unity 3D自己的内存损耗。我们可是还带着Mono呢，还有托管的那一套东西。更别说又引入自己的几个dll文件了。这些都是内存开销上需要考虑到的。
优化注意的三个方面：
（1）CPU方面。
（2）GPU方面。
（3）内存方面。
影响CPU的效率：
（1）DrawCalls。
（2）物理组件（Physics）。
（3）GC（用来处理内存的，但是是谁使用GC去处理内存的呢？）。
（4）脚本中的代码质量。
- 减少DrawCalls
主要的思路就是每个物体尽量减少渲染次数，多个物体最好一起渲染。
- 使用Draw Call Batching，也就是描绘调用批处理。Unity 3D在运行时可以将一些物体进行合并，从而用一个描绘调用来渲染他们。
- 通过把纹理打包成图集尽量减少材质的使用。
- 尽量少的使用反光、阴影之类的效果，因为那会使物体多次渲染。
首先要理解为什么两个没有使用相同材质的物体即使使用批处理，也无法实现Draw Call数量的下降和性能的提升。
因为被“批处理”的两个物体的网格模型需要使用相同材质的目的，在于其纹理是相同的，这样才可以实现同时渲染的目的。因此保证材质相同，是为了保证被渲染的纹理相同。
Draw Call Batching本身，也还会细分为两种，即Static Batching 静态批处理和Dynamic Batching 动态批处理。
-
Static Batching 静态批处理
对静态批处理下个定义：只要这些物体不移动，并且拥有相同的材质，静态批处理就允许引擎对任意大小的几何物体进行批处理操作来降低描绘调用。
那要如何使用静态批处理来减少Draw Call呢？只需要明确指出哪些物体是静止的，并且在游戏中永远不会移动、旋转和缩放。想完成这一步，只需要在检测器（Inspector）中勾选“Static”复选框即可。
image.png Dynamic Batching 动态批处理
首先要明确一点，Unity 3D的Draw Call动态批处理机制是引擎自动进行的，无须像静态批处理那样手动设置Static。举一个动态实例化Prefab的例子，如果动态物体共享相同的材质，则引擎会自动对Draw Call优化，也就是使用批处理。
总结一下动态批处理的约束，也许能从中找到为什么动态批处理在自己的项目中不起作用的原因。
（1）批处理动态物体需要在每个顶点上进行一定的开销，所以动态批处理仅支持小于900顶点的网格物体。
（2）如果着色器使用顶点位置、法线和UV值3种属性，那么只能批处理300顶点以下的物体；如果着色器需要使用顶点位置、法线、UV0、UV1和切向量，那只能批处理180顶点以下的物体。
（3）不要使用缩放。分别拥有缩放大小（1,1,1）和（2,2,2）的两个物体将不会进行批处理。
（4）统一缩放的物体不会与非统一缩放的物体进行批处理。
（5）使用缩放尺度（1,1,1）和（1,2,1）的两个物体将不会进行批处理，但是使用缩放尺度（1,2,1）和（1,3,1）的两个物体将可以进行批处理。
（6）使用不同材质的实例化物体（instance）将会导致批处理失败。
（7）拥有lightmap的物体含有额外（隐藏）的材质属性，例如lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理（除非它们指向lightmap的同一部分）。
（8）多通道的shader会妨碍批处理操作。比如几乎Unity 3D中所有的着色器在前向渲染中都支持多个光源，并为它们有效地开辟多个通道。
（9）预设体的实例会自动地使用相同的网格模型和材质。
所以这里建议各位开发者尽量使用静态的批处理。对物理组件的优化
第一点是设置一个合适的Fixed Timestep
第二点是尽量不要使用网格碰撞器（mesh collider）。
不选择mesh collider是因为什么原因呢？这是由于mesh collider实在是太过于复杂了。mesh collider利用一个网格资源并在其上构建碰撞器。对于复杂网状模型上的碰撞检测，它要比应用原型碰撞器精确得多。标记为凸起的（Convex）的网格碰撞器才能够和其他网格碰撞器发生碰撞。手机游戏自然无须这种性价比不高的东西。处理内存，却让CPU受伤的GC
虽然GC是用来处理内存的，但的确增加的是CPU的开销。因此它的确能达到释放内存的效果，但代价更加沉重，会加重CPU的负担，因此对于GC的优化目标就是尽量少的触发GC。
首先要明确所谓的GC是Mono运行时的机制，而非Unity 3D游戏引擎的机制，所以GC也主要是针对Mono的对象来说的，而它管理的也是Mono的托管堆。清楚这一点，也就明白了GC不是用来处理引擎的assets（纹理、音效等）的内存释放的，因为Unity 3D引擎也有自己的内存堆，而不是和Mono一起使用所谓的托管堆。
其次要清楚什么东西会被分配到托管堆上，那就是引用类型。比如类的实例、字符串、数组等。而作为int类型、float类型，包括结构体struct其实都是值类型，它们会被分配在堆栈上而非堆上。GC在以下两种情况下会触发。
（1）堆的内存不足时，会自动调用GC。
（2）作为编程人员，自己也可以手动调用GC。
GC的优化说白了也就是代码的优化。
需要注意以下5点：
（1）字符串连接的处理。因为将两个字符串连接的过程，其实是生成一个新的字符串的过程。而之前旧字符串自然而然就成为了垃圾。而作为引用类型的字符串，其空间是在堆上分配的，被弃置的旧字符串的空间会被GC当作垃圾回收。
（2）尽量不要使用foreach语句，而是使用for语句。foreach语句其实会涉及到迭代器的使用，而据说每一次循环所产生的迭代器会带来24Bytes的垃圾。那么循环10次就是240Bytes。
（3）不要直接访问gameobject的tag属性。比如“if (go.tag == “human”)”最好换成“if (go.CompareTag (“human”))”。因为访问物体的tag属性会在堆上额外的分配空间。如果在循环中这么处理，留下的垃圾就可想而知了。
（4）使用“池”，以实现空间的重复利用。
（5）最好不用LINQ的命令，因为它们会分配临时的空间，同样也是GC收集的目标。而且笔者不用LINQ的一点原因就是它有可能在某些情况下无法很好地进行AOT编译。比如“OrderBy”会生成内部的泛型类“OrderedEnumerable”。这在AOT编译时是无法进行的，因为它只是在OrderBy的方法中才使用。所以如果你使用了OrderBy，那么在iOS平台上也许会报错。对代码质量的优化
5个方面需要注意：
（1）以物体的Transform组件为例，我们应该只访问一次，之后就将它的引用保留，而非每次使用都去访问。有人做过一个小实验，就是对比通过方法GetComponent＜Transform＞()获取Transform组件, 通过MonoBehavor的transform属性去获取，以及保留引用之后再去访问所需要的时间。
1）GetComponent=619ms。
2）Monobehaviour=60ms。
3）CachedMB=8ms。
4）Manual Cache=3ms。
（2）最好不要频繁使用GetComponent，尤其是在循环中。
（3）善于使用OnBecameVisible()和OnBecameVisible()来控制物体的update()函数的执行以减少开销。
（4）使用内建的数组，比如用Vector3.zero而不是new Vector(0, 0, 0)。
（5）对于方法的参数的优化，善于使用ref关键字。值类型的参数是通过将实参的值复制到形参，来实现按值传递到方法，也就是通常说的按值传递。“复制”总会让人感觉很笨重。比如“Matrix4x4”这样比较复杂的值类型，如果直接复制一份新的，反而不如将值类型的引用传递给方法作为参数。
