Android performance tuner unity

Android Performance Tuner (APT) Part of Android Game Development Kit.

Android Performance Tuner (APT) enables you to deliver the best possible experience to each of your users by helping you to measure and optimize frame rates, graphical fidelity, loading time and loading abandonment across many Android devices at scale.

It helps you identify performance issues in your game or app, and also highlights opportunities to improve your fidelity. Impact metrics help you to prioritize, and issues are categorized to help you take action. Information at both device model and device spec level enables you to find the most effective way to act.

What are the benefits?

Android Performance Tuner (APT) helps you deliver a high-quality experience to more users.

New! Understand your loading times and their impact on abandonment

APT tracks both your loading time and loading abandonment across multiple types of loading (first loads, cold loads, warm loads and interlevel loads). It shows you the impact that longer loading times has on abandonment for your game, so that you can determine the optimal loading time.

Measure the quality of your user experience

APT shows you the frame rate and loading time performance of your game on actual user devices in the real world, so you get direct insight into their experience. All metrics are customized to your targets, so you can understand how the game is performing relative to your specific goals.

Diagnose and prioritise your game performance issues

Frame rate and loading time issues are broken out by your quality levels and your in-game annotations, as well as device model, to help you narrow down the root cause. For each frame rate issue, you can see GPU time as well as CPU time, so you can assess what type of optimization may be needed. The number of affected sessions is also shown, so you can understand what’s affecting your users most, and decide what devices or game scenes to focus on first.

Get the best out of every device

As well as surfacing performance rate issues, APT highlights opportunities for you to improve your user experience by increasing fidelity on devices which already perform well but that have room to go further. This enables you to ensure that every user gets the best possible experience of your game.

How does it work?

Android Performance Tuner works with Android vitals.

• Android Performance Tuner records and aggregates live frame time and loading information from your game or app, alongside game annotations and fidelity parameters that you provide.
• When you publish a version of your game or app with Android Performance Tuner, this performance data is uploaded to Google Play and unlocks new performance insights in Android vitals.

To get these performance insights, you must integrate Android Performance Tuner into your game or app and then publish it on Google Play:

Requirements

Android Performance Tuner (APT) works on any Android device (with or without Google Play services) running Android 4.1 (API level 16) or later. This is over 99% of all active Android devices.

For all developers:

• Access to Android vitals
• Product only available in the new Google Play Console

Additional requirements for Unity developers:

• Unity version 2017.4 or later and .NET version 4.6
• To use APK Expansion files, Unity 2018.2 is required
• For improved frame pacing and GPU measurements, Unity version 2019.3.14 or later is required

Additional resources

Android Performance Tuner is part of the AGDK Libraries.

To learn more about Android Performance Tuner, see the following:

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Overview of Android Performance Tuner (Unity)

This guide describes how to use a Unity plugin to record and upload frame time data from Unity 2017.4 or later.

For game engines using C or C++, see the guide for native game engines.

Background

A key component of the game experience is rendering performance. Rendering performance is an outcome of the following two inputs:

• Frame rate: How often a frame is drawn.
• Graphical quality settings: Level of fidelity at which a frame is presented, including simulation fidelity as well as graphics.

For games, good rendering performance is defined as the following:

• Delivering a stable, consistent frame rate (that is, the percentage of frames rendering at the desired frequency).
• Rendering frames at the highest frequency possible while maintaining stability, typically 30 or 60 FPS depending on the type of game.
• Maximizing the level of detail for a user given their screen size and density while still achieving a desired, stable frame rate.

The Android Frame Pacing library limits much of the variation in frame times, providing a stable frame rate for games. The remaining variation in frame times is due to the level of detail displayed during certain scenes in gameplay and the graphical capabilities of the device. Using Android Performance Tuner, you can pinpoint times during gameplay when the frame time is slower or faster than your target, and correlate these issues and opportunities to:

• Specific quality settings
• Specific scenes in your game
• Specific device models or device specs

Record and upload data

The Tuning Fork library relies on one of its tick functions being called each frame by the Android Frame Pacing library (or by the Unity engine for older versions of Unity where the Frame Pacing Library is not present). Within the library, this tick information is aggregated into histograms which are then periodically uploaded to Google Play through an HTTP endpoint. Each tick is recorded as being associated with an instrument key and an annotation. You define annotations using the Unity plugin.

Instrument keys

An instrument key indicates where in the frame the tick comes from and is an integer that must be passed to each tick function call. This is done automatically by the Unity plugin. If the Optimized Frame Pacing option is enabled in the Unity settings for your game (available in Unity version 2019.3.14 or later), Android Performance Tuner will use information from the Android Frame Pacing library to report enhanced metrics.

Annotations

Annotations give contextual information about what your game is doing when a tick is recorded. For example, an annotation could identify any of the following:

• The current game level
• A specific scene is loading
• A «big boss» is on the screen
• Any other relevant game state information

Annotations are defined in a dialog provided by the Unity plugin.

Internally, the Tuning Fork library uses Google’s protocol buffer format to store annotations and fidelity parameters. This is a well-defined, multi-language protocol for extensible, structured data. For more information, see the Protocol Buffers documentation.

Fidelity parameters

Fidelity parameters influence the performance and graphical fidelity of your game, such as mesh level-of-detail, texture resolution, and anti-aliasing method. Like annotations, fidelity parameters are defined in a dialog provided by the Unity plugin.

Memory and CPU overhead

All memory used by the Tuning Fork library is allocated at initialization in order to avoid surprises during gameplay. The size of the data depends on the number of instrument keys, number of possible annotations, and number of buckets in each histogram; it is a multiple of all of these times four bytes for each bucket. There are also two copies of all histograms to allow for submission in a double-buffered fashion.

Submission occurs on a separate thread and doesn’t block tick calls. If no upload connection is available, the submission is queued for later upload.

There is little processing overhead to calling a tick function: it simply calculates an index into the array of histogram buckets and increments an integer count.

Web requests

The library makes two kinds of requests to the server endpoint:

• A generateTuningParameters request at initialization
• Periodically during gameplay, an uploadTelemetry request to send data to the server

Offline players

If there is no available connection at initialization, the request is retried several times with an increasing back-off time. If there is no connection at upload, the upload is cached. Uploads are stored as files in temporary storage.

Requirements

To use the plugin in your game, use a supported version of Unity:

• Unity version 2017.4 or later and .NET version 4.6
• To use APK Expansion files, Unity 2018.2 is required
• For improved frame pacing and GPU measurements, Unity version 2019.3.14 or later is required

Integrate Android Performance Tuner in Unity

You will integrate Android Performance Tuner in Unity by importing and configuring a Unity plugin. Click the Next link below to get started.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Initialize the library and verify operation

This page describes how initialize the library in your game code and verify that it is uploading data to Google Play. To find more information on specific library functions, see the reference documentation.

Initialize the library

In an initialization method at the start of your game, initialize the library by instantiating AndroidPerformanceTuner and calling its Start() method:

This code is enough to get Android Performance Tuner started and your game instrumented. The log statements indicate when Android Performance Tuner has started and when telemetry has been uploaded to the Google Play Console APIs. Later, you will find these statements in the log to verify that the plugin is operating correctly.

Late initialization (Vulkan only)

If your game targets Vulkan and uses Android Frame Pacing, Android Performance Tuner should have a late initialization:

Verify the interval between telemetry uploads

The default interval between telemetry uploads in the plugin settings is 30 seconds. This time is set to a short interval to make it easier to verify the proper uploading of telemetry. When you release your game to production, set this to a large interval (for example, every 10 minutes) so that the game is not making too many requests to the APIs, which is especially important for users who do not have a mobile data plan that includes unlimited data. A large interval also avoids overusing the device battery.

To verify that the interval is set to 30 seconds, do the following:

1. Select Google > Android Performance Tuner to access the settings.
2. Select the Instrumentation Settings tab and click Use advanced settings.
3. Verify that the Intervals (minutes) field contains 0.5.

Instrumentation settings tab in the plugin

Verify proper operation

If you are using IL2CPP or code stripping, see Manage code stripping.

Build your game for Android. While your game is launching on a device, open a terminal on your computer and launch adb logcat :

In the output of adb logcat , search for «TuningFork» (as Tuning Fork is the internal name of the library):

If you made a mistake while setting up the plugin, like forgetting to set the API key, you’ll see an error in the initialization logs:

Check that Android Performance Tuner is uploading telemetry. If you see TuningFork initialized in the logs, wait a bit more and look for logs indicating that telemetry is being uploaded.

You can also search in the logs for «Connecting to:». This message is followed by the response code a few lines after.

If you don’t see telemetry upload logs, verify that you properly set the interval between each upload in the Android Performance Tuner settings to a small value, like 30 seconds.

Manage code stripping

Google.Protobuf.dll uses reflection. During code stripping, some of the required code may be removed. To avoid this removal, the plugin contains a link.xml file with information about which symbols should be preserved. If you need some functionality of protobuf which uses reflection and you have code stripping enabled, add this information into the link.xml file to preserve the symbols.

You can read more about managed code strippping in the Unity documentation.

If you need to preserve all symbols in protobuf, add a link.xml file to your project that contains the following:

Ahead-of-time compile (AOT)

Ahead-of-time compile is required for the IL2CPP backend and Unity versions 2017 and 2018.

The AOT compiler may not generate code for generic methods. You need to force the compiler to generate the proper code required for protobuf by adding the following method:

You can read more about scripting restrictions in the Unity documentation.

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник

Android performance tuner unity

What better place to start than profiling and the process of gathering and acting on mobile performance data? This is where optimizing mobile performance truly begins.

Profile early, often, and on the target device

The Unity Profiler provides essential performance information about your application, but it can’t help you if you don’t use it. Profile your project early in development, not just when you are close to shipping. Investigate glitches or spikes as soon as they appear. As you develop a “performance signature” for your project, you’ll be able to spot new issues more easily.

While profiling in the Editor can give you an idea of the relative performance of different systems in your game, profiling on each device gives you the opportunity to gain more accurate insights. Profile a development build on target devices whenever possible. Remember to profile and optimize for both the highest- and lowest-spec devices that you plan to support.

Along with the Unity Profiler, you can leverage native tools from iOS and Android for further performance testing on their respective engines:

Certain hardware can take advantage of additional profiling tools (e.g., Arm Mobile Studio, Intel VTune, and Snapdragon Profiler). See Profiling Applications Made with Unity for more information.

Focus on optimizing the right areas

Don’t guess or make assumptions about what is slowing down your game’s performance. Use the Unity Profiler and platform-specific tools to locate the precise source of a lag.

Of course, not every optimization described here will apply to your application. Something that works well in one project may not translate to yours. Identify genuine bottlenecks and concentrate your efforts on what benefits your work.

Understand how the Unity profiler works

The Unity Profiler can help you detect the causes of any lags or freezes at runtime and better understand what’s happening at a specific frame, or point in time. Enable the CPU and Memory tracks by default. You can monitor supplementary Profiler Modules like Renderer, Audio, and Physics, as needed for your game (e.g., physics-heavy or music-based gameplay).

Build the application to your device by checking Development Build and Autoconnect Profiler, or connect manually to accelerate app startup time.

Choose the platform target to profile. The Record button tracks several seconds of your application’s playback (300 frames by default). Go to Unity > Preferences > Analysis > Profiler > Frame Count to increase this as far as 2000 if you need longer captures. While this means that the Unity Editor has to do more CPU work and take up more memory, it can be useful depending on your specific scenario.

This is an instrumentation-based profiler that profiles code timings explicitly wrapped in ProfileMarkers (such as MonoBehaviour’s Start or Update methods, or specific API calls). Also, when using the Deep Profiling setting, Unity can profile the beginning and end of every function call in your script code to tell you exactly which part of your application is causing a slowdown.

When profiling your game, we recommend that you cover both spikes and the cost of an average frame in your game. Understanding and optimizing expensive operations that occur in each frame can be more useful for applications running below the target frame rate. When looking for spikes, explore expensive operations first (e.g., physics, AI, animation) and garbage collection.

Click in the window to analyze a specific frame. Next, use either the Timeline or Hierarchy view for the following:

• Timeline shows the visual breakdown of timing for a specific frame. This allows you to visualize how the activities relate to one another and across different threads. Use this option to determine if you are CPU- or GPU-bound.
• Hierarchy shows the hierarchy of ProfileMarkers, grouped together. This allows you to sort the samples based on time cost in milliseconds (Time ms and Self ms). You can also count the number of Calls to a function and the managed heap memory (GC Alloc) on the frame.

Read a complete overview of the Unity Profiler here. Those new to profiling can also watch this Introduction to Unity Profiling.

Before optimizing anything in your project, save the Profiler .data file. Implement your changes and compare the saved .data before and after the modification. Rely on this cycle to improve performance: profile, optimize, and compare. Then, rinse and repeat.

Use the Profile Analyzer

This tool lets you aggregate multiple frames of Profiler data, then locate frames of interest. Want to see what happens to the Profiler after you make a change to your project? The Compare view allows you to load and differentiate two data sets, so you can test changes and improve their outcome. The Profile Analyzer is available via Unity’s Package Manager.

Work on a specific time budget per frame

Each frame will have a time budget based on your target frames per second (fps). Ideally, an application running at 30 fps will allow for approximately 33.33 ms per frame (1000 ms / 30 fps). Likewise, a target of 60 fps leaves 16.66 ms per frame.

Devices can exceed this budget for short periods of time (e.g., for cutscenes or loading sequences), but not for a prolonged duration.

Account for device temperature

For mobile, however, we don’t recommend using this maximum time consistently as the device can overheat and the OS can thermal throttle the CPU and GPU. We recommend that you use only about 65% of the available time to allow for cooldown between frames. A typical frame budget will be approximately 22 ms per frame at 30 fps and 11 ms per frame at 60 fps.

Most mobile devices do not have active cooling like their desktop counterparts. Physical heat levels can directly impact performance.

If the device is running hot, the Profiler might perceive and report poor performance, even if it is not cause for long-term concern. To combat profiling overheating, profile in short bursts. This cools the device and simulates real-world conditions. Our general recommendation is to keep the device cool for 10-15 minutes before profiling again.

Determine if you are GPU-bound or CPU-bound

The Profiler can tell you if your CPU is taking longer than your allotted frame budget, or if the culprit is your GPU. It does this by emitting markers prefixed with Gfx as follows:

• If you see the Gfx.WaitForCommands marker, it means that the render thread is ready, but you might be waiting for a bottleneck on the main thread.
• If you frequently encounter Gfx.WaitForPresent, it means that the main thread was ready but was waiting for the GPU to present the frame.

Unity employs automatic memory management for your user-generated code and scripts. Small pieces of data, like value-typed local variables, are allocated to the stack. Larger pieces of data and longer-term storage are allocated to the managed heap.

The garbage collector periodically identifies and deallocates unused heap memory. While this runs automatically, the process of examining all the objects in the heap can cause the game to stutter or run slowly.

Optimizing your memory usage means being conscious of when you allocate and deallocate heap memory, and how you minimize the effect of garbage collection. See Understanding the managed heap for more information.

Use the Memory Profiler

This separate add-on (available as an Experimental or Preview package in the Package Manager) can take a snapshot of your managed heap memory, to help you identify problems like fragmentation and memory leaks.

Click in the Tree Map view to trace a variable to the native object holding onto memory. Here, you can identify common memory consumption issues, like excessively large textures or duplicate assets.

Learn how to leverage the Memory Profiler in Unity for improved memory usage. You can also check out our official Memory Profiler documentation.

Reduce the impact of garbage collection (GC)

Unity uses the Boehm-Demers-Weiser garbage collector, which stops running your program code and only resumes normal execution once its work is complete.

Be aware of certain unnecessary heap allocations, which could cause GC spikes:

• Strings: In C#, strings are reference types, not value types. Reduce unnecessary string creation or manipulation. Avoid parsing string-based data files such as JSON and XML; store data in ScriptableObjects or formats like MessagePack or Protobuf instead. Use the StringBuilder class if you need to build strings at runtime.
• Unity function calls: Some functions create heap allocations. Cache references to arrays rather than allocating them in the middle of a loop. Also, take advantage of certain functions that avoid generating garbage. For example, use GameObject.CompareTag instead of manually comparing a string with GameObject.tag (as returning a new string creates garbage).
• Boxing: Avoid passing a value-typed variable in place of a reference-typed variable. This creates a temporary object, and the potential garbage that comes with it implicitly converts the value type to a type object (e.g., int i = 123; object o = i). Instead, try to provide concrete overrides with the value type you want to pass in. Generics can also be used for these overrides.
• Coroutines: Though yield does not produce garbage, creating a new WaitForSeconds object does. Cache and reuse the WaitForSeconds object rather than creating it in the yield line.
• LINQ and Regular Expressions: Both of these generate garbage from behind-the-scenes boxing. Avoid LINQ and Regular Expressions if performance is an issue. Write for loops and use lists as an alternative to creating new arrays.

Time garbage collection if possible

If you are certain that a garbage collection freeze won’t affect a specific point in your game, you can trigger garbage collection with System.GC.Collect.

See Understanding Automatic Memory Management for examples of how to use this to your advantage.

Use the incremental garbage collector to split the GC workload

Rather than creating a single, long interruption during your program’s execution, incremental garbage collection uses multiple, much shorter interruptions that distribute the workload over many frames. If garbage collection is impacting performance, try enabling this option to see if it can reduce the problem of GC spikes. Use the Profile Analyzer to verify its benefit to your application.

Источник