您的位置：首页 > 移动开发 > IOS开发

ios性能分析和优化

2013-12-27 10:43 267 查看

http://game.ceeger.com/Manual/iphone-InternalProfiler.html
http://game.ceeger.com/Manual/Profiler.html http://game.ceeger.com/Manual/iphone-Optimizing-Physics.html

使用内置分析器的性能测量 Measuring Performance with the Built-in Profiler

Date:2013-05-13 05:38

Unity iOS and Android contain a built in profiler. This is included in all versions of the add-ons, and is not a Pro feature.
(Pro add-ons do contain a more advanced profiler, however.) The built-in profiler emits console messages from the game running on device. These messages are written every 30 seconds and will provide insight into how the game is running. Understanding what
these messages mean is not always easy, but as a minimum, you should quickly be able to determine if your game is CPU or GPU bound, and if CPU bound whether it's script code, or perhaps Mono garbage collection that is slowing you down. See later in this page
to learn how to configure the built-in profiler.

Unity的iOS和Android包含一个内置分析器。这是包含在所有版本的附加项，而不是专业版独有的功能。（不过专业版的附加项有一个更先进的分析器。）内置分析器从设备上运行的游戏发出控制台消息。这些消息每隔30秒被写入一次，并将提供深入了解如何运行游戏。了解这些消息是什么意思并不容易，但作为最低限度，你应该能够很快确定你的游戏是CPU或GPU绑定。如果是CPU绑定，它是否有脚本代码，或者Mono的垃圾回收减慢了你的速度。

What the Profiler Tells You 分析器能告诉你什么

Here's an example of the built-in profiler's output.

这里是一份内置分析器输出实例。

iPhone/iPad Unity internal profiler stats: iPhone/iPad Unity内部分析器数据：
cpu-player>    min:  9.8   max: 24.0   avg: 16.3
cpu-ogles-drv> min:  1.8   max:  8.2   avg:  4.3
cpu-waits-gpu> min:  0.8   max:  1.2   avg:  0.9
cpu-present>   min:  1.2   max:  3.9   avg:  1.6
frametime>     min: 31.9   max: 37.8   avg: 34.1
draw-call #>   min:   4    max:   9    avg:   6     | batched:    10
tris #>        min:  3590  max:  4561  avg:  3871   | batched:  3572
verts #>       min:  1940  max:  2487  avg:  2104   | batched:  1900
player-detail> physx:  1.2 animation:  1.2 culling:  0.5 skinning:  0.0 batching:  0.2 render: 12.0 fixed-update-count: 1 .. 2
mono-scripts>  update:  0.5   fixedUpdate:  0.0 coroutines:  0.0
mono-memory>   used heap: 233472 allocated heap: 548864  max number of collections: 1 collection total duration:  5.7

All times are measured in milliseconds per frame. You can see the minimum, maximum and average times over the last thirty frames.

所有时间都是以毫秒/帧为单位。你可以看到最后30帧的最小、最大和平均时间。

General CPU Activity 一般CPU活动

cpu-player
Displays the time your game spends executing code inside the Unity engine and executing scripts on the CPU.

显示游戏在Unity引擎内部执行代码以及在CPU执行脚本花费的时间。

cpu-ogles-drv
Displays the time spent executing OpenGL ES driver code on the CPU. Many factors like the number of draw calls, number of internal rendering state changes, the rendering pipeline setup and even the number of
processed vertices can have an effect on the driver stats.

显示CPU上执行OpenGL ES驱动程序代码所花费的时间。很多因素，诸如绘制调用的数目、内部渲染的状态变化、渲染管线的设置，甚至处理顶点的数目都能影响驱动状态。

cpu-waits-gpu
Displays the time the CPU is idle while waiting for the GPU to finish rendering. If this number exceeds 2-3 milliseconds then your application is most probably fillrate/GPU processing bound. If this value is
too small then the profile skips displaying the value.

显示CPU处于空闲状态，等待GPU完成渲染所需的时间。如果这个数字超过2-3毫秒，那么最有可能的是应用程序的填充率/GPU绑定了。如果这个值太小，则配置文件过跳过显示这个值。

msaa-resolve
The time taken to apply anti-aliasiing. 应用抗锯齿所需时间。

cpu-present
The amount of time spent executing the presentRenderbuffer command in OpenGL ES.

在OpenGL ES中执行presentRenderbuffer命令花费的时间量。

frametime
Represents the overall time of a game frame. Note that iOS hardware is always locked at a 60Hz refresh rate, so you will always get multiples times of ~16.7ms (1000ms/60Hz = ~16.7ms).

代表一个游戏框架的总体时间。需要注意的是，iOS硬件总是锁定在60Hz的刷新率，所以你总会得到一个倍数时间 ~16.7ms (1000ms/60Hz = ~16.7ms)

Rendering Statistics 渲染统计

draw-call #
The number of draw calls per frame. Keep it as low as possible.

每一帧调用绘制的数量。保持尽可能低的水平。

tris #
Total number of triangles sent for rendering.

用于渲染的三角形总数。

verts #
Total number of vertices sent for rendering. You should keep this number below 10000 if you use only static geometry but if you have lots of skinned geometry then you should keep it much lower.

用于渲染的顶点总数。如果你只使用静态几何，你应该保持这个数字低于10000，但如果你有大量的蒙皮几何体，你应该保持更低。

batched
Number of draw-calls, triangles and vertices which were automatically batched by the engine. Comparing these numbers with draw-call and triangle totals will give you an idea how well is your scene prepared for
batching. Share as many materials as possible among your objects to improve batching.

绘制调用的数量，引擎会自动批处理三角形和顶点。比较这些绘制调用的数目和三角形的总数会告诉你，你的场景是如何做好批处理准备的。在对象中分享尽可能多的材质，以提高批处理。

Detailed Unity Player Statistics 详细的Unity播放器统计信息

The player-detail section provides a detailed breakdown of what is happening inside the engine:-

播放器-详细信息部分提供了引擎内部发生了什么的详细分项：-

physx
Time spent on physics. 物理花费的时间。

animation
Time spent animating bones. 骨骼动画花费的时间。

culling
Time spent culling objects outside the camera frustum.

摄像机视景外剔除对象花费的时间。

skinning
Time spent applying animations to skinned meshes.

应用动画为蒙皮网格花费的时间。

batching
Time spent batching geometry. Batching dynamic geometry is considerably more expensive than batching static geometry.

批处理几何体花费的时间。批处理动态几何体比静态几何体成本要昂贵得多。

render
Time spent rendering visible objects.

渲染可视化对象花费的时间。

fixed-update-count
Minimum and maximum number of FixedUpdates executed during this frame. Too many FixedUpdates will deteriorate performance considerably. There are some simple guidelines to set a good value for the fixed time
delta here.

在这一帧内执行的FixedUpdates的最小和最大数量。太多的FixedUpdates将会严重恶化性能。这里有一些简单的指引，以帮助你设置较好的固定时间增量值。

Detailed Scripts Statistics 详细的脚本统计

The mono-scripts section provides a detailed breakdown of the time spent executing code in the Mono runtime:

mono脚本部分提供了Mono运行时执行代码所花费时间的详细分项：

update
Total time spent executing all Update() functions in scripts.

在脚本中执行全部Update()函数花费的时间。

fixedUpdate
Total time spent executing all FixedUpdate() functions in scripts.

在脚本中执行全部FixedUpdate() 函数花费的时间。

coroutines
Time spent inside script coroutines.

脚本内协同程序花费的时间。

Detailed Statistics on Memory Allocated by Scripts

由脚本分配内存的详细统计

The mono-memory section gives you an idea of how memory is being managed by the Mono garbage collector:

mono内存部分告诉你内存如何管理Mono垃圾回收器：

allocated heap
Total amount of memory available for allocations. A garbage collection will be triggered if there is not enough memory left in the heap for a given allocation. If there is still not enough free memory even after
the collection then the allocated heap will grow in size.

可供分配的内存总量。如果在给定的分配堆中内存不足，将会触发垃圾回收。如果在回收后仍然没有足够的可用内存，分配的堆的大小将会增加。

used heap
The portion of the allocated heap which is currently used up by objects. Every time you create a new class instance (not a struct) this number will grow until the next garbage collection.

这是当前对象用完的分配的堆的那部分。每当你创建一个新的类实例（不是结构体），这个数字将会增长，直到下一次垃圾回收。

max number of collections
Number of garbage collection passes during the last 30 frames.

在最后30帧垃圾回收通过的数量。

collection total duration
Total time (in milliseconds) of all garbage collection passes that have happened during the last 30 frames.

在最后30帧，所有垃圾回收通过的总时间（以毫秒为单位）。

Configuration 配置

iOS
On iOS, it's disabled by default so to enable it, you need to open the Unity-generated XCode project, select the

iPhone_Profiler.h

file and change the line

在iOS上，默认情况下是禁用，所以要启用它，你需要打开Unity-generated XCode项目，选择iPhone_Profiler.h文件，并把下面这一行

#define ENABLE_INTERNAL_PROFILER 0

to 改为

#define ENABLE_INTERNAL_PROFILER 1

Select View > Debug Area > Activate Console in the XCode menu to display the output console (GDB) and then run your project. Unity will output statistics to the console window every thirty frames.

在XCode菜单中选择View > Debug Area > Activate Console 来显示输出控制(GDB)，然后运行你的工程。Unity每30帧会往控制台输出一次统计数据。

Android
On Android, it is enabled by default. Just make sure Development Build is checked in the player settings when building, and the statistics should show up in logcat when run on the device. To view logcat, you need adb or the Android Debug
Bridge. Once you have that, simply run the shell command adb logcat.

在安卓上，默认为启动。只需确保在构建时，Development Build被勾选，并且在设备上运行时统计数据应该显示在logcat。要查看logcat，你需要adb或者Android Debug Bridge。一旦拥有它，你只需要运行shell命令adb logcat就可以了。

分析器(仅专业版) Profiler (Pro only)

Date:2013-07-01 14:17

The Unity Profiler helps you to optimize your game. It reports for you how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating or in your game logic.

Unity分析器可以帮助你优化你的游戏。它为您报告在你的游戏的各个领域所花费的时间。例如，它可以报告渲染、动画或在你的游戏逻辑花费时间的百分比。
You can play your game in the Editor with Profiling on, and it will record performance data. The Profiler window then displays the data in a timeline, so you can see the frames or areas that spike (take more time) than others. By clicking anywhere in the
timeline, the bottom section of the Profiler window will display detailed information for the selected frame.

在编辑器中，你可以将你的游戏在分析器运行着的状态下运行，它会记录性能数据。分析器窗口，在时间轴上显示数据，所以你可以看到帧或区域峰值（比其他需要更多的时间）。在时间轴中的任何地方按一下，分析器窗口的底部区域会显示选定的帧的详细信息。
Note that profiling has to instrument your code. This instrumentation has a small impact on the performance of your game. Typically this overhead is small enough to not affect the game framerate. When using profiling it is typical to consider only
the ratio (or percentage) of time spent in certain areas. Also, to improve performance focus on those parts of the game that consume the most time. Compare profiling results before and after code changes and determine the improvements you measure. Sometimes
changes you make to improve performance might have a negative effect on frame rate; unexpected consequences of code optimization should be expected.

请注意，分析时必须检测你的代码。这检测会对你的游戏性能有小小影响。通常情况下，这种开销是足够小，不会影响游戏的帧率。当使用分析时，它是典型的考虑时间花费在某些领域的比例（或百分比）。此外，为了提高性能，重点在游戏消耗的时间最多的那些部分。代码更改前后比较分析结果，并确定您测量的改进。有时，您所做的更改来提高性能，可能对帧速率有负面影响;应预计代码优化的意外的后果。

Profiler window 分析器窗口

CPU Usage Area CPU使用率区域
Rendering Area 渲染区域
Memory Area 内存区域
Audio Area 音频区域
ProfilerPhysics 物理学区域
GPU Area GPU区域

在iOS的性能优化 Optimizing Performance in iOS.

Date:2012-04-03 16:13

Good performance is an essential ingredient in most games and an understanding of the graphical and processing abilities of iOS devices will help you get the best results from them.

良好的性能在大多数游戏中的重要组成部分以及了解iOS设备的图形处理能力将帮助你从中获得最好的结果。
This section explains how to optimize an iOS project to make the best possible use of the hardware.

本部分阐述了如何iOS项目使尽可能利用硬件。

Optimizing Graphics Performance优化图形性能

Draw Call Batching 描绘调用批处理
Modeling Characters for Optimal Performance 为优化性能建模角色
Rendering Statistics Window 渲染数据统计窗口

Optimizing Physics Performance 优化物理性能
Optimizing Script Performance 优化脚本性能
Measuring Performance with the Built-in Profiler 用内置分析器测试性能
Tuning Main Loop Performance 调整主循环性能
Optimizing the Size of the Built iOS Player 优化内置iOS播放器大小

优化脚本性能 Optimizing Script Performance

Date:2012-04-12 12:06

This page gives some general hints for improving script performance on iOS.

此页面提供了一些一般的技巧，提高了在iOS上的脚本性能。

Reduce Fixed Delta Time 减少固定的增量时间

Use a fixed delta time value between 0.04 and 0.067 seconds (ie, 15-25 frames per second). You can
change this in Edit->Project Settings->Time. This reduces the frequency with which FixedUpdate is called and how often the physics engine has to perform collision detection and rigidbody updates. If you are using a rigidbody
for the main character, you can enable interpolation in the Rigidbody Component to smooth out low fixed delta time steps.

使用fixedDeltaTime值在0.04～0.067秒之间（例如，每秒15～25帧之间）。可以在Edit->Project
Settings->Time修改这个。这降低了FixedUpdate被调用和物理引擎执行碰撞检测和刚体更新的频率。如果为主角色使用刚体，你可以在刚体组件启用插值来平滑降低固定增量时间步。

Reduce GetComponent Calls 减少GetComponent调用

Using GetComponent or built-in component accessors can have a noticeable overhead. You can avoid this by getting a reference to the component once and assigning it to a variable (sometimes referred to as "caching" the reference). For example,
if you are using something like:-

使用GetComponent或内置的组件访问器有明显的性能开销。可以通过获取一次组件的引用并指定给变量来避免这个（有时也被称为"缓存"的引用）。例如，如果你使用像这样：

function Update () {
transform.Translate(0, 1, 0);
}

...you would get better performance by changing it to:-

......通过改变它会得到更好的性能： -

var myTransform : Transform;

function Awake () {
myTransform = transform;
}

function Update () {
myTransform.Translate(0, 1, 0);
}

Avoid Allocating Memory 避免分配内存

You should avoid allocating new objects unless you really need to, since they increase the garbage collection overhead when they are no longer in use. You can often reuse arrays and other objects rather than allocate new ones and doing so will help to minimise
garbage collection. Also, you should use structs instead of classes where possible. Struct variables are allocated from the stack like simple types rather than from the heap like object types. Since stack allocation is faster and involves no garbage collection,
structs will often improve performance if they are fairly small in size. While large structs will still avoid allocation/collection overhead, they will incur a separate overhead due to "pass-by-value" copying and may actually be less efficient than the equivalent
object classes.

你应该避免分配新的对象，除非你真的需要，当他们不再使用时，因为它们增加了垃圾收集的开销。你经常可以重复使用数组和其他物体，而不是分配新的，这样做将有助于减少垃圾收集。此外，在可能的情况下你应该使用结构而取代类。从堆栈（stack）中分配结构变量像简单类型而不是从堆（heap）中，像对象类型。由于堆栈分配速度非常快，不涉及垃圾收集，如果它们的大小相当小，结构往往会提高性能。同时大的结构仍然将避免分配/收集的开销，由于pass-by-value的拷贝将产生一个单独的开销，实际上可能效率低于同等的对象类。

Minimise the GUI 尽量减少GUI

The GUILayout functions are very convenient for automatic spacing of GUI elements. However, this automation
naturally comes with a processing overhead. You can avoid some of this overhead by handling the layout manually using the GUI functions.
Additionally, you can set a script's useGUILayoutvariable to false in order to disable
the layout phase completely:-

GUILayout功能对于GUI元素的自动间距都非常方便。然而这种自动化有一些处理性能开销。通过使用GUI功能手动处理布局可以避免这种开销。此外，您可以设置脚本的useGUILayout变量为false，以完全禁用此布局。

function Awake () {
useGUILayout = false;
}

Use iOS Script Call Optimization 使用iOS脚本调用优化

Most of the functions in the UnityEngine namespace are implemented in C/C++. Calling a C/C++ function from a Mono script involves a performance overhead. You can use iOS Script Call optimization (menu: Edit->Project Settings->Player)
to save about 1 to 4 milliseconds per frame. The options for this setting are:-

大多数在UnityEngine命名空间的功能是在C/C++实现。从Mono脚本调用C/C++功能涉及到性能开销。可以使用iOS脚本调用优化(菜单: Edit->Project Settings->Player)，节省大约每帧1至4毫秒。

Slow and Safe - the default Mono internal call handling with exception support.

慢而安全 - 默认的Mono内部调用支持异常处理。
Fast and Exceptions Unsupported - a faster implementation of Mono internal call handling. However, this doesn't support exceptions and so should be used with caution. An app that doesn't explicitly handle exceptions
(and doesn't need to deal with them gracefully) is an ideal candidate for this option.

快而不提供异常 - Mono内部调用处理快速执行。然而，并不提供异常，所以应慎用。应用程序并不需要明确的处理异常，用此选项。

Optimizing Garbage Collection 优化垃圾收集

As mentioned above, it is best to avoid allocations as far as possible. However, given that they can't be completely eliminated, there are two main strategies you can use to minimise their intrusion into gameplay:-

如上所述，最好是尽可能避免分配。然而，由于不能完全消除，主要有两种方法可以使用，以减少它们侵入到游戏： -

Small heap with fast and frequent garbage collection

小堆快而频繁的垃圾收集

This strategy is often best for games that have long periods of gameplay where a smooth framerate is the main concern. A game like this will typically allocate small blocks frequently but these blocks will be in use only briefly. The typical heap size when
using this strategy on iOS is about 200KB and garbage collection will take about 5ms on an iPhone 3G. If the heap increases to 1MB, the collection will take about 7ms. It can therefore be advantageous sometimes to request a garbage collection at a regular
frame interval. This will generally make collections happen more often than strictly necessary but they will be processed quickly and with minimal effect on gameplay:-

这种策略对于长时间的游戏是最好的，有平滑的帧率是主要的考量。像这样的游戏通常会频繁地分配小块，但这些块将只是简单使用。当在iOS上使用这一策略时，典型的堆大小是大约200KB，在iPhone 3G垃圾收集大于需要5ms，如果堆增加到1MB，收集大约需要7ms。因此这是很有利的，有时垃圾收集在一个规则的帧间隔。这通常会使收集发生很多时候绝对必要的，但他们将迅速处理并对游戏影响很小： -

if (Time.frameCount % 30 == 0)
{
System.GC.Collect();
}

However, you should use this technique with caution and check the profiler statistics to make sure that it is really reducing collection time for your game.

但是，应该谨慎使用这项技术，并检查分析器统计以确保它真的为游戏减少了垃圾收集时间。

Large heap with slow but infrequent garbage collection

大堆慢，但不经常垃圾收集

This strategy works best for games where allocations (and therefore collections) are relatively infrequent and can be handled during pauses in gameplay. It is useful for the heap to be as large as possible without being so large as to get your app killed
by the OS due to low system memory. However, the Mono runtime avoids expanding the heap automatically if at all possible. You can expand the heap manually by preallocating some placeholder space during startup (ie, you instantiate a "useless" object that is
allocated purely for its effect on the memory manager):-

这一策略最适合于分配是相对偶发并可在游戏暂停期间处理的游戏。对于堆需要尽可能的大而由于系统内存不足没有那么大，操作系统将杀死应用，这是很有用的。然而，如果可能，在Mono运行时避免自动扩大堆。在启动期间通过预留占位空间可以手动扩展堆（例如，实例化一个无用的对象来分配，纯粹为其在内存管理器的效果）。

function Start() {
var tmp = new System.Object[1024];

// make allocations in smaller blocks to avoid them to be treated in a special way, which is designed for large blocks
for (var i : int = 0; i < 1024; i++)
tmp[i] = new byte[1024];

// release reference
tmp = null;
}

A sufficiently large heap should not get completely filled up between those pauses in gameplay that would accommodate a collection. When such a pause occurs, you can request a collection explicitly:-

一个足够大的堆，在游戏容纳一个收集，暂停之前不应该完全被填满。当这样暂停发生时，应该明确要求收集：

System.GC.Collect();

Again, you should take care when using this strategy and pay attention to the profiler statistics rather than just assuming it is having the desired effect.

再次，使用此策略，应该注意分析器统计情况，而不是仅仅假设它是有预期的效果。

优化物理性能 Optimizing Physics Performance

Date:2012-04-04 10:44

The NVIDIA PhysX physics engine used by Unity is available on iOS but the performance limits of the hardware will be reached more easily on mobile platforms than desktops.

NVIDIA PhysX 物理引擎在iOS可用，但性能受硬件限制。
Here are some tips for tuning physics to get better performance on iOS:-

这里有一些技巧，为调整物理在iOS以获得更好的效果：

You can adjust the Fixed Timestep setting (in the Time manager) to reduce
the time spent on physics updates. Increasing the timestep will reduce the CPU overhead at the expense of the accuracy of the physics. Often, lower accuracy is an acceptable tradeoff for increased speed.

您可以调整Fixed Timestep设置（Time manager），以减少对物理更新所花费的时间。增加时间步长将减少CPU开销，以物理精度为代价。通常情况下，为增加速度而降低精度是可以接受的折中方案。
Set the Maximum Allowed Timestep in the Time manager in the 8-10fps range
to cap the time spent on physics in the worst case scenario.

在Time manager设置Maximum Allowed Timestep，在8-10fps范围，在最坏的情况下，以封顶物理花费的时间。
Mesh colliders have a much higher performance overhead than primitive colliders, so use them sparingly. It is often possible to approximate the shape of a mesh by using child objects with primitive colliders. The child colliders
will be controlled collectively as a single compound collider by the rigidbody on the parent.

网格碰撞器比原始碰撞器有高的多的性能开销，因此尽量少使用。通过使用原始碰撞器的子对象，来尽可能的近似网格的形状。子碰撞器将作为单一复合碰撞器共同控制其父级的刚体。
While wheel colliders are not strictly colliders in the sense of solid objects, they nonetheless have a high CPU overhead.

车轮碰撞器不是严格意义上的固体物体的碰撞，也有很高的CPU开销。

The total amount of physics calculation depends on the number of non-sleeping rigid bodies and colliders in the scene and the complexity of the colliders. You can keep track of how many physics objects there are in the scene using the internal
profiler.

物理计算的总量取决于场景中非休眠刚体和碰撞器的数量以及碰撞器的复杂度。可以在场景使用内部分析器来跟踪有多少物理物体。

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航