性能分析

Unity分析器使用的端口如下：

	MulticastPort : 54998						组播端口：54998
	ListenPorts : 55000 - 55511					监听端口：55000 - 55511
	Multicast(unittests) : 55512 - 56023		多路广播（单元测试）：55512 - 56023

First Steps：第一步

Unity依靠CPU（对于它的SIMD部分已被巨大的优化了，就像x86上的SSE或是ARM上的NEON一样）来进行蒙皮、批处理、物理模拟、用户脚本、粒子等工作

GPU则被用于shaders，drawcalls和图像效果。

性能分析方法：

（1）Pareto analysis 帕累托分析法

很大一部分问题百分之80是由于一下不分关键原因百分之20引起的。

use the editor profiler to get the most problematic function calls and optimize them first。

使用编辑器分析器来得到最有问题的函数调用，并且在第一时间优化它们.

Make sure the scripts run only when necessary.

确保脚本只在必要时才会运行.

使用OnBecameVisible/OnBecameInvisible 来禁用非活跃对象。

如果一些脚本不需要在每一帧都运行，就使用协同函数。

IEnumerator Start（）

{

      while（true）

      {

                 yield returnnewWaitForSeconds（0.2f）;//每0.2秒调用一次

      }

}

CPU Profiling（CPU分析）

Profile user code 分析用户代码

不是所有的用户代码都被显示在分析器中。但是你可以使用 Profiler.BeginSample 和 Profiler.EndSample 来使得需要的用户代码出现在分析器中。

GPU Profiling （GPU分析）

Unity编辑器分析器目前还不可以显示GPU数据

Memory 内存

Mono memory（mono内存）

Mono内存为Unity对象（游戏对象，资源，组件等等）控制脚本对象和封装器。当资源分配和可用内存不相配或者在调用 System.GC.Collect()时，清理器就会清理空间。

Unity memory（unity内存）

Unity内存控制资源数据（贴图，网格，音频，动画等等），游戏对象，引擎内部（渲染，粒子系统，物理等等）。使用Profiler.usedHeapSize来得到已使用的所有Unity内存的数量。

Garbage collector 垃圾回收器

1.）当系统无法把新的数据分配到已分配的堆块中，就会开始工作

2.）不要在移动设备上使用OnGUI。1.它在每一帧时都会被调用若干次。2.它完全重绘视图。3.它会创建大量的内存分配调用，并需要垃圾回收器来清理。

3.）过快地创建/移除过多的对象.1.这可能会导致碎片。2.使用编辑器分析器来跟踪内存活动。3.内置分析器可以被用于跟踪mono内存活动。

4.）当它可以有一个间隔时，你可以使用System.GC.Collect() 这个.Net函数。

New memory allocations 新的内存分配

·Allocation hiccups分配间隔.1.使用预分配列表，可重用类实例来实现自己的内存管理计划。2.不要在每一帧时执行大量的分配，使用缓存、预分配来代替。

·Problems with fragmentation 碎片的问题1.预分配内存池2.保存一个非活跃游戏对象列表，然后重用他们而不是实例化再销毁他们.

·out of mono memory 耗尽mono内存

·对于局部数据，使用结构体而不是类。类被存储在堆：而结构体被存储在栈.

Out of memory crashes 内存不足崩溃

At some points a game may crash with "out of memory" though it in theory it should fit in fine. When this happens compare your normal game memory footprint and the allocated memory size when the crash happens. If the numbers are not similar, then there is a memory spike. This might be due to:

在某些时刻，一个游戏可能由于“内存不足”而崩溃。尽管理论上它最后应当是合适的。当这个问题发生而引发崩溃时，对比你的正规的游戏内存轨迹和已分配内存大小。如果得到的数字不是类似的，那么这就发生了一个内存峰值。这可能是由于：

• Two big scenes being loaded at the same time - use an empty scene between two bigger ones to fix this. 
  两个大场景被同时加载——为了解决它，在两个更大的场景中间使用一个空的场景。
• Additive scene loading - remove unused parts to maintain the memory size. 
  附加的场景加载——移除没有用到的部分来维护内存大小。
• Huge asset bundles loaded to the memory 
  巨大的资源包被加载到内存
• Loading via WWW or instantiating (a huge amount of) big objects like:
  通过WWW加载或是实例化（大量的实例化）庞大的对象，例如：
  • Textures without proper compression (a no go for mobiles). 
    没有合适压缩的贴图（对于移动设备是无效的）。
  • Textures having Get/Set pixels enabled. This requires an uncompressed copy of the texture in memory. 
    被启用了 获取/设置像素 的贴图。这需要在内存中创建一个贴图的未压缩的复制品。
  • Textures loaded from JPEG/PNGs at runtime are essentially uncompressed. 
    动态地从JPEG/PNGs加载的贴图没有基本上被压缩。
  • Big mp3 files marked as decompress on loading. 
    在加载时，巨大的mp3文件被标记为解压缩。
• Keeping unused assets in weird caches like static monobehavior fields, which are not cleared when changing scenes. 
  在怪异的缓存中（像静态monobehavior区域，当变换场景时它不会被清理）保留了未使用的资源。