Practical Guide for Optimizing Unity on Mobiles

COPYRIGHT 2014 @ UNITY TECHNOLOGIES
PRACTICAL GUIDE TO
OPTIMIZATION ON MOBILES
Valentin Simonov
Field Engineer @ Unity Technologies
E-mail: val@unity3d.com
Skype: simonov.valentin
Comment: additional comments were added to slides.
Content shown in live demos is obviously missing.

Valentin Simonov
Field Engineer @ Unity Technologies
• Work with Unity customers to get
maximum performance from their
games
• Teach Unity
• Translated a book about Unity
• Maintain a few open source projects:
• https://github.com/TouchScript/TouchScript
E-mail: val@unity3d.com
Skype: simonov.valentin

COPYRIGHT 2014 @ UNITY TECHNOLOGIESCOPYRIGHT 2014 @ UNITY TECHNOLOGIES
OPTIMIZATION

while (true)
{
var stuff = FindStuffToOptimize();
if (stuff == null) break;
Optimize(stuff);
}
Comment: in theory optimization loop is that simple. In practice we have such annoying concepts like TIME and MONEY,
so FindStuffToOptimize() function must also consider impact and business value of issues it returns.

Stuff FindStuffToOptimize()
{
var stuff = …; // ???
return stuff;
}
Comment: so, how should the FindStuffToOptimize function work?

Every developer knows where
issues in his code are.

Every developer knows where
issues in his code are.
Comment: LOL! Of course not. Developers usually know where the code they’d LIKE to optimize is,
but without actual profiling it is impossible to say if this makes sense.

SET THE TARGET DEVICE

“How do I
optimize my game
on iOS?”
Random Unity Developer
Comment: All phones are very different. The first step must be figuring out what your target device is.
The question “How do I optimize my game on iOS” doesn’t make sense, instead you should ask “How do I make my game run 30 fps
on iPhone 4s?”.

TEST SCENE
Chinese pool simulator
Comment: next you need a reference scene to base your tests on. This scene must contain 1.5-2x all assets that is possible
to create in your game. For example if you are making a pool simulator game, this is how your test scene should look.

TEST AND MEASURE

DON’T WASTE TIME!
You must:
1. Know how to use tools to get data from the target device,
2. Have enough knowledge to interpret this data.
Comment: this must be the most important slide. If you are not following this procedure you most likely just wasting time.
This is probably one of the fundamental differences between senior and junior developers. When junior developers encounter an issue
they run around in panic, while senior developers seem to know what they are doing.

1. Set the target device
2. Test and measure
3. Know your platform
4. Know your tools
5. Profile on device
6. CPU
7. GPU
8. Memory
9. Project structure

KNOW YOUR PLATFORM

“Nothing is black and white…”
* Except black and white.
Comment: nothing is ever black and white. You should not blindly do (or not do) things because you were told that they were bad.
Usually it depends…

“The trouble with quotes
on the Internet is that
you can never know if
they are genuine.”
Abraham Lincoln

DRAW CALLS ARE NOT THE WORST
Comment: static batching in Unity is implemented with several draw calls with no state changes which are fast.

OVERDRAW IS YOUR ENEMY
Comment: all mobile devices have a maximum number of pixels they can draw a second. Divided by 60 fps and retina resolution
you’ll get a relatively low number. This means that you should really try to avoid drawing fully transparent pixels which get alpha blended.

Comment: to avoid overdraw you can use more complex
geometry effectively cutting empty space.

Comment: when you import sprites Unity automatically does this for you. But it doesn’t do it very smart. There are plugins on Asset Store
which do much better job.

DON’T USE CUTOUT SHADERS
Comment: cutout shaders are bad on mobile GPUs. Here’s a test where I was rendering a fullscreen transparent checkerboard.
Left: transparent shader, right: cutout shader.

DON’T MOVE 2D COLLIDERS
• Box2D can’t change colliders, it has to recreate them
• Don’t move 2d colliders
• Only move transforms with Rigidbody2D

KNOW WHERE ASSETS LIVE
• There’s native (c++) and managed (c#) memory
• Assets live in native memory
• Managed memory has light wrappers for assets
• myTexture = null; — wrapper is GCd, texture data is stuck
• Destroy(myTexture); — wrapper is stuck, texture data is freed
• Resources.UnloadUnusedAssets(); — destroys stuck assets

EXAMPLE: WWW
• WWW www = new WWW(…)
-> allocate buffers
• www.Dispose()
-> release buffers
• GC(?)-> www.~WWW()
-> release buffers
WWW wrapper
WWW data
Managed

READ THIS:
• Unity iOS and Android - cross-platform challenges and solutions
http://www.realtimerendering.com/downloads/MobileCrossPlatformChallenges_siggraph.pdf
• Tuning your OpenGL ES app
https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_Programming
Guide/Performance/Performance.html
• Squeezing performance out of your unity gear vr game
https://developer.oculus.com/blog/squeezing-performance-out-of-your-unity-gear-vr-game/
https://developer.oculus.com/blog/squeezing-performance-out-of-your-unity-gear-vr-game-continued/
• Mobile performance tuning: poor man's tips and tricks
http://www.slideshare.net/valentinsimonov/mobile-performance-tuning-48786822

KNOW YOUR TOOLS

KNOW YOUR TOOLS
• Unity Profiler
• Unity Frame Debugger
• Xcode
• Xcode Frame Debugger
• Instruments
Comment: here a sample game is shown and different tools are used to get relevant data while it’s running on an iPhone.

PROFILE ON DEVICE

PROFILE ON DEVICE
• Hardware is very different
• Editor uses a different player
• Editor keeps more stuff in memory
• It’s possible to do a lot of unnecessary work
(GetComponent<T>() allocates???!)

CPU

CPU
• Loading time:
• Resources overhead
• Parsing/loading JSON/XML
• Building cached data
• Downloading bundles
• Instantiating stuff
• Useless calculations:
• Invisible objects
• Empty cameras
• Physics

GPU

GPU
• Overdraw
• Sprite geometry
• Particle systems (super bad on iPhone4)
• WTF geometry (wrong or totally useless)
• Broken batching
• Shader complexity

MEMORY

MEMORY
• Garbage in managed memory -> GC lag spikes
• instantiation
• foreach allocates* 40 bytes
• … all the other stuff
• Resources in native memory

PROJECT

PROJECT
• Multiple JSON/XML parsers
• Multiple tween engines
• Multiple loggers
• Example code
• All this stuff goes into generated IL2CPP code
• Example: 72Mb vs. 64Mb generated code size on test game

STUFF WE FOUND
• Loading time:
• 2 seconds to parse JSON
• 3 seconds to generate the list of images from the bundle
• 2 seconds to fill pool of bots
• WWW is not disposed
• Resources overhead
• Empty fullscreen quad
• Broken batching, a lot of overdraw on sprites
• 2D colliders are constantly rebuilt due to animation
• Shaders are too complex
• Text is constantly updated
• Game Over window is very heavy
• foreach loops allocate 40 bytes each
• A lot of unnecessary code
• …

1. Have you RTFM?
2. Do you know your target device?
3. Are you profiling on device?
4. Are you using the right tools?
5. Are you fixing the right issues?
QUESTIONS?

Practical Guide for Optimizing Unity on Mobiles

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Practical Guide for Optimizing Unity on Mobiles

Similar to Practical Guide for Optimizing Unity on Mobiles (20)

Recently uploaded

Recently uploaded (20)

Practical Guide for Optimizing Unity on Mobiles

Editor's Notes