U3d常规性能优化技巧

优化的常规技巧 
n 剖析你的游戏。 不要花费时间来优化那些晦涩的代码或者缩减图形文件的大小，除非这是你游戏的瓶颈。第一次剖析你的游戏将会使你发现你游戏的瓶颈。Apple's Shark是一个很好的用来剖析基于OpenGL的程序的工具。 
n 再次剖析你的游戏。 优化之后不要忘记再剖析一次你的游戏，这样可以检查你所做的优化是否达到了预期的效果。当然，这样做也可能会使你发现更多的瓶颈。 
n 流程第一、性能第二。 花费时间来使你游戏的创建尽可能地流畅。尽可能快地修正游戏中的错误将会使你后期更容易优化你的游戏。 
n 在Scene View中测试场景。 这样做将会使你清楚了解这个场景中的物体或者附加在物体上的脚本是否降低了游戏性能。如果Scene View反应迟钝，那么有可能是图形方面的原因，如果Scene View反应不迟钝，那么瓶颈可能出在脚本或者物理系统上。 
n 禁用指定游戏物体。 在play模式下，尝试禁用并启用游戏物体来排查出游戏慢的原因。 

网格 
n 如果可能的话，把相邻的物体（网格）合并为一个只有一个材质的物体（网格）。 比如，你的游戏中包含一个桌子，上面有一堆东西，你完全可以在3D程序中将它们合并在一起（这可能也需要你将这些物体的纹理合并为一个大的纹理集）。减少需要渲染的物体的数量可以极大地提高游戏性能。 
n 不要有不必要的网格。 如果你的游戏场景中有一个人物，那么他应该是一个网格。如果你有一个船，那么它也应该只是一个网格。 
n 每一个网格只用一种材质。 
n 使用极少的面数的网格（比如500个多边形以下）。 
n 最好把你人物的三角面数量控制在1500-2000个之间。 这个数量可以说是游戏质量和性能之间一个均衡值。如果你的模型有四边形，那么在导入模型的时候，引擎将会把每个四边形变为两个三角形。 

光照 
n 像素光。 像素光可以让你的游戏看起来效果很牛逼，但是不要使用过多的像素光。在你的游戏中可以使用质量管理器来调节像素光的数量来取得一个性能和质量的均衡点。 
n 性能占用顺序：聚光灯>点光源>平行光。 一个好的点亮场景的方法就是先得到你想要的效果，然后看看哪些光更重要；在保持光效的前提下看看哪些光可以去掉。 
n 点光源和聚光灯只影响它们范围内的网格。 如果一个网格处于点光源或者聚光灯的照射范围之外，并且光源的attenuate开关是打开的，那么这个网格将不会被光源所影响，这样就可以节省性能开销。这样做理论上来讲可以使用很多小的点光源而且依然能有一个好的性能，因为这些光源只影响一小部分物体。一个网格在有8个以上光源影响的时候，只响应前8个最亮的光源。 

贴图 
n 在外观不变的前提下，贴图大小越小越好。 如果你的显卡的显存不够大的话，你游戏中的贴图将会被转存到系统内存中，在显卡调用它们的时候再传到显卡中。对于比较新的电脑来说，内存和显卡之间有足够的带宽来达到一个很好的性能；如果你很无耻地用了巨多的大图片的话，在低显存的电脑上运行你的游戏的时候，你的游戏必然会挂掉。倒是没有必要在图形编辑软件中调整贴图的大小。你可以在unity导入贴图的时候进行调整。 
n 不要使用低质量的图片。 在小播放界面的游戏中使用低质量的jpeg图片或者低色彩的png图片亦或是gif图片没什么问题。在发布游戏的时候，引擎会自动压缩这些图片，多重压缩和解压将会降低图片的质量，所以最好保持贴图文件的分辨率为原始分辨率。这样就会减少多重压缩和解压所导致的图片失真现象。 

音频 
n  使用.ogg 格式的压缩音频文件。   所有其他的音频格式文件在发布时将会被转储为未压缩音频文件。 
n  对于小音效使用未压缩音频文件。  Unity 在运行过程中会解压所有的 ogg 文件。它会把经常播放的音效转储为 WAV 或者 aiff 格式的文件，这样就可以不用 cpu 总是解压这些文件了。比如快速的枪声，脚步声和其他一些连续播放又很短小的音效。 

物理 
n  每一个刚体都需要大量运算，所以刚体越少越好。   当角速度和移动速度降低到某个临界值的时候，刚体将会进入休眠状态。当刚体进入休眠状态时，他们需要的运算量将会大量减少，但是会保留很少的一部分运算来随时应对外部的作用力或者物体的碰撞。 
n  多重碰撞相比一个接一个地碰撞将会花费更多的运算。   比如一个球去碰一堆球所需要的计算量会远远大于去一个一个地碰这些球所需要的计算量。

Shaders 
n 多重效果的shader就比看起来样式很单一的shader要更耗费资源。 同样在一个拥有贴图和光反射的物体上，使用VertexLit Diffuse shader无疑是最省资源的。 

脚本 
n  选择适当的算法。   选择一个正确的算法将会更容易进行优化。最好的算法不一定就是算法复杂度最低的算法。 
n  尽量不要使用 FixedUpdate()函数 。   这种函数在每一个物体的每一个脚本中每秒调用 50-100 次。如果可以的话尽量把这个函数里面的东西放在 Update() 函数中执行。 
n  如果可能的话，在脚本无用的时候禁用它。   比如有一个敌人在数千米开外的位置，完全可以禁用它的 AI 脚本，直到需要的时候再启用这个脚本。启用和禁用物体的最好方法就是使用 gameObject.SetActiveRecursively(false) 函数，并且把物体的球碰撞和盒碰撞都置为 trigger 。 
n  如果不需要Update 函数的时候就删掉它。   在创建一个新脚本的时候，系统会自动加入一个空的 Update 函数，如果你不使用它的话就把它删掉。 
n  适当的时候使用物体引用。   如果调用一个物体需要走一个很弯的逻辑，比如 someGameObject.transform.gameObject.rigidbody.transform.gameObject.rigidbody.transform ，这样就不如直接在脚本中声明一个变量，把要调用的物体直接赋给这个变量。 
n  尽量使用协同函数。   协同函数开销很小，相比于一直在进行不必要调用的 Update 函数来说更好用。举例来说，如果你有一个控制灯光渐明渐暗的脚本，你就完全可以使用协同函数来替代 Update 函数。这样的话，在大多数时间灯光不变化的时候，系统的开销会很小。如果这一过程是在 Update 函数中执行的话， Update 函数会一直检测是否需要执行渐变。 
n  尽量不要使用搜索物体的函数。   比如 GameObject.FindByTag() 和  GameObject.GetComponent() ，搜索组件的函数也一样尽量少用。搜索就等于遍历，搜索一次物体就要把所有物体都遍历一遍，这个开销我不说大家也应该都明白。尤其要注意，不要在 Update() 和 FixedUpdate() 中使用搜索函数，如果需要的话，最好在 Start 函数中使用变量来获取一次，之后调用就直接用这个变量。 
n  尽量不要使用SendMessage() 函数或者类似的函数。  SendMessage() 函数的执行速度至少比直接调用一个 function 慢 100 倍，随着脚本和函数的增多，这个速度会更慢，所以如果能直接调用函数的话就直接调用。 
n  关于 JavaScript（ Boo） 中的动态类型。   在使用 JavaScript 时，声明变量的尽量明确指定它的类型。