Practical Guide for Optimizing Unity on Mobiles

COPYRIGHT 2014 @ UNITY TECHNOLOGIES

PRACTICAL GUIDE TO OPTIMIZATION ON MOBILES

Valentin SimonovField Engineer @ Unity TechnologiesE-mail: [email protected]: simonov.valentin

Comment: additional comments were added to slides.Content shown in live demos is obviously missing.


Valentin SimonovField 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: [email protected]: 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 issuethey run around in panic, while senior developers seem to know what they are doing.


1. Set the target device2. Test and measure3. Know your platform4. Know your tools5. Profile on device6. CPU7. GPU8. Memory9. 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 resolutionyou’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 complexgeometry 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 Storewhich 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 apphttps://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Performance/Performance.html

• Squeezing performance out of your unity gear vr gamehttps://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 trickshttp://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

Software

Transcript of Practical Guide for Optimizing Unity on Mobiles