¿Cómo funciona?

El secreto de la eficiencia de WebAP radica en su modularidad y enfoque matemático. El plugin no intenta "adivinar" la causa de los retrasos o reducir ciegamente la resolución de la pantalla.

Todo el sistema opera como un pipeline finamente ajustado que consta de tres capas principales: Tracker, Indexer, y Scalers.

Pipeline de Decisión

La arquitectura del plugin separa estrictamente la recopilación de datos, la toma de decisiones y la ejecución.

1. Tracker (Observador)

Cada fotograma, el Tracker recopila datos en bruto sobre el tiempo del fotograma y el tiempo puro de la CPU. Calcula una Media Móvil Exponencial (Exponential Moving Average) para suavizar los picos aleatorios causados por el Garbage Collector (GC) o la carga de assets.
El Tracker no toma decisiones; simplemente responde a dos preguntas:

• "¿Estamos manteniendo el Target Min FPS?"
• "¿Qué subsistema específico se está retrasando actualmente (Cuello de Botella / Bottleneck)?"

2. Indexer (Cerebro)

El Indexer recibe los datos del Tracker y decide cómo proceder. Es el árbitro del sistema.
Si los FPS caen, el Indexer:

1. Verifica si el sistema está en Cooldown.
2. Evalúa el Sistema de Penalización Anti Yo-Yo (consulta Penalización Anti Yo-Yo para más detalles).
3. Calcula el costo de todos los Scalers disponibles.
4. Emite un comando al Scaler que producirá el máximo rendimiento con el mínimo daño visual.

3. Scalers (Ejecutores)

Los Scalers reciben comandos del Indexer y realizan el trabajo pesado. Se comunican con la API de Unity y aplican la configuración requerida (reducir resolución, ocultar capas, desactivar el anti-aliasing).

Cuellos de Botella (Bottlenecks): Encontrando Limitaciones Sin Termómetros

¿Cómo entiende WebAP exactamente qué está fallando al manejar la carga sin acceso a los sensores del dispositivo? Analizamos las proporciones de tiempo dentro del propio motor.

• Cuello de Botella de CPU: El Tracker divide el tiempo puro del hilo principal del procesador entre el tiempo total del fotograma. Si esta proporción supera el 85%, la conclusión es obvia. El fotograma está limitado por cálculos de lógica o física. Disminuir la resolución de la pantalla o desactivar las sombras es inútil.
• Cuello de Botella de GPU: Si los FPS generales están por debajo de lo normal, pero la cuota de CPU es inferior al 85%, indica que el procesador está inactivo. La tarjeta de video no logra renderizar el fotograma a tiempo (cuello de botella de Fillrate, shaders complejos o Overdraw).
• Tasa de Fotogramas Objetivo (Target Frame Rate): Si el tiempo de espera promedio de VSync es mayor que cero, significa que tanto el procesador como la tarjeta de video están terminando el renderizado más rápido que la tasa de refresco del monitor. El sistema opera con Margen de Rendimiento (Performance Headroom), y el Indexer puede aumentar suavemente la calidad gráfica.

Zero-GC: Rendimiento Primero

Un plugin diseñado para salvar a un juego del lag no tiene derecho a tener lag él mismo. El núcleo de WebAP está diseñado teniendo en mente una estricta economía de memoria (Zero-GC) a lo largo del Hot Path.

• Búferes Circulares O(1): En lugar de List<float> y bucles pesados en Update, el Tracker utiliza matrices de tamaño fijo (Ring Buffers). El cálculo de FPS promedio se ejecuta en tiempo constante.
• Cero Asignaciones en Update: El núcleo no contiene llamadas new, boxing o lambdas. Simplemente no hay nada que limpiar para el Garbage Collector (GC).
• Caché de Delegados: Incluso para tareas complejas (interceptar clics en WebScaledPhysics2DRaycaster), abandonamos la lenta reflexión (MethodInfo.Invoke) en favor de rápidos delegados compilados.

Invisibilidad

Gracias a estas optimizaciones, la sobrecarga para todo el pipeline de WebAP es mínima. Tu procesador ni siquiera notará que está siendo monitoreado.