Unity Stats窗口（统计数据窗口）

通过Stats窗口可以初步查看游戏运行时，当前一帧的各项性能。

Stats是英文单词Statistics的缩写，意思是“统计数据”。

打开方法：Game窗口右上角，找到Stats，点击它。

    Audio表示音频的数据

    Level表示声音强度，单位是分贝，也就是dB。声音太大或太小都会影响玩家体验。
    应将这项数据控制在一个合适的范围内。

    DSP load表示数字信号处理器的负载。播放的声音越多、声音的采样率越高、声音效果越复杂，本变量的数值都会越大。
    应尽量避免这项数据过大。

    Clipping表示音频的裁剪情况。当音频信号超过设备支持的最大范围时，该音频信号会被裁剪。裁剪之后，该音频会出现一定程度失真的现象。
    应尽量避免这项数据过大。

    Stream load表示音频流的负载情况。音频的流式加载是指以持续的方式从音频源获取音频数据，而不是一次性加载全部数据。流式加载的主要优势是可以实时地处理和播放音频，无需等待全部数据加载完成。
    应尽量避免这项数据过大。

    Graphics表示图像的数据

    FPS表示帧率，也就是1秒内播放多少帧。可以用来判断游戏运行得是否流畅。
    例如209.5FPS（4.8ms）表示平均每秒播放209.5张画面，平均每4.8毫秒播放一张画面。
    游戏画面、视频画面都是由一张张静态的画面连续播放而成的，1帧就是一张静态的画面。60FPS是很流畅的，45FPS比较流畅，30FPS会明显感到卡顿。
    应将这项数据控制在一个合适的范围内。

    CPU的指标表示CPU处理一帧的时间。
    例如CPU:main 4.6ms render thread 0.5ms表示Unity的主线程处理这一帧所花费的时间是4.6毫秒，主线程主要负责游戏逻辑的更新，例如检测用户的输入、更新游戏对象的位置、碰撞检测等。在渲染线程处理这一帧所花费的时间是0.5毫秒，渲染线程负责显示游戏画面。
    应尽量避免这项数据过大。

    Batches表示处理的绘制调用（Draw Call）批次的总数。
    应尽量避免这项数据过大。

    Saved by batching表示有多少个绘制调用（Draw Call）被合并到了批次。
    应尽量让这项数据大。

    Tris表示当前摄像机视锥体的范围内三角面的个数。
    应尽量避免这项数据过大。

    Verts表示当前摄像机视锥体的范围内网格顶点的个数。
    应尽量避免这项数据过大。

    在3D建模软件中创建的模型导入到Unity后，该模型在Unity中显示的三角面和网格顶点的数量和在3D建模软件中的可能不同。因为3D建模软件和Unity对模型的三角面和网格顶点的计算方式可能是不一样的。

    Screen表示当前的屏幕分辨率，以及屏幕的内存占用量。例如Screen：1920×1080 - 23.7MB表示当前屏幕分辨率是1920×1080，屏幕占用了23.7MB的内存。
    应尽量避免这项数据过大。

    SetPass calls表示在当前摄像机的渲染过程中，Unity切换着色器通道（Shader Pass）来渲染游戏对象的次数。一个着色器（Shader）可以包含多个着色器通道，每个着色器通道可以通过不同的方式来渲染游戏对象。但每次切换着色器通道都会消耗一定的性能。
    应尽量避免这项数据过大。

    Shadow casters表示摄像机画面中有多少个游戏对象产生了阴影。同一个游戏对象产生较多的阴影，可能会被算作多个Shadow casters
    应尽量避免这项数据过大。

    Visible skinned meshes表示当前摄像机中有多少个可见的蒙皮网格。网格用来定义一个模型的形状、大小和表面细节等信息，模型的所有顶点、线、面共同构成了这个模型的网格。蒙皮网格是一个与骨骼绑定的网格，这个网格可以发生形变和做出各种动作。一个网格在没有蒙皮之前是不能发生形变的，也不能做出各种动作的。但是在成功蒙皮之后，这个网格就可以发生形变和做出各种动作。
    应尽量避免这项数据过大。

    Animator components playing表示当前场景中有多少个Animator组件正在播放动画。播放动画会消耗性能。
    应尽量避免这项数据过大。

    Animation components playing表示当前场景中有多少个Animation组件正在播放动画。播放动画会消耗性能。
    应尽量避免这项数据过大。

    没用的Animator组件和Animation组件可以考虑删掉。因为即使只有空的动画，Animator组件和Animation组件也会根据自己的工作流程进行每帧的计算和更新，以检查当前动画状态和过渡条件，这样就会消耗不必要的性能。

Unity动态合批

动态合批也叫动态批处理，是Unity的一种优化技术。

对移动的物体使用动态合批后，则Unity不会一个个绘制它们，而是把它们合并为一个批次（Batch），再由CPU把它们一次性提交给GPU进行处理，这样可以减少Draw Call带来的性能消耗，从而提高性能。

官方文档：https://docs.unity3d.com/cn/current/Manual/dynamic-batching.html

动态合批默认是由Unity自动完成。可以在Edit——Project Settings——Player——Other Settings——Dynamic Batching查看。默认Dynamic Batching是勾选的，当条件满足时，Unity会自动对使用了相同材质（Material）的物体进行动态合批。如果取消勾选，则不会进行动态合批。

即使勾选了Dynamic Batching，也必须同时满足以下条件，动态合批才会成功： 1、Unity不能对包含超过900个顶点属性和225个顶点的网格应用动态批处理。这是因为网格的动态批处理对每个顶点都有开销。例如，如果你的着色器使用顶点位置、顶点法线和单个UV，那么Unity最多可以批处理225个顶点。然而，如果你的着色器使用顶点位置、顶点法线、UV0、UV1和顶点切线，那么Unity只能批处理180个顶点。 2、如果GameObjects使用不同的材质实例，Unity就不能将它们批处理在一起，即使它们本质上是相同的。唯一的例外是阴影施法者的渲染。 3、带有光贴图的游戏对象有额外的渲染参数。这意味着，如果你想批处理光照贴图的游戏对象，它们必须指向相同的光照贴图位置。 4、Unity不能完全将动态批处理应用于使用多通道着色器的GameObjects。 几乎所有的Unity着色器都支持正向渲染中的多个光源。为了实现这一点，他们为每个光处理一个额外的渲染通道。Unity只批处理第一个渲染通道。它不能批处理额外的逐像素灯光的绘制调用。 遗留延迟渲染路径不支持动态批处理，因为它在两个渲染通道中绘制GameObjects。第一个通道是灯光预通道，第二个通道渲染GameObjects。

其中我们要注意的是，物体必须使用相同的材质，才有可能成功进行动态合批。

使用动态合批往往能减少CPU和GPU的开销，提升游戏性能，但同时也会占用一定的内存。

是否要开启动态合批，要根据自己的项目来定。可以尝试启用，在性能分析器中看看效果如果，如果效果好，再确定启用它。