原文链接：https://unity3d.com/cn/learn/tutorials/temas/best-practices/unity-ui-profiling-tools?playlist=30089
UGUI性能分析工具
有很多用于分析UGUI性能的工具。一些关键的工具是：
1.Unity Profiler
2.Unity Frame Debugger
3.XCode的Instrument或者Intel的VTune
4.XCode的Frame Debugger或者Intel GPA
外部工具提供了对CPU毫秒级（或更高精度的）性能分析方法，同时对shader和drawcall详细分析。对上述工具设置和使用的说明超出了本指南的范围。请注意，XCode Frame Debugger和Instrument仅适用于Apple平台的IL2CPP版本，因此目前只能用于iOS平台的性能分析。
Unity Profiler
Unity Profiler的主要用途是执行性能比较分析：当Unity Profiler运行的时候进行enabling和disabling的操作，它可以迅速的缩小定位到性能问题最大的UI层级。
要分析这个，请查看profiler输出结果中的“Canvas.BuildBatch”和“Canvas.SendWillRenderCanvases”。
如上文所述，Canvas.BuildBatch是执行Canvas的Batch build过程的底层代码计算量。
Canvas.SendWillRenderCanvases包含了C#脚本对Canvas组件的willRenderCanvases事件的订阅的调用。UGUI的CanvasUpdateRegistry类接收这个事件并且通过它来执行前文所描述的rebuild过程。预计所有被标dirty的UI组件都会在这个时候更新他们的Canvas Renderer。
注意：为了更容易地看到UI性能的差异，通常建议禁用除了Rendering和Scripts以外所有trace category。这可以通过点击CPU Usage profiler左侧的名叫trace category旁边的彩色方块来完成。
还要注意，category可以在CPU profiler中重新排列，可以点击或者拖拽category向上或者向下来对他们进行重新排列。
Unity Frame Debugger
Unity Frame Debugger是一个减少UGUI的draw call的实用工具。这个内置的工具可以通过Unity Editor中的Window菜单来访问。当它运行的时候，它将显示包括UGUI在内的所有Unity产生的draw call。
特别要注意的是，Unity Frame Debugger在Unity Editor界面就可以更新游戏视口产生的draw call信息，因此可以用来尝试不同的UI配置而无需进入游戏模式。
UGUI的drawcall产生的位置取决于Canvas组件上被设置的渲染模式：
1.Screen Space – Overlay将出现在Canvas.RenderOverlays组中。
2.Screen Space – Camera将出现在Render.TransparentGeometry子项，所选渲染相机的Camera.Render组中。
3.World Space将出现在Render.TransparentGeometry子项，每个可以看见Canvas的World Space的摄像机中。
如果UI的shader没有被自定义的shader替换的话，那么所有UI都可以被 “Shader: UI/Default”识别，列出在哪个组和drawcall的细节。在下图中请看高亮红框标注的地方。（图片见原网页）
在调整UI的时候观察Unity Frame Debugger所显示的信息，这就相对比较简单的使Canvas中的UI元素最优的合成batch。最常见的与设计相关的打断批次的原因是UI元素间不小心造成的重叠。
所有的UGUI组件将它们的几何体生成成一系列的 quad。然而，很多sprite和text只占用用于显示它们的 quad的一小部分，留下了大量的剩余空间。这样的结果就是，UI开发者无意中使多个不同的 quad互相覆盖，它们的texture来自不同的material，不能合成batch。
由于UGUI的操作完全在透明队列中，任何有不能合batch的quad在它上边的quad必须在不能合batch的quad之前绘制，因此它不能与放在不能合batch的quad上的quad合batch。（翻译这段我尽力了，但是估计还是不清楚。我讲一下大意：就是两个能合batch的quad中间夹了一个不能合batch的quad，造成这两个quad也不能合batch了）
考虑一个情景，有三个quadA、B、C。假设这三个quad彼此覆盖，并且A和C使用了相同的Material，B使用了单独的Material。B不能和A、C合成batch。
如果在层级结构中从上到下的是A、B、C，那么A、C也不能合batch，因为B必须绘制在A的上面，C的下面。然而，如果B被放在可被合batch的quad前面或者后面，那么可以被合batch的quad就能构成batch。B只需要在batch的quad之前或者之后绘制，而不会介入其中。
关于这个问题更深入的探讨，请看Canvas章节的Child order部分。
Instruments & VTune
XCode的Instruments和Intel的VTune各自可以非常深入的分析UGUI的rebuild和Canvas的batch计算在Apple设备和Intel CPU上的性能。方法名称几乎和我们之前介绍过的Unity Profiler的标签完全相同。它们是：
Canvas::SendWillRenderCanvases是一个C++父类调用C#中的Canvas.SendWillRenderCanvases方法，并控制 Unity Profiler中该行显示。它包含了用于进行rebuild过程的代码，这已经在上一章节详细介绍了。
Canvas::UpdateBatches几乎和Canvas.BuildBatch完全相同，但是增加了Unity Profiler页面并不包括的代码引用。它运行上文描述的Canvas的batch建立的实际过程。
当通过IL2CPP构建一个Unity APP时，这些工具可以被用于更深入的查看C#中Canvas::SendWillRenderCanvases的编译。（注意：编译的方法的名字是近似的。）
IndexedSet_Sort和CanvasUpdateRegistry_SortLayoutList是用于排序显示在标为dirty的Layout组件被重新计算之前的一个列表。如上文所述，这包括了计算每个Layout组件的父transform数量。
ClipperRegistry.Cull调用所有IClipRegion接口注册的实现者。内置的实现者包括使用IClipRegion接口的RectMask2D组件。当ClipperRegistry.Cull被调用时，RectMask2D组件将遍历在它层级下的所有要被裁剪的UI元素，更新他们的剔除信息。
所有可嵌套元素，并要求它们更新其剔除信息。
Graphic_Rebuild包含所有要显示的Image，Text或其他Graphic派生的组件所需要的网格的实际计算性能开销。在这之下有其他一些方法，如Graphic_UpdateGeometry，最值得注意的是Text_OnPopulateMesh。
-当Best Fit勾选时，Text_OnPopulateMesh通常是一个热点。这将在本指南后面详细讨论。
-网格修饰符，比如Shadow_ModifyMesh和Outline_ModifyMesh也在这里运行。通过这些方法可以看到shadow, outline和其他特殊效果组件的计算性能开销。
Xcode Frame Debugger和Intel GPA
底层的Frame Debugger对监测UI不同独立部分的batch性能开销和UI过度绘制开销非常重要。在后面章节我们将详细的对UI过度绘制进行讨论。
Xcode Frame Debugger的使用
为了测试一个给定的UI是否过度榨取GPU资源，可以使用Xcode内置的GPU诊断工具。首先将项目配置为使用Metal或OpenGLES3，然后进行构建并打开生成的Xcode项目工程。如果Unity在OpenGLES 2下运行，则Xcode不能对Unity进行分析，因此这些技术不能用于较旧的设备。
注意：在某些版本的Xcode中，为了使图形分析器工作，有必要在Build Scheme中选择适当的Graphics API。为此，请转到Xcode中的Product菜单，展开Scheme菜单项，然后选择Edit Scheme ....选择Run target并转到Options页面。更改GPU Frame Capture选项来使API适配您的工程。假设Unity工程设置了自动选择图形API，则大多数新一代的iPad将默认选择Metal。如果有疑问，请启动项目并查看Xcode中的调试日志，前面的几行应该会指出哪个渲染路径（Metal，GLES3或GLES2）正在被初始化。
注意：上述调整在Xcode 7.4中应该不是必需的，但在Xcode 7.3.1和更旧的版本中仍然偶尔会被发现是必须的。
在iOS设备上构建并运行项目。GPU profiler显示在Xcode的Navigator边栏中，点击FPS条目。（图请参见原网页）
GPU分析器中第一个重要的是屏幕中的三个条目：“Tiler”、“Renderer”、“Device”。这些表示：
“Tiler”是对GPU生成几何体（包括在顶点着色器中的花费时间）过程中压力的衡量。
——一般来讲，“Tiler”值高表明顶点着色器计算过慢或者是绘制的顶点过多。
“Renderer”是对GPU的像素流水线压力的衡量。
——一般来讲，“Renderer”值高表明应用程序超过了GPU的最大填充率，或是片段着色器效率低下。
“Device” 是GPU使用的综合衡量标准，包括“Tiler”和“Renderer”的性能分析。它通常可以被忽略，因为它大体上跟踪监测“Tiler”和“Renderer”的较高者。
有关Xcode GPU Profiler的更多信息，请参阅此文档(链接见原网页)。
Xcode’s Frame Debugger可以通过点击隐藏在GPU Profiler底部的小“相机”图标来打开。在下面的屏幕截图中，通过箭头和红色框突出显示。（截图见原网页）
暂停一下之后，Frame Debugger的摘要视图就会出现，如下所示（截图见原网页）：
在使用默认UI着色器时，假设默认UI着色器没有被自定义着色器替换，那么由UGUI系统生成的渲染几何图形的开销将显示在“UI / Default”着色器通道下。在上面的截图中可以看到这个渲染管线的默认的UI着色器是“UI / Default”。
UGUI只产生quad，所以顶点着色器不太可能给GPU Tiler流水线产生压力。出现在这个着色器中的任何问题都应归结于填充率问题。
分析分析器结果
在收集分析数据之后，可以得出几个结论：
如果Canvas.BuildBatch或Canvas :: UpdateBatches占用了过多的CPU时间，则可能的问题是单个Canvas上的Canvas Renderer组件数量过多。请参阅“Canvas”一章的“Splitting Canvases”章节。
如果GPU过度的时间花费在绘制UI上，并且frame debugger表明片段着色器流水线是瓶颈，那么应该是UI的像素填充率超过了GPU的能力，最可能的原因是UI的过渡绘制。请参考Fill-rate, Canvases and input章节的Remediating fill-rate issues部分。
如果Graphic的rebuild占用了过多的CPU，如在Canvas.SendWillRenderCanvases或者Canvas::SendWillRenderCanvases中看到了大量的CPU时间占用，那么就需要进行深层分析，应该与Graphic的rebuil过程中的一些部分有关。
如果是大量的WillRenderCanvas花费在IndexedSet_Sort或是CanvasUpdateRegistry_SortLayoutList上，时间花费在对dirty的layout组件列表进行排序，那么就要考虑减少Canvas中的Layout组件数量。请在Replacing layouts with RectTransforms和Splitting Canvases部分中也许会找到补救措施。
如果过多的时间花在Text_OnPopulateMesh上，那么Text网格的生成就是罪魁祸首。请参阅Best Fit和 Disabling Canvas Renderers部分，也许会找到补救措施。并考虑Splitting Canvases中的建议，如果正在重建的大部分文本实际上并未更改其基础字符串数据，text大量rebuild实际上并没有改变其基础的字符串数据。
如果时间花在内置的Shadow_ModifyMesh或Outline_ModifyMesh（或任何其他使用的ModifyMesh），则问题在于花费在计算修饰性网格过多的时间。考虑删除这些组件，并通过静态图像实现其视觉效果。
如果Canvas.SendWillRenderCanvas中没有特定的热点，或者它看起来每帧都在运行，那么问题可能是动态元素与静态元素混合在一起，致使整个Canvas过于频繁地重建。参见Splitting Canvases部分。
