U3D性能分析 Profiling

电玩女神 2022-08-18 03:09 228阅读 0赞

Ports that the Unity profiler uses:

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

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

They should be accessible from within the network node. That is, the devices that you're trying to profile on should be able to see these ports on the machine with the Unity Editor with the Profiler on.

它们应当在网络节点内部是可访问的。也就是说，当设置Unity Editor的分析器为开启时，在你尝试进行分析的设备应当是可以看到这些端口的。

## First steps 第一步 ##

Unity relies on the CPU (heavily optimized for the SIMD part of it, like SSE on x86 or NEON on ARM) for skinning, batching, physics, user scripts, particles, etc.

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

The GPU is used for shaders, drawcalls, image effects.

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

### CPU or GPU bound (CPU 或 GPU限制) ###

*  Use the internal profiler to detect the CPU and GPU ms  
    使用内置分析器来检测CPU和GPU ms

### Pareto analysis 帕累托分析法 ###

A large majority of problems (80%) are produced by a few key causes (20%).

很大一部分问题（80%）是由于一小部分关键原因（20%）引起的。

1.  Use the Editor profiler to get the most problematic function calls and optimize them first.  
    使用编辑器分析器来得到最有问题的函数调用，并且在第一时间优化它们。
2.  Make sure the scripts run only when necessary.  
    确保脚本只在必要时才会运行。
    
    1.  Use *OnBecameVisible/OnBecameInvisible* to disable inactive objects.  
        使用OnBecameVisible/OnBecameInvisible 来禁用非活跃对象。
    2.  Use coroutines if you don't need some scripts to run every frame.  
        如果一些脚本不需要在每一帧都运行，就使用协同函数。

// Do some stuff every frame:
    // 在每一帧做一些事情：情：
    void Update () {
        
    }
    
    //Do some stuff every 0.2 seconds:
    // 每0.2秒做一些事情：
    IEnumerator Start ()_ {
        
       while (true) {
        
          yield return new WaitForSeconds (0.2f);
       }
    }

1.  Use the *.NET System.Threading.Thread* class to put heavy calculations to the other thread. This allows you to run on multiple cores, but Unity API is not thread-safe. So buffer inputs and results and read and assign them on the main thread.  
    使用 .NET System.Threading.Thread 类来将繁重的运算放到其他线程里。这允许你在多个内核上运行，但是Unity API不是线程安全的。因此缓冲区在主线程中对它们进行输入、输出、读取、赋值。

## CPU Profiling(CPU分析) ##

### Profile user code 分析用户代码 ###

Not all of the user code is shown in the Profiler. But you can use *Profiler.BeginSample* and *Profiler.EndSample* to make the required user code appear in the profiler.

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

## GPU Profiling (GPU分析) ##

The Unity Editor profiler cannot show GPU data as of now. We're working with hardware manufacturers to make it happen with the Tegra devices being the first to appear in the Editor profiler.

Unity编辑器分析器目前还不可以显示GPU数据。我们正在硬件制造商合作来使得它可以发生在英伟达图睿（Tegra）设备上，这将是第一个出现在编辑器分析器上的GPU。

###  iOS ###

### Tools for iOS (iOS的工具) ###

*  Unity internal profiler (not the Editor profiler). This shows the GPU time for the whole scene.  
    Unity内部分析器（不是编辑器分析器）。这显示了整个场景的GPU时间。
 *  PowerVR PVRUniSCo shader analyzer. See below.  
    PowerVR PVRUniSCo着色分析器。见下文。
 *  iOS: Xcode OpenGL ES Driver Instruments can show only high-level info:  
    iOS：Xcode OpenGL ES驱动仪器仅可以显示上层信息：
    
     *  'Device Utilization %' - GPU time spent on rendering in total. >95% means the app is GPU bound.  
        设备利用率：GPU在渲染上花费的所有时间。>95%意味着该应用程序是GPU绑定的。
     *  'Renderer Utilization %' - GPU time spent drawing pixels.  
        渲染利用率：GPU在绘制像素上花费的时间。
     *  'Tiler Utilization %' - GPU time spent processing vertices.  
        Tiler利用率从：GPU在处理顶点上花费的时间。
     *  'Split count' - the number of frame splits, where the vertex data didn't fit into allocated buffers.  
        分割次数：帧分割的数量，顶点信息无法使用分配的缓冲区。

PowerVR is tile based deferred renderer, so it’s impossible to get GPU timings per draw call. However you can get GPU times for the whole scene using Unity's built-in profiler (the one that prints results to Xcode output). Apple's tools currently can only tell you how busy the GPU and its parts are, but do not give times in milliseconds.

PowerVR是基于平铺的延迟渲染器，因此在每一个draw call时得到GPU计时是不可能的。但是，你可以使用Unity内置的分析器（打印Xcode输出的那一个）得到整个场景的GPU时间。目前，Apple的工具只可以告诉你GPU和它的组件有多繁忙，但是不会给出毫秒单位的时间。

PVRUniSCo gives cycles for the whole shader, and approximate cycles for each line in the shader code. Windows & Mac! But it won't match what Apple's drivers are doing exactly anyway. Still, a good ballpark measure.

PVRUniSCo为整个着色器提供循环，以及为着色器中的每一行提供一个近似的循环。Windows和Mac！但是它不会精确匹配Apple的设备正在做些什么。但是，它仍然是一个不错的估量方法。

###  Android ###

### Tools for Android 安卓的工具 ###

*  Adreno (Qualcomm) 高通
 *  NVPerfHUD (NVIDIA) 英伟达
 *  PVRTune, PVRUniSCo (PowerVR) 德州仪器

On Tegra, NVIDIA provides excellent performance tools which does everything you want - GPU time per draw call, Cycles per shader, Force 2x2 texture, Null view rectangle, runs on Windows, OSX, Linux. PerfHUD ES does not easily work with consumer devices, you need the development board from NVIDIA.

在图睿上，英伟达提供了非常棒的性能工具，它们可以做到你想要实现的任何事——每个draw call时的GPU时间，每个着色器的周期数，Force 2x2 贴图，Null视图矩形，它们可以运行在Windows，OSX，Linux。PerfHUD ES不那么容易和用户设备一起工作，你需要英伟达的开发板。

Qualcomm provides excellent Adreno Profiler (Windows only) which is Windows only, but works with consumer devices! It features Timeline graphs, frame capture, Frame debug, API calls, Shader analyzer, live editing.

高通提供了杰出的Adreno分析器（只适用于Windows），它仅在Windows上工作，但是可以和用户设备一起工作！它的特点有时间轴图形，帧捕捉，帧调试，API调用，着色器分析器，现场编辑等。

### Graphics related CPU profiling (CPU有关的图形分析) ###

The internal profiler gives a good overview per module:

内置的分析器对于每个模块提供了一个很好的概述：

*  time spent in OpenGL ES API 在OpenGL ES API中花费的时间
 *  batching efficiency 批处理效率
 *  skinning, animations, particles 蒙皮，动画，粒子系统

## Memory 内存 ##

There is Unity memory and mono memory.

这里讲述了Unity内存和mono内存。

### Mono memory (Mono内存) ###

Mono memory handles script objects, wrappers for Unity objects (game objects, assets, components, etc). Garbage Collector cleans up when the allocation does not fit in the available memory or on a *System.GC.Collect()* call.

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

Memory is allocated in heap blocks. More can allocated if it cannot fit the data into the allocated block. Heap blocks will be kept in Mono until the app is closed. In other words, Mono does not release any memory used to the OS (Unity 3.x). Once you allocate a certain amount of memory, it is reserved for mono and not available for the OS. Even when you release it, it will become available internally for Mono only and not for the OS. The heap memory value in the Profiler will only increase, never decrease.

内存被分配在堆块中。如果要分配的资源和已分配块不相符时，就会分配更多的内存。堆块将会保留在Mono里，直到app关闭。也就是说，Mono不会释放任何OS使用的内存（Unity 3.x）。一旦你分配了一定数量的内存，它就会被mono保留，并对于OS来说不再是可用的。即使当你释放它，它也仅仅变为是对Mono可用的，而不是对于OS可用。分析器中的堆内存值仅会增加，而永远不会减少。

If the system cannot fit new data into the allocated heap block, the Mono calls a "GC" and can allocate a new heap block (for example, due to fragmentation).

如果系统不能将新的数据分配到已分配的堆块，Mono就会调用一个“GC”，然后可以分配一个新的堆块（例如，根据存储碎片）。

'Too many heap sections' means you've run out of Mono memory (because of fragmentation or heavy usage).

过多的堆片段意味着你已经耗尽了Mono内存（因为存储碎片或者繁重的使用）。

Use *System.GC.GetTotalMemory* to get the total used Mono memory.

使用System.GC.GetTotalMemory来得到已使用的所有Mono内存的数量。

The general advice is, use as small an allocation as possible.

通常的设备应当使用越小的分配越好。

### Unity memory (Unity内存) ###

Unity memory handles Asset data (Textures, Meshes, Audio, Animation, etc), Game objects, Engine internals (Rendering, Particles, Physics, etc). Use *Profiler.usedHeapSize* to get the total used Unity memory.

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

### Memory map 内存映射 ###

No tools yet but you can use the following.

目前还没有任何工具，但是你可以使用下面的方法。

*  Unity Profiler - not perfect, skips stuff, but you can get an overview. It works on the device!  
    Unity分析器——不完美，跳过了一些东西，但是你可以得到一个概览。它在设备上工作！
 *  Internal profiler 内置分析器
    
     *  Shows Used heap and allocated heap - see mono memory.  
        显示已使用的堆和已分配的堆——详见mono内存。
     *  Shows the number of mono allocations per frame.  
        显示每一帧时mono资源分配的数目
 *  Xcode tools - iOS
    
     *  Xcode Instruments Activity Monitor - Real Memory column.  
        Xcode仪器活动监视器——Real Memory列。
     *  Xcode Instruments Allocations - net allocations for created and living objects.  
        仪器分配——对已创建而且活跃的对象的净分配。
     *  VM Tracker (VM跟踪器)
        
         *  textures usually get allocated with IOKit label.  
            贴图通常使用IOKit标签得到分配。
         *  meshes usually go into VM Allocate.  
            网格通常进入VM分配。
 *  Make your own tool 制作你自己的工具。
    
     *  *FindObjectsOfTypeAll (type : Type) : Object\[\]*
     *  *FindObjectsOfType (type : Type): Object\[\]*
     *  *GetRuntimeMemorySize (o : Object) : int*
     *  *GetMonoHeapSize*
     *  *GetMonoUsedSize*
     *  *Profiler.BeginSample/EndSample* \- profile your own code
     *  *UnloadUnusedAssets () : AsyncOperation*
     *  *System.GC.GetTotalMemory/Profiler.usedHeapSize*
 *  References to the loaded objects - There is no way to figure this out. A workaround is to 'Find references in scene' for public variables.  
    对已加载对象的引用——没有方法可以得到它。一个变通的方案是找到场景为公有变量在场景中找到引用。

### Memory hiccups 内存小信息 ###

*  Garbage collector 垃圾回收器
    
     *  This fires when the system cannot fit new data into the allocated heap block.  
        当系统无法把新的数据分配到已分配的堆块中，就会开始工作。
     *  Don't use *OnGUI* on mobiles  
        不要在移动设备上使用OnGUI
        
         *  It shoots several times per frame  
            它在每一帧时都会被调用若干次。
         *  It completely redraws the view.  
            它完全重绘视图。
         *  It creates tons of memory allocation calls that require Garbage Collection to be invoked.  
            它会创建大量的内存分配调用，并需要垃圾回收器来清理。
     *  Creating/removing too many objects too quickly?  
        过快地创建/移除过多的对象？
        
         *  This may lead to fragmentation.  
            这可能会导致碎片。
         *  Use the Editor profiler to track the memory activity.  
            使用编辑器分析器来跟踪内存活动。
         *  The internal profiler can be used to track the mono memory activity.  
            内置分析器可以被用于跟踪mono内存活动。
     *  *System.GC.Collect()* You can use this *.Net* function when it's ok to have a hiccup.  
        当它可以有一个间隔时，你可以使用System.GC.Collect() 这个.Net函数。
 *  New memory allocations 新的内存分配。
    
     *  Allocation hiccups 分配间隔
        
         *  Use lists of preallocated, reusable class instances to implement your own memory management scheme.  
            使用预分配列表，可重用类实例来实现你自己的内存管理计划。
         *  Don't make huge allocations per frame, cache, preallocate instead  
            不要在每一帧时执行大量的分配，使用缓存、预分配来代替。
     *  Problems with fragmentation? 碎片的问题？
        
         *  Preallocate the memory pool. 预分配内存池。
         *  Keep a List of inactive GameObjects and reuse them instead of Instantiating and Destroying them.  
            保存一个非活跃游戏对象列表，然后重用它们而不是实例化再销毁它们。
     *  Out of mono memory 耗尽mono内存
        
         *  Profile memory activity - when does the first memory page fill up?  
            分析内存活动——第一张内存页面什么时候填满的？
         *  Do you really need so many gameobjects that a single memory page is not enough?  
            你真的需要这么多游戏对象以至于一个单独的内存页面还不够？
     *  Use structs instead of classes for local data. Classes are stored on the heap; structs on the stack.  
        对于局部数据，使用结构体而不是类。类被存储在堆；而结构体被存储在栈。

class MyClass {
        
       public int a, b, c;
    }
    
    struct MyStruct {
        
       public int a, b, c;
    }
    
    void Update () {
        
       //BAD 　　//不好的做法
       // allocated on the heap, will be garbage collected later!
    
       //被分配到堆中，随后将会被垃圾回收！
       MyClass c = new MyClass();
    
       //GOOD   // 好的做法
       //allocated on the stack, no GC going to happen!
    
    	//被分配到栈中，垃圾清理器不会发生！
       MyStruct s = new MyStruct();
    }

*  Read the relevant section in the manual Link to 阅读手册中的相关单元链接[http://docs.unity3d.com/Documentation/Manual/UnderstandingAutomaticMemoryManagement.html][http_docs.unity3d.com_Documentation_Manual_UnderstandingAutomaticMemoryManagement.html]

### 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区域，当变换场景时它不会被清理）保留了未使用的资源。

页面最后更新：2012-12-11

[http_docs.unity3d.com_Documentation_Manual_UnderstandingAutomaticMemoryManagement.html]: http://game.ceeger.com/Manual/UnderstandingAutomaticMemoryManagement.html