Profiler性能分析

性能分析工具可以给我们提供游戏性能表现的详细信息。如果我们的游戏存在性能问题，如低帧率或者高内存占用，性能分析工具可以帮助我们发现问题的起因，并协助我们解决问题。

Profiler工具是Unity内置的强大的性能分析工具，本文介绍如何使用它。当我们阅读完本文，并且熟悉Profiler的界面和功能时，我们可以继续学习怎么使用它对不同类型的性能问题进行诊断。

Profiler可以给我们提供，关于我们的游戏的不同部分是怎样运行的深入的信息。

使用Profiler我们可以学习游戏性能的不同方面，例如我们的游戏如何使用内存，不同的任务使用了多少cpu时间，物理运算执行的有多频繁。最重要的是，我们可以利用这些数据找到引起性能问题的原因，并且测量我们的解决方案的有效性。

Profiler布局

在我们使用Profiler收集游戏数据之前，先打开它熟悉下界面布局。

-从菜单Window > Profiler打开

注意，只有在它开始录制时才会显示性能信息，当我们第一次打开时，一些部分是空的。

当开始录制时，窗口上部的每个profiler会随着时间显示数据。性能是随着时间变化的，所以随着时间变化的信息是比仅仅一帧的信息有用的多的。有些性能问题是持续性的，有些问题是仅仅在一帧中出现的，还有一些性能问题是随着时间逐渐显现的。

Profiler的下半部显示我们选择的当前profiler当前帧的详细信息。

这里显示的数据依赖于我们当前选择的profiler。例如，当选中内存profiler时，这个区域显示如游戏资产使用的内存和总共内存占用等。如果选中渲染profiler，这里会显示被渲染的对象数量或者渲染操作执行次数等数据。

这些profiler会提供很多详细信息，但是我们并不总是需要使用这些所有的profiler。事实上，我们通常在分析游戏性能时只是观察一个或者两个profiler。例如，当我们的游戏运行的比较慢时，我们可能一开始先查看cpu usage profiler。

cpu usage profiler给我们一个总览，可以观察到我们游戏的哪个部分占用了最多的cpu时间。然后我们可以查看那个部分相关的profiler。例如我们发现物理运算函数占用了很长时间，那么我们就需要使用物理profiler去获取更多的详细信息。

我们可以关闭一些我们不关心的profiler，通过点击x按钮就可以关闭。

通过点击左上角的Add Profiler按钮，我们可以添加profiler。

我们可以随时添加或者删除profiler，添加删除操作不会清除他们的数据，仅仅是显示或者隐藏他们。

控制

Profiler窗口的顶部包含一些控制按钮。

我们可以使用控制按钮开始或停止分析和浏览收集的数据。

一个典型的使用控制按钮的过程如下，开始分析我们的游戏，当游戏出现性能问题时，停止分析，然后通过时间线控制，逐帧的找到显示出性能问题的帧，这帧的详细信息会在下半部窗口显示。

在Unity Editor中进行分析

在unity editor中进行录制分析的步骤如下：

-在unity中打开游戏工程

-菜单中打开profiler Window > Profiler

-确保Profiler窗口顶部的Record按钮为选中状态

-在Play Mode中运行游戏

此时Profiler会随着游戏中的互动实时的显示分析数据。

在development build中进行分析 在目标平台上进行分析，需要运行development build并连接Profiler。不同的目标平台有不同的具体做法。

Windows, OSX, Linux and WebGL 步骤如下：

-在unity中打开想要分析的项目

-菜单中打开profiler Window > Profiler

-确保Profiler窗口顶部的Record按钮为选中状态

-打开build settings（File > Build Settings）

-勾选Development Build

-勾选Autoconnect Profiler

-点击Build and Run

此时Profiler会随着游戏中的互动实时的显示分析数据。

iOS or Android 在iOS或者Android中连接Profiler有些复杂，因为我们需要把游戏安装到设备上，并且把设备连接到Unity Editor。

详细的操作步骤，请参考on this page of the Unity Manual.

CPU

A. WaitForTargetFPS: Vsync(垂直同步)功能所，即显示当前帧的CPU等待时间 B. Overhead： Profiler总体时间-所有单项的记录时间总和。用于记录尚不明确的时间消耗，以帮助进一步完善Profiler的统计。 C. Physics.Simulate： 当前帧物理模拟的CPU占用时间。 D. Camera.Render： 相机渲染准备工作的CPU占用量 E. RenderTexture.SetActive： 设置RenderTexture操作. 底层实现： 1.比对当前帧与前一帧的ColorSurface和DepthSurface. 2.如果这两个Buffer一致则不生成新的RT，否则则生成新的RT，并设置与之相对应的Viewport和空间转换矩阵. F. Monobehaviour.OnMouse_ ：用于检测鼠标的输入消息接收和反馈，主要包括：SendMouseEvents和DoSendMouseEvents。（只要Edtor开起来，这个就会存在） G. HandleUtility.SetViewInfo：仅用于Editor中，作用是将GUI和Editor中的显示看起来与发布版本的显示一致。 H. GUI.Repaint：GUI的重绘(说明在有使用原生的OnGUI) I. Event.Internal_MakeMasterEventCurrent：负责GUI的消息传送 J. Cleanup Unused Cached Data：清空无用的缓存数据，主要包括RenderBuffer的垃圾回收和TextRendering的垃圾回收。 1.RenderTexture.GarbageCollectTemporary:存在于RenderBuffer的垃圾回收中，清除临时的FreeTexture. 2.TextRendering.Cleanup:TextMesh的垃圾回收操作 K. Application.Integrate Assets in Background：遍历预加载的线程队列并完成加载，同时，完成纹理的加载、Substance的Update等. L. Application.LoadLevelAsync Integrate：加载场景的CPU占用，通常如果此项时间长的话70%的可能是Texture过长导致. M. UnloadScene：卸载场景中的GameObjects、Component和GameManager，一般用在切换场景时. N. CollectGameObjectObjects：执行上面M项的同时，会将场景中的GameObject和Component聚集到一个Array中.然后执行下面的Destroy. O. Destroy：删除GameObject和Component的CPU占用. P. AssetBundle.LoadAsync Integrate：多线程加载AwakeQueue中的内容，即多线程执行资源的AwakeFromLoad函数. Q. Loading.AwakeFromLoad：在资源被加载后调用，对每种资源进行与其对应用处理.

GPU Usage

A. Device.Present: device.PresentFrame的耗时显示，该选项出现在发布版本中. B. Graphics.PresentAndSync：GPU上的显示和垂直同步耗时.该选项出现在发布版本中. C. Mesh.DrawVBO：GPU中关于Mesh的Vertex Buffer Object的渲染耗时. D. Shader.Parse：资源加入后引擎对Shader的解析过程. E. Shader.CreateGPUProgram：根据当前设备支持的图形库来建立GPU工程.

Memory Profiler

A. Used Total: 当前帧的Unity内存、Mono内存、GfxDriver内存、Profiler内存的总和. B. Reserved Total: 系统在当前帧的申请内存. C. Total System Memory Usage: 当前帧的虚拟内存使用量.（通常是我们当前使用内存的1.5~3倍) D. GameObjects in Scene: 当前帧场景中的GameObject数量. E. Total Objects in Scene: 当前帧场景中的Object数量(除GameObject外，还有Component等). F. Total Object Count: Object数据 + Asset数量.

Detail Memory Profiler

A. Assets: Texture2d:记录当前帧内存中所使用的纹理资源情况，包括各种GameObject的纹理、天空盒纹理以及场景中所用的Lightmap资源. B. Scene Memory: 记录当前场景中各个方面的内存占用情况，包括GameObject、所用资源、各种组件以及GameManager等（天般情况通过AssetBundle加载的不会显示在这里). C. Other:ManagedHeap.UseSize:代码在运行时造成的堆内存分配，表示上次GC到目前为止所分配的堆内存量. SerializedFile(3): WebStream:这个是由WWW来进行加载的内存占用. System.ExecutableAndDlls:不同平台和不同硬件得到的值会不一样。

优化重点

A. CPU-GC Allow: 关注原则： 1.检测任何一次性内存分配大于2KB的选项 2.检测每帧都具有20B以上内存分配的选项. B. Time ms: 记录游戏运行时每帧CPU占用（特别注意占用5ms以上的）. C. Memory Profiler-Other: 1.ManagedHeap.UsedSize: 移动游戏建议不要超过20MB. 2.SerializedFile: 通过异步加载(LoadFromCache、WWW等)的时候留下的序列化文件,可监视是否被卸载. 3.WebStream: 通过异步WWW下载的资源文件在内存中的解压版本,比SerializedFile大几倍或几十倍,重点监视. D. Memory Profiler-Assets: 1.Texture2D: 重点检查是否有重复资源和超大Memory是否需要压缩等. 2.AnimationClip: 重点检查是否有重复资源. 3.Mesh： 重点检查是否有重复资源.

项目中可能遇到的问题

A. Device.Present: 1.GPU的presentdevice确实非常耗时，一般出现在使用了非常复杂的shader. 2.GPU运行的非常快，而由于Vsync的原因，使得它需要等待较长的时间. 3.同样是Vsync的原因，但其他线程非常耗时，所以导致该等待时间很长，比如：过量AssetBundle加载时容易出现该问题. 4.Shader.CreateGPUProgram:Shader在runtime阶段（非预加载）会出现卡顿(华为K3V2芯片). B. StackTraceUtility.PostprocessStacktrace()和StackTraceUtility.ExtractStackTrace(): 1.一般是由Debug.Log或类似API造成. 2.游戏发布后需将Debug API进行屏蔽.

C. Overhead: 1.一般情况为Vsync所致. 2.通常出现在Android设备上. D. GC.Collect: 原因: 1.代码分配内存过量(恶性的) 2.一定时间间隔由系统调用(良性的). 占用时间：1.与现有Garbage size相关 2.与剩余内存使用颗粒相关（比如场景物件过多，利用率低的情况下，GC释放后需要做内存重排) E. GarbageCollectAssetsProfile: 1.引擎在执行UnloadUnusedAssets操作(该操作是比较耗时的,建议在切场景的时候进行). 2.尽可能地避免使用Unity内建GUI，避免GUI.Repaint过渡GC Allow. 3.if(other.tag == GearParent.MogoPlayerTag)改为other.CompareTag(GearParent.MogoPlayerTag).因为other.tag为产生180B的GC Allow. F. 少用foreach，因为每次foreach为产生一个enumerator(约16B的内存分配)，尽量改为for. G. Lambda表达式，使用不当会产生内存泄漏. H. 尽量少用LINQ： 1.部分功能无法在某些平台使用. 2.会分配大量GC Allow. I. 控制StartCoroutine的次数： 1.开启一个Coroutine(协程)，至少分配37B的内存. 2.Coroutine类的实例 — 21B. 3.Enumerator — 16B. J. 使用StringBuilder替代字符串直接连接. K. 缓存组件: 1.每次GetComponent均会分配一定的GC Allow. 2.每次Object.name都会分配39B的堆内存.