Este documento proporciona consejos sobre optimización de rendimiento en Unity. Recomienda apuntar a 60 FPS en dispositivos móviles medianos, limitar el número de draw calls, vertices y texturas cargadas. Además, ofrece consejos sobre usar profiler, batching de materiales, pooling de objetos, evitar Find y mejorar el rendimiento de scripts y UI.

3.  Profiler
 Samples
 Detailed RAM
 Gamebench
 Scripts
 Caches
 Resources Folder
 Pools
 Tips
 Materiales
 Batching
 Alpha
 Atlas
 Shared vs Instance
 CombineChildren
 Texture Formats
 UI (4.6)
 Tips

5.  Target 60 FPS gama media
 ~ 40 drawcalls, ~50k verts
 ~ 120 tracks runtime
 150 texturas en total
 70 cargadas a la vez
 ~250 animaciones
 ~550 meshes

7.  Profiler.BeginSample(“DoSomething”);
DoSomething();
Profiler.EndSample();
 Profiler.GetRuntimeMemorySize(t)

8.  Memory -> Simple/Detailed ->Take Sample

11.  Acceder al transform es lo mismo que
acceder a GetComponent<Transform>()
 Acceder al GetComponent en el Update está
desaconsejado
 Cachear en el awake/start
private Transform myTransform;
void Awake() {
myTransform = transform;
}
void Update() {
myTransform.Translate(0, 0, 5);
}

12.  Jamás usar GameObject.Find.Aparte de ser
lentísimo, el nombre puede cambiar y tu
código dejará de funcionar.
GameObject.Find ("MenuObject").transform.
GetChild(2).transform.GetChild (1).transform;
 Referencias en la propia clase (public). Si
necesitas muchas referencias, hacer un
CustomInspector

14.  Muy cómodo hacer Resources.Load pero
ojocuidao con los tiempos de carga. Evitarlo
dentro de lo posible.
 Uso aceptable: elementos que no se utilizan
en el juego inicialmente, pero que más tarde
puede que si (cosméticos, habitaciones para
un sistema aleatorio, etc). Si se referenciasen
estos elementos se cargarían en memoria
siempre, haciendolo desde Resources no.

15.  Instantiate / Destroy son operaciones MUY
costosas.
 En el pool podemos tener pre-creados una lista
de objetos a usar e ir activando/desactivando y
reseteando según necesitemos.
 Dos posibilidades. Crear todos los objetos en el
Awake o tenerlos ya creados en la Scene.
 Dato curioso. Cargar una escena con un Pool y X
elementos tarda menos que cargar una escena
con un Pool que en su awake cree X elementos

16.  Foreach genera basura, no usarlo nunca.
 Las clases ArrayList y Array son muy lentas en
Unity. Mucho más rapido usar List o un array
simple.
 ¿Seguro que necesitas llamar al método para
actualizar la distancia cada frame? Optimizar
las llamadas recurrentes.

18. DYNAMIC
 Se aplica automáticamente
(si se cumplen requisitos)
 Menos de 900 vertices.
300 si el shader usaVertex
Position, Normal y UV
180 si además se usa UV1 y
Tangent.
 Misma escala
STATIC
 Se activa en
QualitySettings
 Hay que marcar los objetos
como Static, no se podrán
mover durante todo su
lifetime.
 Mejor performance que
Dynamic batching
 Unity Pro
 Gran ahorro en el número de draw calls = mejor performance
 Batching solo funciona en objetos con el mismo material -> atlas (ojo con instancias)

21.  MultiplesAlpha en pantalla multiplican
drawcalls
 Usar cutout en la medida de lo posible (peor
calidad, mejor rendimiento)
 Unificar todos los efectos con Alpha del juego
en un Atlas para hacer batching
 No soportado por texturas ETC (tampoco el
cutout)

22.  Agrupando texturas en un Atlas conseguimos
aumentar las posibilidades de Batching
 Agrupar elementos relacionados (por nivel,
por obstaculo / decoracion, etc).
 TexturePacker de Unity funciona de forma
automática, pero tiene algunos problemas
 TexturePackerPro > all

24.  Si accedemos al material desde script
(renderer.material) estaremos creando una
Instancia del material
 Las instancias no hacen batching, por lo que
generarán nuevos draw calls
 Usar siempre que se pueda el sharedMaterial
(renderer.sharedMaterial). Esto cambiará los
parámetros en todos los objetos y no creará
instancias del material.

25.  Utilidad de Unity para combinar geometría al
vuelo
 Se puede usar on demand en runtime o hacerlo
desde el editor y tener las meshes preparadas
 La mesh será gigante, no se hará culling
eficientemente y ocupará más espacio en
memoria
 Teniendo todos los elementos combinados solo
se hará un draw call por material, aunque haya
diferentes escalas y demás dado que contará
como una sola mesh.

26.  Mejor compresión para Android -> ETC 4 bits
 Soportado en el 99.9% de los moviles (OpenGL 2.0)
 No soporta Alpha
 ETC2 soporta Alpha, pero solo está asegurado en OpenGL 3.0
 Mejor compresión para iOS -> PVRTC 4 bits
 Soportado en todos los dispositivos
 Soporta Alpha
 Texturas cuadradas o las deformará
 16 bits / 32 (Truecolor)
 Si necesitamos Alpha en Android o nada de perdida de calidad
sobre la textura original
 Gran impacto en memoria (1024x1024TC + mipmaps -> 5.3MB)

28.  TextMeshPro >Text (65$). Mejor calidad con
escalados, mejor implementación de outline /
sombras / efectos, más opciones con el texto
 No actualizar cada frame la UI
 Separar en diferentesCanvas en caso de que
algun panel tenga animaciones.Al mover /
animar alguna parte, hace draw y batch de
todo el canvas al completo

29. guillermo.andrades@cremagames.com
@xYaW
@CremaGames