Unity Performance Tips - Guia de boas práticas

Prévia do material em texto

Unity iPhone dev tips
The most important things to consider are your drawcalls. For example, an iPhone 3G really starts doing funky things over 25-30 drawcalls.
You could reduce your physics Solver Iteration count (from Edit> Project Settings > Physics) and use interpolation.
Try avoding instantiating / destroying objects. In some cases, implementing a GameObject pool might improve performance drastically.
Try to stay away from comparing strings and never use GameObject.Find .
Try to use Switch statements instead of many if / if else nested statements.
I also try to use extremely simple shaders. I usually blend all my external lightmaps and any other maps into the diffuse one and use a Texture Only mini-shader.
You should also try to stay away from using alpha-testing shaders if you're planning to release for the ipad. Due to it's high resolution and really boring hardware if has quite a few fill-rate related problems.
-----------------------------------------------------------------
	Use vertex lit shaders instead of vertex colored on anything that doesn't fade
Avoid large amounts of blended pixels: 2 particles close to cam is worst than 25 particles far away.
Make motion framerate indipendent:
position += velocity * time;
Avoid anything thats non diffuse when possible
Skybox shader is your friend
Avoid clear on camera if the background hits every pixel
(Design) Many smaller scenes > 1 long loading scene
Use UnloadUnusedAssets()
Use very few cameras / lights
Batch draw sprites
Triangle limit is ~ 15k
Be smart with LOD's if you can afford the ram.
 
2------------------------------------------------- 
-Objects with a collider but no RigidBody are considered static. 
Moving these is expensive, so if you’re creating them with code, add the collider and physics material (to the collider) after positioning.
-Hide sprites you’re not using. 
Make a reference to them and set them active = false; They won’t be drawn when offscreen anyway, but something has to determine whether or not they’re visible and chances are you know best, especially when one sprite may be fully hidden behind another and is still drawn.
 -Resize your sprite’s Quad (the sprite itself) rather than its transform. 
If you have say a sprite component on a GameObject, then resize the GameObject’s transform, you’re going to break batching on that sprite. Instead consider the next point. With SM2 for example, you’d just set the Sprite/PackedSprite’s “Width” and “Height” properties in the inspector.
-Do you really need to recreate your GUI for each level? 
You can hide it and have it persist when loading different scenes, reducing loading time.
 -GameObject.Instantiate() is slow! 
One common technique (which proved absolutely vital in Truck Toss) is to create a pool of objects during loading. E.g. 4 of each enemy type. When an object’s no longer needed, disable it and shove it back in the pool instead of recreating it. So you’d have a function along the lines of MakePrefab(“path/to/prefab”); which will only only call Resources.Load() provided there are none in the pool.
-Resources.Load() is even slower! 
This function does not cache, and involves reading from the device’s HD or equivalent. Ideally you want a hybrid pool system if you’re doing a lot of loading\unloading. I.e. your standard pool system which preloads objects,  but when the instantiate function is called, it keeps a different copy in a different list. Whenever instantiate’s called and there aren’t enough in the pool but there’s a copy in the spare list, Instantiate from that rather than doing a Resources.Load fresh again.  This is a balancing act of memory use and processor use, so target it for your device.
 -GameObject.Find() and GetCompoenent().. 
…are slow (You saw that one coming, right?). If you’re going to be using an object or component repeatedly, then it makes sense to create a reference to it in a local variable rather than looking it up repeatedly.
-Reflective functions can be noticeably slower. 
Reflection is the ability for a language\code to look within itself and get method names\types\scope etc and potentially alter them. I.e. calling a function by string name, or using delegates. Try to avoid this kinda of behaviour for performance critical code.
-Set your BG music to decompress on load. 
Anything you’ll be using a lot should probably be decompressed on load rather than streaming from the disk (which is slow and can be especially troublesome on Android.) This is another tradeoff situation however, given that decompression can take time and memory. Balance it!
 -Force to mono? 
Yes yes! Unless you really want stereo and you’ve got some bitchin’ music or sound effects, you’ll save yourself some space on this one. Remember the phone has a mono speaker
-Unity’s UI system is slow. 
Where possible try to use a plugin or sprite package that renders to meshes in 3D space.
-OnGUI is slow! 
Even in a blank scene you can see it spike. Try to have no more than one of these in your code, and centralise branches out from it. It’s fairly easily done.
-Disable the accelerometer! 
In older Unities, that was done via #define kaccelerometer_frequency 0 in the AppControler class via XCode. Nowadays you can disable it from within Unity itself, and can free up 2-3 FPS.
-Strip things down! 
When your game’s running nice and stable, switch compatibility to the .NET 2.0 subset, Stripping Level to micro mscorlib and Script Call Optimisation to Fast but no Exceptions. This will generate a smaller binary with less redundant code and debug symbols. I successfully navigated that one without a stripper reference. Jugs.