一、脚本上的优化
1、在使用数组或ArrayList对象时应当注意
length=myArray.Length;
for(inti=0;i
{
}
避免
for(inti=0;i
{
}
2、如果没有必要每帧都处理，则可以每隔几帧处理一次
voidUpdate（）{if（Time.frameCount%6==0） { DoSomething(); }}
3、定时重复调用可以使用InvokeRepeating函数实现，比如，启动0.5秒后每隔1秒执行一次 DoSomeThing 函数：
voidStart()
{
InvokeRepeating("DoSomeThing", 0.5f, 1.0f);
}
4、少使用临时变量，特别是在Update OnGUI等实时调用的函数中。
voidUpdate()
{
Vector3 pos;
pos=transform.position;
}
可以改为：
privateVector3 pos;
voidUpdate()
{
pos=transform.position;
}
5、主动进行垃圾回收
voidUpdate()
{
if(Time.frameCount%50==0)
{
System.GC.Collection();
}
}
6、优化数学运算，尽量避免使用float，而使用int，特别是在手机游戏中，尽量少用复杂的数学函数，比如sin,cos等函数。改除法/为乘法,例如：使用x*0.5f而不是 x/2.0f 。
7、压缩 Mesh
导入 3D 模型之后，在不影响显示效果的前提下，最好打开 Mesh Compression。Off, Low, Medium, High 这几个选项，可酌情选取。对于单个Mesh最好使用一个材质。
8、 运行时尽量减少 Tris 和 Draw Calls
预览的时候，可点开 Stats，查看图形渲染的开销情况。特别注意 Tris 和 Draw Calls 这两个参数。一般来说，要做到：Tris 保持在 7.5k 以下 ，Draw Calls 保持在 35 以下。
9、避免大量使用 Unity 自带的 Sphere 等内建 Mesh
Unity 内建的 Mesh，多边形的数量比较大，如果物体不要求特别圆滑，可导入其他的简单3D模型代替。
10、如果可能，将GameObject上不必要的脚本disable掉。如果你有一个大的场景在你的游戏中，并且敌方的位置在数千米意外，这是你可以disable你的敌方AI脚本直到它们接近摄像机为止。一个好的途径来开启或关闭GameObject是使用SetActiveRecursively(false），并且球形或盒型碰撞器设为trigger。
11、删除空的Update方法。当通过Assets目录创建新的脚本时，脚本里会包括一个Update方法，当你不使用时删除它。
12、引用一个游戏对象的最合乎逻辑的组件。有人可能会这样写someGameObject.transform，gameObject.rigidbody.transform.gameObject.rigidbody.transform，但是这样做了一些不必要的工作，你可以在最开始的地方引用它，像这样：
privateTransform myTrans;
void Start()
{
myTrans=transform;
}
13、协同是一个好方法。可以使用协同程序来代替不必每帧都执行的方法。（还有InvokeRepeating方法也是一个好的取代Update的方法）。
14、尽可能不要再Update或FixedUpdate中使用搜索方法（例如GameObject.Find()），你可以像前面那样在Start方法里获得它。
15、不要使用SendMessage之类的方法，他比直接调用方法慢了100倍，你可以直接调用或通过C#的委托来实现。
16、使用javascript或Boo语言时，你最好确定变量的类型，不要使用动态类型，这样会降低效率，你可以在脚本开头使用#pragmastrict 来检查，这样当你编译你的游戏时就不会出现莫名其妙的错误了。
二、优化图像性能
Unity3D性能优化专题性能优化是一个异常繁琐而又涉及到项目开发的方方面面的一个过程，它的本质是在运行时的一个时间里尽可能完美展现丰富的内容。实现优化可以通过优化资源、渲染、粒子、物理等模式；也可以通过修改模型大小、减少纹理尺寸并结合Unity3D的一些相关特性来提升游戏的性能。随着移动端的设备硬件能力的提升，如何使用尽可能优化的资源和程序效率来展现出更多的细节内容就成为了每个开发者都应该思考的内容，这也使得优化变成了项目开发中非常重要的一环。
***********首先介绍下draw call（这个东西越少你的游戏跑的越快）：在游戏中每一个被展示的独立的部分都被放在了一个特别的包中，我们称之为“描绘指令”（draw call），然后这个包传递到3D部分在屏幕上呈现出来。这就和你希望你的亲友收到准备好的圣诞礼物需要包装好然后穿过城市准时放在他应该出现的地方一样没什么不同。你的CPU来完成包装和传递他们的活，同时会消耗很多的带宽，所以最终分配好这些关键性资源很重要。目前，真正可怕的事情是从描绘指令消耗远景开始，每一个独立的飞溅到地板上的血迹和一个角色或者一具死尸消耗的字节是一样的多的：他们都消耗同样的描绘指令。除此之外，没有什么更多的差别。那么如何降低draw call呢？？那么我们就用到Culling(剔除）技术。如果不应用这个技术，电脑是不管3721把场景里所有的东西都送去渲染的。看得见的也渲染，看不见得照样也送去渲染。很傻是吧，那咋办呢。得告诉电脑，那个你看得见的渲染，看不见的就算了。于是就有了1.视锥体剔除（Frustum Culling）这个unity系统自带了好像，就不用操心了。2.遮挡剔除（Occlusion Culling）
***********
输出设置相关:1:最终输出的时候,在unity - edit - project setting - player里,把other settings - script call optimization改成 快速,但没有例外. fast but no exceptions
2: unity - edit - project setting - time里,把maximum allowed timestep改成0.1
3:
常规优化1:联结(combine)优化显卡对于一个含100个面片的物体的和含1500个面片的物体的渲染消耗几乎是等价的。所以如果你有N个同一材质的东西，那么把他们联成同一个物体再统一用一个material那么对于显卡的渲染消耗就要降低N倍。
在unity里再联结，这个要怎么做呢，其实也挺简单的，经常看Island Demo项目的人应该很早就注意到里面的石头这些都是连在一起的，原因就在这里,他提供了现成就脚本实现联结。先到Island Demo的Assets/Script下找到CombineChildren.cs和MeshCombineUtility.cs两个脚本复制到自己的项目文件（我们要用的只是前者，但他会调用后者，没有后者unity会报错，所以把后者扔到项目里不管就好）然后把你项目里那些用同一Materials的东西扔到一个空物体里面去，再把CombineChildren.cs贴到那个空物体上，搞定！
2:模型(1)只用一个mesh renderer,少用多materials,最多3个每个角色尽量使用一个Skinned Mesh Renderer这是因为当角色仅有一个Skinned Mesh Renderer时，Unity会 使用可见性裁剪和包围体更新的方法来优化角色的运动，而这种优化只有在角色仅含有一个Skinned Mesh Renderer时才会启动。(2)模型骨骼不超过30个.(3)尽量减少面300-1500(4)模型尽量不要分开,如果多个模块,会多次调用dc(5)一般角色应该没有IK结点这是因为角色的动作大多数都是事先设定好的，并不需要经过IK操作来进行实时计算（Rogdoll除外），所以在模型导入时，不要将IK结点一起导入。(6)不要附加Animation Component在静态实体上附加Animation部件虽然对结果没有影响，但却会增加一定的CPU开销来调用这一组件，所以尽量去掉该组件。
3:尽量不用像素光(pixels Lights)
4:不用 软阴影(soft shadow),或者不用阴影(No Shadows)灯光能不用就不用,阴影可以用面来代替.
7:动态物体的相关优化优化主要分为两个方向，一个是资源相关优化和引擎相关的优化。资源相关的优化，大概分为动态物体、静态物体、纹理数据、音频数据、程序包数据。对于动态物体比如NPC、怪物等，需要对面片数量的控制，大概在300到2000面。1500面就可以体现人物细节，但如果是人物比较多，可能要降低面数，不要低于300。另外，一方面是控制Skinned Mesh Renderer的数量；另一方面是控制材质数量在1到3种。人物最好用小于30根骨骼，如果你用的骨骼越多，耗费的CPU就更多，所以在移动平台上尽量少于30根。现在我们看其他动态物体，利用Dynamic Batching进行合批。这个下雨特效并不是系统做的，是包含很多雨点的网格进行重复拷贝，然后错乱移动实现的。每一个雨点并不是一个粒子，这样能减少很多CPU的消耗，每一个整体网格都会有一个顶点的控制，通过控制顶点数量，对系统实现雨点效果来说，这是一个相当省时省力的方法。8:静态物体的相关优化下面我们来看静态物体，静态物体也是要控制面数和顶点数，顶点数少于500个。static是不会进行移动缩放、旋转的，把它标记为static，当然他们的材质是一样的。不要添加animation组建，对于静态物体来说，这个组件毫无意义，能把他丢掉就丢掉，因为这对CPU的消耗是非常客观的。
9:音频程序的优化关于音频时间的播放，比如背景音乐，建议使用MP3压缩格式，比如音效，要求数据尽快加载，这些数据比较小就可以，使用WAV和AIF未压缩音频格式。关于程序包的优化，很多开发者会埋怨说打出来的包太大，现在介绍减少程序包的方法，首先使用压缩格式的纹理，以显卡的压缩格式保存，使用压缩网格和动画数据。网格压缩是先采用量化处理，当然这个压缩是保证在包里面的数据小，但运行时占用的内存没有减少，因为我们并没有把顶点删除，但是对动画数据来说，动画数据经过压缩处理后降低，可以减少游戏列层。
关于代码尽量不要使用System.xml，我们建议使用Mono.xml。启用Stripping来减少库的大小，使用剥离方式。
10:引擎相关优化和物理相关优化下来是引擎相关的优化，例如光照设置、相继设置、粒子特效、物理特效等。那拿光照设置来说，光源全部的实时光照这是很恐怖的，每一次实施光照代表着每一次使用消耗，怎么优化？有人使用LightMapping来制作静态场景，他的好处是不需要用多张实施光照，而给场景很好的光照效果。有人使用Light Probes代替实时光照，好处是完全不用怎么消耗，而且运作性能也非常高。在有些时候使用Light Probes代替光照，他能跟场景很好的融合，在一个角落里，这个任务会被阴影打得暗一些。如果说场景中确实需要一些实时光源，那么肯定是需要做过优化设置的实时光源，控制important的光源个数。如果说光源有些地方产生了交叉光，这个时候你可以通过设置Pxel Light，控制每一个光源都只接受一个动态光照，数目大概是1—2个。对于关闭光源的实时阴影，并不是所有平台都支持实时阴影，消耗也非常大，不建议大家使用。关于相机方面的设置，平面越近，渲染越少。我们更建议使用分层，比如远处的建筑，对于建筑物的裁减平面远一些，如果是花草，就可以使用平面就近一些。现在看一下粒子特效，粒子也是游戏中需要优化的东西，建议屏幕中最大的粒子数不要超过200，同时每个发射器发射的最大粒子数不要超过50。粒子尺寸也要尽可能小，最终在屏幕有多少像素。他们中间的像素可能会被渲染很多次，至少四五次，这时发现粒子系统仅像素就填充了更多屏幕，这时候对游戏来说非常耗费，对游戏的其他功能性能也有所影响。另外一方面，对于非常小的粒子，尽量不要开启粒子碰撞功能。现在我们看一下物理相关优化，物理尽可能使用Sphere Coillider、Box Coillider等，尽量避免使用Meh Colllider等。渲染设置，避免使用Alpha Test，因为非常耗时，性价比很低。关于Sttic Batching，对静态物体进行Batch，对几何数据的大小没有限制。物体被合并后会带来一些内存消耗，比如说有控制网格的物体，用Batch会合并成大物体。Dynamic Batching目前仅支持小于900顶点的网格物体。如何理解900呢，其实就相当于900个顶点数据大小的物体，如果说使用Position、Normal和UV三种属性，那么你只能Batch300个顶点。整体缩放的物体不能被Batch，除非他们的缩放值相同。之前有一个客户做特效，使用Batch机制把面片合并，最终让所有面片共享一个纹理，这时候发现这些面片没有被Batch出来，导致运行游戏时大概放三个技能就10多个招套。对于非整体用户体，他们的Batch是需要很好利用到。11:纹理合并优化现在来看纹理合并，纹理合并就是为了特到Batch数量，合并物体首先需要合并工具，还要修改使用纹理的网格的UV，使他们使用纹理。合并纹理主要是参照Batch，提高渲染性能。但在合并材质后需要注意的是脚本访问Renderer被拷贝。/*安挡剔除，建议使用PVS技术。建议大家使用自定义shader，例如高光效果，高光效果可能不需要做一些入射线的检测，只是简单把他的值放大也可以模拟高光效果，从而减少一些消耗。
另外一个是用profiler，通过他给的数据进行针对性的优化。以上是跟大家介绍优化的内容，如何作出良好优化，一定要做好良好的规划，到后期就不会很麻烦，如果规划没有做好有可能会给程序带来很大压力，结果可能很不乐观。*/最后，要不断实验不断总结才能达到自己满意的效果。
12:要想降低Drawcal的话，有如下两点小建议（1）不要用Unity自带UI或者iGUI,用NUI或者EZ GUI(2)创建好的GameObject不用了就最好及时 删除/设置active为false/移出屏幕 。 这几种方法都可以去掉该物体导致增加的Drawcall
13:
***************************************************************************************************最近一段时间一直在做Unity在IOS设备上的资源优化，结合Unity的官方文档以及自己遇到的实际问题，我把自己认为一些重要的信息罗列在下面，并尽可能对将其量化，以方便更多需要做优化的朋友。
1、 角色每个角色尽量使用一个Skinned Mesh Renderer这是因为当角色仅有一个Skinned Mesh Renderer时，Unity会 使用可见性裁剪和包围体更新的方法来优化角色的运动，而这种优化只有在角色仅含有一个Skinned Mesh Renderer时才会启动。角色Material数量2-3个骨骼数量小于30个面片数量300-1500一般角色应该没有IK结点这是因为角色的动作大多数都是事先设定好的，并不需要经过IK操作来进行实时计算（Rogdoll除外），所以在模型导入时，不要将IK结点一起导入。
2、 静态实体不要附加Animation Component在静态实体上附加Animation部件虽然对结果没有影响，但却会增加一定的CPU开销来调用这一组件，所以尽量去掉该组件。网格顶点数小于500UV值范围尽量不要超过（0, 1）区间尽量保证UV值不越界，这对于将来的纹理拼合优化很有帮助。
3、 地形地形的分辨率大小长宽均尽量小于257。这是因为地形太大，会造成大量顶点数据，给你的内存带宽造成一定的影响，在目前的ios设备中，内存带宽是非常有限的，需要尽量节省。同时，如果用Unity自带的地形，一定也要使用Occlusion Culling，因为Unity的刷地形工具虽然方便，但却是framekiller，刷过之后，你会发现drawcall增加的非常多。混合纹理数量不要超过4。地形的混合操作是很耗时的，应该尽量避免。能合并的纹理尽量合并。
4、 纹理纹理格式建议png或tga。不用转成ios硬件支持的PVRTC格式，因为Unity在发布时会帮你自动转的。纹理尺寸长宽小于1024。同时应该尽可能地小，够用就好，以保证纹理对内存带宽的影响达到最小。支持Mipmap建议生成Mipmap。虽然这种做法会增加一些应用程序的大小，但在游戏运行时，系统会根据需求应用Mipmap来渲染，从而减少内存带宽。检查Alpha值如果纹理的alpha通道均为1，则用RGB的24位纹理来代替RGBA的32位纹理。（据说Unity内部会进行自动检测）
5、 光源光源“Important”个数建议1个，一般为方向光。“Important”个数应该越小越少。个数越多，drawcall越多。Pixel Light数目1-2个。
6、 粒子特效屏幕上的最大粒子数建议小于200个粒子。每个粒子发射器发射的最大粒子数建议不超过50个。粒子大小如果可以的话，粒子的size应该尽可能地小。因为Unity的粒子系统的shader无论是alpha test还是alpha blending都是一笔不小的开销。同时，对于非常小的粒子，建议粒子纹理去掉alpha通道。尽量不要开启粒子的碰撞功能。非常耗时。
7、 音频游戏中播放时间较长的音乐（如背景音乐）使用.ogg或.mp3的压缩格式。较短音乐（如枪声）使用.wav和.aif的未压缩音频格式。
8、 相机裁剪平面将远平面设置成合适的距离。远平面过大会将一些不必要的物体加入渲染，降低效率。根据不同的物体设置不同的远裁剪平面Unity提供了可以根据不同的layer来设置不同的view distance，所以我们可以实现将物体进行分层，大物体层设置的可视距离大些，而小物体层可以设置地小些，另外，一些开销比较大的实体（如粒子系统）可以设置得更小些等等。
9、 碰撞尽量不用MeshCollider如果可以的话，尽量不用MeshCollider，以节省不必要的开销。如果不能避免的话，尽量用减少Mesh的面片数，或用较少面片的代理体来代替。
10、 其他Drawcall尽可能地减少Drawcall的数量。iOS设备上建议不超过100。
减少的方法主要有如下几种：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降了，渲染速度也变慢了”的原因。非运动物体尽量打上Static标签Unity在运行时会对static物体进行自动优化处理，所以应该尽可能将非运行实体勾上static标签。场景中尽可能地使用prefab尽可能地使用prefab的实例化物体，以降低内存带宽的负担。检查实体的PrefabType，尽量将其变成PrefabInstance，而不是ModelPrefabInstance。