DrawCalls：控制电脑平台上DrawCalls几千个之内，移动平台上DrawCalls200百左右
Verts：PC平台的话保持场景中显示的顶点数少于300W，移动设备的话少于10W，一切取决于你的目标GPU与CPU。
需要注意的是:
如果在Profiler下的GPU中显示的RenderTexture.SetActive()占用率很高的话，那么可能是因为你同时打开了编辑窗口的原因，而不是U3D的BUG。
1、Shader着色器
（1）有些着色器可能是处理器密集型的，因此最好为材质指定移动设备专用的着色器。将着色器从Diffuse修改为Mobile/Diffuse。
（2）shader中用贴图混合的方式去代替多重通道计算。
（3）shader中注意float/half/fixed的使用。
（4）shader中不要用复杂的计算pow,sin,cos,tan,log等。
（5）shader中越少Fragment越好。
（6）自己写的shader请注意复杂操作符计算，类似pow,exp,log,cos,sin,tan等都是很耗时的计算，最多只用一次在每个像素点的计算。不推荐你自己写normalize,dot,inversesqart操作符，内置的肯定比你写的好。
（7）需要警醒的是alpha test，这个非常耗时。
（8）浮点类型运算:精度越低的浮点计算越快。
在CG/HLSL中：float ：32位浮点格式，适合顶点变换运算，但比较慢。
half：16位浮点格式，适合贴图和UV坐标计算，是highp类型计算的两倍。
fixed: 10位浮点格式，适合颜色，光照，和其他。是highp格式计算的四倍。
2、光源
（1）最好使用平行光，点光源和聚光灯消耗资源比较大
（2）限制灯光使用数量，尽可能不用灯光。动态灯光更加不要了。
（3）Lightmapping烘焙灯光，为场景添加光源时要考虑一下，因为有渲染开销。如果你以前做过着色器编程，你会知道为了支持动态光源的渲染，要付出额外的代价。每个光源都需要渲染对象，根据对象使用的着色器、材质计算最终的光源效果，这个计算开销很大。尽可能的在渲染之前就将光源细节“烘焙（bake）” 到对象的纹理中。“烘焙”是使用静态光源效果的渲染方式，可以实现相同的视觉效果，而无需额外的计算开销。
（4）实时阴影技术非常棒，但消耗大量计算。为GPU和CPU都带来了昂贵的负担
（5）灯光的Shadow Type只对PC平台有效，也就是说在移动平台是没有阴影效果的（亲测），另外软阴影更为昂贵，耗资源！！！
（6）light的Render Mode下的Auto是根据附近灯光的亮度和当前质量的设置（Edit ->Project Settings -> Quality ）在运行时确定，Not Important为顶点渲染，Important为像素渲染（更耗资源），但是像素渲染能够实现顶点渲染不能实现的效果，比如实时阴影，因此必须权衡前后照明质量和游戏速度。像素灯的实际数量可以在质量设置（ Edit -> Project Settings -> Quality ）中的进行设置。
3、碰撞器
（1）通常，碰撞器根据复杂度排序，对象越复杂，使用这个对象的性能开销越大。有可能的话，用盒子或者球体(Box/Sphere)来封装对象，这样碰撞器的计算最少。不要用网格碰撞器(Mesh Collider)。
（2）注意碰撞体的碰撞层，不必要的碰撞检测请舍去。
4、贴图纹理
（1）可以把图像纹理或者其它资源共享使用，尽量避免透明，可以使用填充黑色
（2）尝试用压缩贴图格式，或用16位代替32位。图片压缩将降低你的图片大小（更快地加载更小的内存跨度(footprint)），而且大大提高渲染表现。压缩贴图比起未压缩的32位RGBA贴图占用内存带宽少得多。
（3）之前U3D会议还听说过一个优化，贴图尽量都用一个大小的格式（512 * 512 ， 1024 * 1024），这样在内存之中能得到更好的排序，而不会有内存之间空隙。
（4）MIPMAps，跟网页上的略缩图原理一样，在3D游戏中我们为游戏的贴图生成多重纹理贴图，远处显示较小的物体用小的贴图，显示比较大的物体用精细的贴图。这样能更加有效的减少传输给GPU中的数据。但同时也会增加内存的大小，自己根据项目来权衡利弊
（5）如果你做了一个图集是1024X1024的。此时你的界面上只用了图集中的一张很小的图，那么很抱歉1024X1024这张大图都需要载入你的内存里面，1024就是4M的内存，如果你做了10个1024的图集，你的界面上刚好都只用了每个图集里面的一张小图，那么再次抱歉你的内存直接飙40M。意思是任何一个4096的图片，不管是图集还是texture，他都占用4*4=16M？
（6）IOS平台使用PVRTC压缩纹理。Adroid平台使用ETC1格式压缩。均可以减至1/4的内存大小，优化非常明显！目前主流的Android机型基本都支持ETC1格式压缩。但ETC1只能支持非Alpha通道的图片压缩。所以一般把Alpha通道图分离出来，绘制到GPU显存时，a值从Alpha图里获取，无Alpha通道的图就可以使用ETC1压缩。
（7）设置不透明贴图的压缩格式为ETC 4bit，因为android市场的手机中的GPU有多种，每家的GPU支持不同的压缩格式，但他们都兼容ETC格式
对于透明贴图，我们只能选择RGBA 16bit 或者RGBA 32bit。
（8）减少FPS，在ProjectSetting-> Quality中的VSync Count 参数会影响你的FPS，EveryVBlank相当于FPS=60，EverySecondVBlank = 30；
如果这两种情况都不符合游戏的FPS的话，我们需要手动调整FPS，首先关闭垂直同步（VSync = Vertical Sync）这个功能，即设置VSync为Don't Sync
然后在代码的Awake方法里手动设置FPS（Application.targetFrameRate = 45;）
降低FPS的好处：
1）省电，减少手机发热的情况；
2）能都稳定游戏FPS，减少出现卡顿的情况。
（9）当我们设置了FPS后，再调整下Fixed timestep这个参数，这个参数在ProjectSetting->Time中，目的是减少物理计算的次数，来提高游戏性能。
（10）尽量少使用Update LateUpdate FixedUpdate，这样也可以提升性能和节省电量。多使用事件（不是SendMessage，使用自己写的，或者C#中的事件委托）。
（11）待机时，调整游戏的FPS为1，节省电量。
（12）图集大小最好不要高于1024，否则游戏安装之后、低端机直接崩溃、原因是手机系统版本低于2.2、超过1000的图集无法读取导致。2.2 以上没有遇见这个情况。注意手机的RAM 与 ROM、小于 512M的手机、直接放弃机型适配。
（13）不同设备要使用不同的纹理大小，尤其是UI和大型背景中的纹理。《Shadow Blade》使用的是通用型模板，但如果在启动时检测到设备大小和分辨率，就会载入不同资产。
（14）远处的物体绘制在skybox上
5、脚本
（1）如果你不需要运行某一个脚本，那么就禁用它。不管它多少的小，或者出现的很少，但每一个处理都需要占用时间。
（2）不要留着未实现的Update，FixedUpdate等方法，用不到就删除，不然会执行，消耗时间！
（3）移除代码中的任何字符串连接，因为这会给GC留下大量垃圾。使用StringBuilder链接字符串
（4）用简单的“for”循环代替“foreach”循环。由于某些原因，每个“foreach”循环的每次迭代会生成24字节的垃圾内存。一个简单的循环迭代10次就可以留下240字节的垃圾内存。
（5）更改我们检查游戏对象标签的方法。用“if (go.CompareTag (“Enemy”)”来代替“if (go.tag == “Enemy”)” 。在一个内部循环调用对象分配的标签属性以及拷贝额外内存，这是一个非常糟糕的做法。
（6）不使用LINQ命令，因为它们一般会分配中间缓器，而这很容易生成垃圾内存。
（7）修改代码以免依赖“ControllerColliderHit” 回调函数。这证明这些回调函数处理得并不十分迅速。
（8）要谨慎评估触发器的“onInside”回调函数，在我们的项目中，我们尽量在不依赖它们的情况下模拟逻辑。
（9）注意是否有多余的动画脚本，模型自动导入到U3D会有动画脚本，大量的话会严重影响消耗CPU计算。
（10）尽量避免每帧处理,可以每隔几帧处理一次 void Update() { if(Time.frameCount % 5 == 0) { DoSomeThing(); } }
（11）尽量避免使用float，而使用int，特别是在手机游戏中，尽量少用复杂的数学函数，比如sin,cos等函数。改除法/为乘法,例如：使用x*0.5f而不是 x/2.0f 。
（12）避免使用for(int i=0;i<myArray.Length;i++)，而应该这样 int length=myArray.Length; for(int i=0;i<length;i++)
（13）少使用临时变量，特别是在Update OnGUI等实时调用的函数中定义临时变量。
（14）协同是一个好方法。可以使用协同程序来代替不必每帧都执行的方法。（还有InvokeRepeating方法也是一个好的取代Update的方法）。
（15）不要使用SendMessage之类的方法，他比直接调用方法慢了100倍，你可以直接调用或通过C#的委托来实现。
（16）操作transform.localPosition的时候请小心，移动GameObject是非常平常的一件事情，以下代码看起来很简单:
transform.localPosition += new Vector3 ( 10.0f * Time.deltaTime, 0.0f, 0.0f );
但是小心了，假设上面这个GameObject有一个parent, 并且这个parent GameObject的localScale是(2.0f,2.0f,2.0f)。你的GameObject将会移动20.0个单位/秒。
因为该 GameObject的world position等于:
Vector3 offset = new Vector3( my.localPosition.x * parent.lossyScale.x, my.localPosition.y * parent.lossyScale.y, my.localPosition.z * parent.lossyScale.z );
Vector3 worldPosition = parent.position + parent.rotation * offset;
换句话说，上面这种直接操作localPosition的方式是在没有考虑scale计算的时候进行的，为了解决这个问题，unity3d提供了Translate函数，
所以正确的做法应该是:
transform.Translate ( 10.0f * Time.deltaTime, 0.0f, 0.0f );
（17）减少固定增量时间， 将固定增量时间值设定在0.04-0.067区间（即，每秒15-25帧）。您可以通过Edit->Project Settings->Time来改变这个值。这样做降低了FixedUpdate函数被调用的频率以及物理引擎执行碰撞检测与刚 体更新的频率。如果您使用了较低的固定增量时间，并且在主角身上使用了刚体部件，那么您可以启用插值办法来平滑刚体组件。
（18）减少GetComponent的调用使用，GetComponent或内置组件访问器（transform）会产生明显的开销。您可以通过一次获取组件的引用来避免开销，并将该引用分配给一个变量（有时称为"缓存"的引用）。
Transform myTransform ;
void Awake () {
myTransform = transform;
}
（19）同时，在某些可能的情况下，您也可以使用结构（struct）来代替类（class）。这是因为，结构变量主要存放在栈区而非堆区。因为栈的分配较快，并且不调用垃圾回收操作，所以当结构变量比较小时可以提升程序的运行性能。但是当结构体较大时，虽然它仍可避免分配/回收的开销，而它由于"传值"操作也会导致单独的开销，实际上它可能比等效对象类的效率还要低。
（20）使用GUILayout 函数可以很方便地将GUI元素进行自动布局。然而，这种自动化自然也附带着一定的处理开销。您可以通过手动的GUI功能布局来避免这种开销。此外，您也可以设置一个脚本的useGUILayout变量为 false来完全禁用GUI布局：
void Awake () {
useGUILayout = false;
}
（21）最小化碰撞检测请求（例如ray casts和sphere checks），尽量从每次检查中获得更多信息。
（22）在edit->project setting->time中调大FixedTimestep（真实物理的帧率）来减少cpu损耗
（23）尽量不要动态的instantiate和destroy object，使用object pool
（24）尽量不要再update函数中做复杂计算，如有需要，可以隔N帧计算一次
（25）不要使用内置的onGUii函数处理gui，使用其他方案，如NGUI
6、组件
（1）尽可能的使用简单组件—如果你不需求功能较多的组件，那么就自己去实现它避免一起使用大量系统组件。比如，CharacterController是一个很废资源的组件，那么最好使用刚体来定义自己的解决方案。
（2）面对性能更弱的设备，要用skinned mesh代替physics cloth。cloth参数在运行表现中发挥重要作用，如果你肯花些时间找到美学与运行表现之间的平衡点，就可以获得理想的结果。
（3）在物理模拟过程中不要使用ragdolls（ 布娃娃系统），只有在必要时才让它生效。
（4）真实的物理（刚体）很消耗，不要轻易使用，尽量使用自己的代码模仿假的物理
7、NGUI
（1）NGUI中所有Panel都有一个Depth值影响着他下面的所有挂件。如果你正在创建一个使用多个窗口的复杂UI，通常最好的做法是每个窗口有一个UIPanel。请确认你的panel不会拥有相同的depth值。如果这个值是一样的，为了保证绘制顺序，draw call将会开始频繁分割，这将导致产生比平常更多的draw call。
8、顶点数
（1）尽量减少顶点数
9、材质
（1）尽可能共用材质。这样便可以减少DrawCall，引擎可以进行其批处理！
（2）如果你需要通过脚本来控制单个材质属性，需要注意改变Renderer.material将会造成一份材质的拷贝。因此，你应该使用Renderer.sharedMaterial来保证材质的共享状态。
（3）有一个合并模型材质不错的插件叫Mesh Baker
10、特效
（1）如果不需要别用雾效(fog)
（2）要找到美学/性能之间的平衡，就免不了许多粒子效果的迭代。减少发射器数量并尽量减少透明度需求也是一大挑战。
11、模型物体
（1）不要有不必要的三角面。面片数最好控制在300~2000面片
（2）UV贴图中的接缝和硬边越少越好。
需要注意的是，图形硬件需要处理顶点数和硬件报告说的并不一样。不是硬件说能渲染几个点就是几个点。模型处理应用通常展示的是几何顶点数量。例如，一个由一些不同顶点构成的模型。在显卡中，一些集合顶点将会被分离(split)成两个或者更多逻辑顶点用作渲染。如果有法线、UV坐标、顶点色的话，这个顶点必须会被分离。所以在游戏中处理的实际数量显然要多很多。
（3）LOD (Level Of Detail) 是很常用的3D游戏技术了，其功能理解起来则是相当于多重纹理贴图。在以在屏幕中显示模型大小的比例来判断使用高或低层次的模型来减少对GPU的传输数据，和减少GPU所需要的顶点计算。
（4）摄像机分层距离剔除(Per-Layer Cull Distances)：为小物体标识层次，然后根据其距离主摄像机的距离判断是否需要显示。
（5）遮挡剔除（Occlusion Culling）其实就是当某个物体在摄像机前被另外一个物体完全挡住的情况，挡住就不发送给GPU渲染，从而直接降低DRAW CALL。不过有些时候在CPU中计算其是否被挡住则会很耗计算，反而得不偿失。
（6）将不需要移动的物体设为Static，让引擎可以进行其批处理。
（7）用单个蒙皮渲染、尽量少用材质、少用骨骼节点、移动设备上角色多边形保持在300~1500内(当然还要看具体的需求)、PC平台上1500~4000内(当然还要看具体的需求)。
角色的面数一般不要超过1500，骨骼数量少于30就好，越多的骨骼就会越多的带来CPU消耗,角色Material数量一般1~2个为最佳。
（8）导入 3D 模型之后，在不影响显示效果的前提下，最好打开 Mesh Compression。Off, Low, Medium, High 这几个选项，可酌情选取。
（9）避免大量使用unity自带的 Sphere 等内建 Mesh，Unity 内建的 Mesh，多边形的数量比较大，如果物体不要求特别圆滑，可导入其他的简单3D模型代替。
（10）每个角色尽量使用一个Skinned Mesh Renderer,这是因为当角色仅有一个 Skinned Mesh Renderer 时，Unity 会使用视锥型可见性裁剪和多边形网格包围体更新的方法来优化角色的运动，而这种优化只有在角色仅含有一个 Skinned Mesh Renderer时才会启动。
（11）对于静态物体顶点数要求少于500，UV的取值范围不要超过（0,1）区间，这对于纹理的拼合优化很有帮助。
（12）不需要的Animation组件就删掉
12、粒子系统
（1）粒子系统运行在iPhone上时很慢，怎么办？因为iPhone拥有相对较低的fillrate 。如果您的粒子效果覆盖大部分的屏幕，而且是multiple layers的，这样即使最简单的shader，也能让iPhone傻眼。我们建议把您的粒子效果baking成纹理序列图。然后在运行时可以使用1-2个粒子，通过动画纹理来显示它们。这种方式可以取得很好的效果，以最小的代价。
自带地形：地形高度图尺寸小于257，尽量使用少的混合纹理数目，尽量不要超过4个，Unity自带的地形时十分占资源的，强烈建议不要使用，自己制作地形，尽量一张贴图搞定
- drawcall是啥？draw：绘制，call：调用，其实就是对底层图形程序（比如：OpenGL ES)接口的调用，以在屏幕上画出东西。那么，是谁去调用这些接口呢？CPU。
- fragment是啥？经常有人说vf啥的，vertex我们都知道是顶点，那fragment是啥呢？说它之前需要先说一下像素，像素各位应该都知道吧？像素是构成数码影像的基本单元呀。那fragment呢？是有可能成为像素的东西。啥叫有可能？就是最终会不会被画出来不一定，是潜在的像素。这会涉及到谁呢？GPU。
- batching是啥？都知道批处理是干嘛的吧？没错，将批处理之前需要很多次调用（drawcall）的物体合并，之后只需要调用一次底层图形程序的接口就行。听上去这简直就是优化的终极方案啊！但是，理想是美好的，世界是残酷的，一些不足之后我们再细聊。
- 内存的分配：记住，除了Unity3D自己的内存损耗。我们可是还带着Mono呢啊，还有托管的那一套东西呢。更别说你一激动，又引入了自己的几个dll。这些都是内存开销上需要考虑到的。
- CPU方面
上文中说了，drawcall影响的是CPU的效率，而且也是最知名的一个优化点。但是除了drawcall之外，还有哪些因素也会影响到CPU的效率呢？让我们一一列出暂时能想得到的：
（1）DrawCalls
（2）物理组件（Physics）
（3）GC（什么？GC不是处理内存问题的嘛？匹夫你不要骗我啊！不过，匹夫也要提醒一句，GC是用来处理内存的，但是是谁使用GC去处理内存的呢？）
（4）当然，还有代码质量
DrawCalls：
前面说过了，DrawCall是CPU调用底层图形接口。比如有上千个物体，每一个的渲染都需要去调用一次底层接口，而每一次的调用CPU都需要做很多工作，那么CPU必然不堪重负。但是对于GPU来说，图形处理的工作量是一样的。所以对DrawCall的优化，主要就是为了尽量解放CPU在调用图形接口上的开销。所以针对drawcall我们主要的思路就是每个物体尽量减少渲染次数，多个物体最好一起渲染。所以，按照这个思路就有了以下几个方案：
- 使用Draw Call Batching，也就是描绘调用批处理。Unity在运行时可以将一些物体进行合并，从而用一个描绘调用来渲染他们。具体下面会介绍。
- 通过把纹理打包成图集来尽量减少材质的使用。
- 尽量少的使用反光啦，阴影啦之类的，因为那会使物体多次渲染。
Draw Call Batching
首先我们要先理解为何2个没有使用相同材质的物体即使使用批处理，也无法实现Draw Call数量的下降和性能上的提升。
因为被“批处理”的2个物体的网格模型需要使用相同材质的目的，在于其纹理是相同的，这样才可以实现同时渲染的目的。因而保证材质相同，是为了保证被渲染的纹理相同。
因此，为了将2个纹理不同的材质合二为一，我们就需要进行上面列出的第二步，将纹理打包成图集。具体到合二为一这种情况，就是将2个纹理合成一个纹理。这样我们就可以只用一个材质来代替之前的2个材质了。
而Draw Call Batching本身，也还会细分为2种。
Static Batching 静态批处理
看名字，猜使用的情景。
静态？那就是不动的咯。还有呢？额，听上去状态也不会改变，没有“生命”，比如山山石石，楼房校舍啥的。那和什么比较类似呢？嗯，聪明的各位一定觉得和场景的属性很像吧！所以我们的场景似乎就可以采用这种方式来减少draw call了。
那么写个定义：只要这些物体不移动，并且拥有相同的材质，静态批处理就允许引擎对任意大小的几何物体进行批处理操作来降低描绘调用。
那要如何使用静态批来减少Draw Call呢？你只需要明确指出哪些物体是静止的，并且在游戏中永远不会移动、旋转和缩放。想完成这一步，你只需要在检测器（Inspector）中将Static复选框打勾即可！
至于效果如何呢？
举个例子：新建4个物体，分别是Cube，Sphere, Capsule, Cylinder,它们有不同的网格模型，但是也有相同的材质（Default-Diffuse）。
首先，我们不指定它们是static的。Draw Call的次数是4次，如图：
我们现在将它们4个物体都设为static，在来运行一下：
如图，Draw Call的次数变成了1，而Saved by batching的次数变成了3。
静态批处理的好处很多，其中之一就是与下面要说的动态批处理相比，约束要少很多。所以一般推荐的是draw call的静态批处理来减少draw call的次数。那么接下来，我们就继续聊聊draw call的动态批处理。
Dynamic Batching 动态批处理
有阴就有阳，有静就有动，所以聊完了静态批处理，肯定跟着就要说说动态批处理了。首先要明确一点，Unity3D的draw call动态批处理机制是引擎自动进行的，无需像静态批处理那样手动设置static。我们举一个动态实例化prefab的例子，如果动态物体共享相同的材质，则引擎会自动对draw call优化，也就是使用批处理。首先，我们将一个cube做成prefab，然后再实例化50次，看看draw call的数量。
for(int i = 0; i < 50; i++) { GameObject cube; cube = GameObject.Instantiate(prefab) as GameObject; }
draw call的数量：
可以看到draw call的数量为1，而 saved by batching的数量是49。而这个过程中，我们除了实例化创建物体之外什么都没做。不错，unity3d引擎为我们自动处理了这种情况。
但是有很多童靴也遇到这种情况，就是我也是从prefab实例化创建的物体，为何我的draw call依然很高呢？这就是匹夫上文说的，draw call的动态批处理存在着很多约束。下面匹夫就演示一下，针对cube这样一个简单的物体的创建，如果稍有不慎就会造成draw call飞涨的情况吧。
我们同样是创建50个物体，不同的是其中的10个物体，每个物体的大小都不同，也就是Scale不同。
for(int i = 0; i < 50; i++) { GameObject cube; cube = GameObject.Instantiate(prefab) as GameObject; if(i / 10 == 0) { cube.transform.localScale = new Vector3(2 + i, 2 + i, 2 + i); } }
我们看到draw call的数量上升到了11次，而saved by batching的数量也下降到了39。各位看官可以看到，仅仅是一个简单的cube的创建，如果scale不同，竟然也不会去做批处理优化。这仅仅是动态批处理机制的一种约束，那我们总结一下动态批处理的约束，各位也许也能从中找到为何动态批处理在自己的项目中不起作用的原因：
- 批处理动态物体需要在每个顶点上进行一定的开销，所以动态批处理仅支持小于900顶点的网格物体。
- 如果你的着色器使用顶点位置，法线和UV值三种属性，那么你只能批处理300顶点以下的物体；如果你的着色器需要使用顶点位置，法线，UV0，UV1和切向量，那你只能批处理180顶点以下的物体。
- 不要使用缩放。分别拥有缩放大小(1,1,1) 和(2,2,2)的两个物体将不会进行批处理。
- 统一缩放的物体不会与非统一缩放的物体进行批处理。
- 使用缩放尺度(1,1,1) 和 (1,2,1)的两个物体将不会进行批处理，但是使用缩放尺度(1,2,1) 和(1,3,1)的两个物体将可以进行批处理。
- 使用不同材质的实例化物体（instance）将会导致批处理失败。
- 拥有lightmap的物体含有额外（隐藏）的材质属性，比如：lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理（除非他们指向lightmap的同一部分）。
- 多通道的shader会妨碍批处理操作。比如，几乎unity中所有的着色器在前向渲染中都支持多个光源，并为它们有效地开辟多个通道。
- 预设体的实例会自动地使用相同的网格模型和材质。
所以，尽量使用静态的批处理。
物理组件
1.设置一个合适的Fixed Timestep。设置的位置：Edit → Project Settings → Time
那何谓“合适”呢？首先我们要搞明白Fixed Timestep和物理组件的关系。物理组件，或者说游戏中模拟各种物理效果的组件，最重要的是什么呢？计算啊。对，需要通过计算才能将真实的物理效果展现在虚拟的游戏中。那么Fixed Timestep这货就是和物理计算有关的啦。所以，若计算的频率太高，自然会影响到CPU的开销。同时，若计算频率达不到游戏设计时的要求，有会影响到功能的实现，所以如何抉择需要各位具体分析，选择一个合适的值。
2.就是不要使用网格碰撞器（mesh collider）：为啥？因为实在是太复杂了。网格碰撞器利用一个网格资源并在其上构建碰撞器。对于复杂网状模型上的碰撞检测，它要比应用原型碰撞器精确的多。标记为凸起的（Convex ）的网格碰撞器才能够和其他网格碰撞器发生碰撞。各位上网搜一下mesh collider的图片，自然就会明白了。我们的手机游戏自然无需这种性价比不高的东西。
当然，从性能优化的角度考虑，物理组件能少用还是少用为好。
处理内存，却让CPU受伤的GC
在CPU的部分聊GC，感觉是不是怪怪的？其实小匹夫不这么觉得，虽然GC是用来处理内存的，但的确增加的是CPU的开销。因此它的确能达到释放内存的效果，但代价更加沉重，会加重CPU的负担，因此对于GC的优化目标就是尽量少的触发GC。
首先我们要明确所谓的GC是Mono运行时的机制，而非Unity3D游戏引擎的机制，所以GC也主要是针对Mono的对象来说的，而它管理的也是Mono的托管堆。 搞清楚这一点，你也就明白了GC不是用来处理引擎的assets（纹理啦，音效啦等等）的内存释放的，因为U3D引擎也有自己的内存堆而不是和Mono一起使用所谓的托管堆。
其次我们要搞清楚什么东西会被分配到托管堆上？不错咯，就是引用类型咯。比如类的实例，字符串，数组等等。而作为int，float，包括结构体struct其实都是值类型，它们会被分配在堆栈上而非堆上。所以我们关注的对象无外乎就是类实例，字符串，数组这些了。
那么GC什么时候会触发呢？两种情况：
- 首先当然是我们的堆的内存不足时，会自动调用GC。
- 其次呢，作为编程人员，我们自己也可以手动的调用GC。
所以为了达到优化CPU的目的，我们就不能频繁的触发GC。而上文也说了GC处理的是托管堆，而不是Unity3D引擎的那些资源，所以GC的优化说白了也就是代码的优化。那么匹夫觉得有以下几点是需要注意的：
- 字符串连接的处理。因为将两个字符串连接的过程，其实是生成一个新的字符串的过程。而之前的旧的字符串自然而然就成为了垃圾。而作为引用类型的字符串，其空间是在堆上分配的，被弃置的旧的字符串的空间会被GC当做垃圾回收。
- 尽量不要使用foreach，而是使用for。foreach其实会涉及到迭代器的使用，而据传说每一次循环所产生的迭代器会带来24 Bytes的垃圾。那么循环10次就是240Bytes。
- 不要直接访问gameobject的tag属性。比如if (go.tag == “human”)最好换成if (go.CompareTag (“human”))。因为访问物体的tag属性会在堆上额外的分配空间。如果在循环中这么处理，留下的垃圾就可想而知了。
- 使用“池”，以实现空间的重复利用。
- 最好不用LINQ的命令，因为它们会分配临时的空间，同样也是GC收集的目标。而且我很讨厌LINQ的一点就是它有可能在某些情况下无法很好的进行AOT编译。比如“OrderBy”会生成内部的泛型类“OrderedEnumerable”。这在AOT编译时是无法进行的，因为它只是在OrderBy的方法中才使用。所以如果你使用了OrderBy，那么在IOS平台上也许会报错。
代码？脚本？
聊到代码这个话题，也许有人会觉得匹夫多此一举。因为代码质量因人而异，很难像上面提到的几点，有一个明确的评判标准。也是，公写公有理，婆写婆有理。但是匹夫这里要提到的所谓代码质量是基于一个前提的：Unity3D是用C++写的，而我们的代码是用C#作为脚本来写的，那么问题就来了~脚本和底层的交互开销是否需要考虑呢？也就是说，我们用Unity3D写游戏的“游戏脚本语言”，也就是C#是由mono运行时托管的。而功能是底层引擎的C++实现的，“游戏脚本”中的功能实现都离不开对底层代码的调用。那么这部分的开销，我们应该如何优化呢？
- 以物体的Transform组件为例，我们应该只访问一次，之后就将它的引用保留，而非每次使用都去访问。这里有人做过一个小实验，就是对比通过方法GetComponent<Transform>()获取Transform组件, 通过MonoBehavor的transform属性去取，以及保留引用之后再去访问所需要的时间：
- GetComponent = 619ms
- Monobehaviour = 60ms
- CachedMB = 8ms
- Manual Cache = 3ms
2.如上所述，最好不要频繁使用GetComponent，尤其是在循环中。
3.善于使用OnBecameVisible()和OnBecameVisible(),来控制物体的update()函数的执行以减少开销。
4.使用内建的数组，比如用Vector3.zero而不是new Vector(0, 0, 0);
5.对于方法的参数的优化：善于使用ref关键字。值类型的参数，是通过将实参的值复制到形参，来实现按值传递到方法，也就是我们通常说的按值传递。复制嘛，总会让人感觉很笨重。比如Matrix4x4这样比较复杂的值类型，如果直接复制一份新的，反而不如将值类型的引用传递给方法作为参数。
好啦，CPU的部分匹夫觉得到此就介绍的差不多了。下面就简单聊聊其实匹夫并不是十分熟悉的部分，GPU的优化。
GPU的优化
GPU与CPU不同，所以侧重点自然也不一样。GPU的瓶颈主要存在在如下的方面：
- 填充率，可以简单的理解为图形处理单元每秒渲染的像素数量。
- 像素的复杂度，比如动态阴影，光照，复杂的shader等等
- 几何体的复杂度（顶点数量）
- 当然还有GPU的显存带宽
那么针对以上4点，其实仔细分析我们就可以发现，影响的GPU性能的无非就是2大方面，一方面是顶点数量过多，像素计算过于复杂。另一方面就是GPU的显存带宽。那么针锋相对的两方面举措也就十分明显了。
减少绘制的数目
那么第一个方面的优化也就是减少顶点数量，简化复杂度，具体的举措就总结如下了：
- 保持材质的数目尽可能少。这使得Unity更容易进行批处理。
- 使用纹理图集（一张大贴图里包含了很多子贴图）来代替一系列单独的小贴图。它们可以更快地被加载，具有很少的状态转换，而且批处理更友好。
- 如果使用了纹理图集和共享材质，使用Renderer.sharedMaterial 来代替Renderer.material 。
- 使用光照纹理(lightmap)而非实时灯光。
- 使用LOD，好处就是对那些离得远，看不清的物体的细节可以忽略。
- 遮挡剔除（Occlusion culling）
- 使用mobile版的shader。因为简单。
优化显存带宽
第二个方向呢？压缩图片，减小显存带宽的压力。
- OpenGL ES 2.0使用ETC1格式压缩等等，在打包设置那里都有。
- 使用mipmap。
上面是一个mipmap 如何储存的例子，左边的主图伴有一系列逐层缩小的备份小图
是不是很一目了然呢？Mipmap中每一个层级的小图都是主图的一个特定比例的缩小细节的复制品。因为存了主图和它的那些缩小的复制品，所以内存占用会比之前大。但是为何又优化了显存带宽呢？因为可以根据实际情况，选择适合的小图来渲染。所以，虽然会消耗一些内存，但是为了图片渲染的质量（比压缩要好），这种方式也是推荐的。
内存的优化
既然要聊Unity3D运行时候的内存优化，那我们自然首先要知道Unity3D游戏引擎是如何分配内存的。大概可以分成三大部分：
- Unity3D内部的内存
- Mono的托管内存
- 若干我们自己引入的DLL或者第三方DLL所需要的内存。
第3类不是我们关注的重点，所以接下来我们会分别来看一下Unity3D内部内存和Mono托管内存，最后还将分析一个官网上Assetbundle的案例来说明内存的管理。
Unity3D内部内存
Unity3D的内部内存都会存放一些什么呢？各位想一想，除了用代码来驱动逻辑，一个游戏还需要什么呢？对，各种资源。所以简单总结一下Unity3D内部内存存放的东西吧：
- 资源：纹理、网格、音频等等
- GameObject和各种组件。
- 引擎内部逻辑需要的内存：渲染器，物理系统，粒子系统等等
Mono托管内存
因为我们的游戏脚本是用C#写的，同时还要跨平台，所以带着一个Mono的托管环境显然必须的。那么Mono的托管内存自然就不得不放到内存的优化范畴中进行考虑。那么我们所说的Mono托管内存中存放的东西和Unity3D内部内存中存放的东西究竟有何不同呢？其实Mono的内存分配就是很传统的运行时内存的分配了：
- 值类型：int型啦，float型啦，结构体struct啦，bool啦之类的。它们都存放在堆栈上（注意额，不是堆所以不涉及GC）。
- 引用类型：其实可以狭义的理解为各种类的实例。比如游戏脚本中对游戏引擎各种控件的封装。其实很好理解，C#中肯定要有对应的类去对应游戏引擎中的控件。那么这部分就是C#中的封装。由于是在堆上分配，所以会涉及到GC。
而Mono托管堆中的那些封装的对象，除了在在Mono托管堆上分配封装类实例化之后所需要的内存之外，还会牵扯到其背后对应的游戏引擎内部控件在Unity3D内部内存上的分配。
举一个例子：
一个在.cs脚本中声明的WWW类型的对象www，Mono会在Mono托管堆上为www分配它所需要的内存。同时，这个实例对象背后的所代表的引擎资源所需要的内存也需要被分配。
一个WWW实例背后的资源：
- 压缩的文件
- 解压缩所需的缓存
- 解压缩之后的文件
如图：
那么下面就举一个AssetBundle的例子：
Assetbundle的内存处理
以下载Assetbundle为例子，聊一下内存的分配。匹夫从官网的手册上找到了一个使用Assetbundle的情景如下：
IEnumerator DownloadAndCache (){ // Wait for the Caching system to be ready while (!Caching.ready) yield return null; // Load the AssetBundle file from Cache if it exists with the same version or download and store it in the cache using(WWW www = WWW.LoadFromCacheOrDownload (BundleURL, version)){ yield return www; //WWW是第1部分 if (www.error != null) throw new Exception("WWW download had an error:" + www.error); AssetBundle bundle = www.assetBundle;//AssetBundle是第2部分 if (AssetName == "") Instantiate(bundle.mainAsset);//实例化是第3部分 else Instantiate(bundle.Load(AssetName)); // Unload the AssetBundles compressed contents to conserve memory bundle.Unload(false); } // memory is freed from the web stream (www.Dispose() gets called implicitly) } }
内存分配的三个部分匹夫已经在代码中标识了出来：
- Web Stream：包括了压缩的文件，解压所需的缓存，以及解压后的文件。
- AssetBundle：Web Stream中的文件的映射，或者说引用。
- 实例化之后的对象：就是引擎的各种资源文件了，会在内存中创建出来。
那就分别解析一下：
WWW www = WWW.LoadFromCacheOrDownload (BundleURL, version)
- 将压缩的文件读入内存中
- 创建解压所需的缓存
- 将文件解压，解压后的文件进入内存
- 关闭掉为解压创建的缓存
AssetBundle bundle = www.assetBundle;
- AssetBundle此时相当于一个桥梁，从Web Stream解压后的文件到最后实例化创建的对象之间的桥梁。
- 所以AssetBundle实质上是Web Stream解压后的文件中各个对象的映射。而非真实的对象。
- 实际的资源还存在Web Stream中，所以此时要保留Web Stream。
Instantiate(bundle.mainAsset);
- 通过AssetBundle获取资源，实例化对象
最后各位可能看到了官网中的这个例子使用了：
using(WWW www = WWW.LoadFromCacheOrDownload (BundleURL, version)){ }
这种using的用法。这种用法其实就是为了在使用完Web Stream之后，将内存释放掉的。因为WWW也继承了idispose的接口，所以可以使用using的这种用法。其实相当于最后执行了：
//删除Web Stream www.Dispose();
OK,Web Stream被删除掉了。那还有谁呢？对Assetbundle。那么使用
//删除AssetBundle bundle.Unload(false);
尽可能地减少 Drawcall 的数量。
减少的方法主要有如下几种： Frustum Culling ，Occlusion Culling ， Texture Packing 。
Frustum Culling 是 Unity 内建的，我们需要做的就是寻求一个合适的远裁剪平面；
Occlusion Culling ，遮挡剔除， Unity 内嵌了 Umbra ，一个非常好 OC 库。
但 Occlusion Culling 也并不是放之四海而皆准的，有时候进行 OC 反而比不进行还要慢，
建议在 OC 之前先确定自己的场景是否适合利用 OC 来优化； Texture Packing ，或者叫 Texture Atlasing ，
是将同种 shader 的纹理进行拼合，根据 Unity 的 static batching 的特性来减少 draw call 。
建议使用，但也有弊端，那就是一定要将场景中距离相近的实体纹理进行拼合，否则，拼合后很可能会增加每帧渲染所需的纹理大小，加大内存带宽的负担。这也就是为什么会出现“ DrawCall 降了，渲染速度也变慢了”的原因。
