🎮 UnityDocs

El Profiler: mide, no adivines

La herramienta para saber en qué se va el rendimiento de tu juego. Cómo leer el Profiler, el concepto de frame budget, y por qué optimizar sin medir es perder el tiempo.

📄 ArtículoAvanzado✅ RevisadoUnity 6.0 LTSActualizado 2026-07-15
DificultadConceptual Código Matemáticas
Tiempo📖 Lectura 8 min · ⌨️ Práctica 25 min

La regla de oro#

Antes de optimizar, mide. El error más caro en rendimiento es optimizar a ciegas: pasar horas mejorando algo que no era el problema. Casi siempre el cuello de botella no es lo que crees. El Profiler te dice exactamente dónde se va el tiempo.

Frame budget: tu presupuesto por fotograma#

Cada fotograma tiene un tiempo máximo. Si lo pasas, los FPS caen:

ObjetivoTiempo por fotograma
30 FPS33,3 ms
60 FPS16,6 ms
120 FPS8,3 ms

Optimizar consiste en meter todo el trabajo (lógica + física + render) dentro de ese presupuesto. El Profiler te muestra cuánto se lleva cada sistema.

Abrir y leer el Profiler#

Window → Analysis → Profiler. Verás varias pistas (CPU, Rendering, Memory, Physics...). Lo esencial:

  • CPU Usage: el gráfico principal. Cada color es un sistema (scripts, física, render, UI). Busca los picos.
  • Selecciona un fotograma pico y abajo, en modo Timeline o Hierarchy, ves qué método concreto se lo come.
  • GC Alloc: cuánta memoria asigna cada frame. Idealmente, en el bucle de juego, cerca de 0. Asignaciones por frame = futuros tirones del recolector.
Perfila en una build, no solo en el editor

El editor añade su propia carga y distorsiona las medidas. Para datos fiables, haz una Development Build con Autoconnect Profiler y perfila el juego real, mejor aún en el dispositivo objetivo (ese móvil concreto), no en tu PC.

Marcar tu propio código#

Para medir un bloque tuyo con precisión, usa un ProfilerMarker: aparecerá con su nombre en el Profiler.

C#
using Unity.Profiling;
using UnityEngine;

public class IA : MonoBehaviour
{
    static readonly ProfilerMarker s_marcador = new ProfilerMarker("IA.Pensar");

    void Update()
    {
        s_marcador.Begin();
        Pensar();          // tu código a medir
        s_marcador.End();
    }

    void Pensar() { /* ... */ }
}

Herramientas hermanas#

  • Frame Debugger (Window → Analysis → Frame Debugger): reproduce el render paso a paso para ver cuántos draw calls haces y por qué. Clave para optimizar gráficos.
  • Memory Profiler (paquete): analiza la memoria en detalle, útil para fugas y para móvil.

Un método de trabajo#

🛠️ Decisión de ingeniería
  • 1. Reproduce el problema (¿cuándo baja de FPS?)
  • 2. Abre el Profiler y captura ese momento
  • 3. Encuentra el sistema culpable (CPU scripts, física, render, GC…)
  • 4. Baja al método concreto que se lo come
  • 5. Optimiza solo eso y vuelve a medir para confirmar la mejora

Errores frecuentes#

  • Optimizar por intuición sin abrir el Profiler.
  • Perfilar solo en el editor y sacar conclusiones falsas.
  • Ignorar la columna GC Alloc (la causa oculta de muchos tirones).
  • Micro-optimizar código que apenas aparece en el Profiler mientras el verdadero coste está en el render o la física.

Ponte a prueba#

📝 Pon a prueba lo aprendido

Resumen#

El Profiler (Window → Analysis → Profiler) te dice en qué se va cada fotograma. Trabaja con un frame budget (16,6 ms para 60 FPS), perfila en una build en el dispositivo objetivo, vigila la columna GC Alloc, y usa ProfilerMarker para medir tu código. Mide, optimiza solo el cuello de botella real, y vuelve a medir.

Fuentes y para profundizar