Como Funciona

O segredo para a eficiência do WebAP reside na sua modularidade e abordagem matemática. O plugin não tenta "adivinhar" a causa dos atrasos ou reduzir cegamente a resolução da tela.

Todo o sistema opera como um pipeline rigorosamente ajustado consistindo em três camadas principais: Tracker, Indexer e Scalers.

Pipeline de Decisão

A arquitetura do plugin separa estritamente a coleta de dados, a tomada de decisão e a execução.

1. Tracker (Observador)

Em cada frame, o Tracker recolhe dados brutos sobre o tempo do frame e o tempo puro do CPU. Calcula uma Média Móvel Exponencial (Exponential Moving Average) para suavizar picos aleatórios causados pelo Garbage Collector (GC) ou pelo carregamento de assets.
O Tracker não toma decisões; apenas responde a duas perguntas:

• "Estamos a acompanhar o Target Min FPS?"
• "Qual subsistema específico está atualmente atrasado (Gargalo/Bottleneck)?"

2. Indexer (Cérebro)

O Indexer recebe os dados do Tracker e decide como prosseguir. Ele é o árbitro do sistema.
Se os FPS caírem, o Indexer:

1. Verifica se o sistema está em Cooldown.
2. Avalia o Anti Yo-Yo Penalty System (ver Penalidade Anti Yo-Yo para detalhes).
3. Calcula o custo de todos os Scalers disponíveis.
4. Emite um comando para o Scaler que produzirá o máximo de desempenho com o mínimo dano visual.

3. Scalers (Executores)

Os Scalers recebem comandos do Indexer e realizam o trabalho pesado. Eles interagem com a API da Unity e aplicam as configurações necessárias (reduzir resolução, ocultar camadas, desativar anti-aliasing).

Gargalos (Bottlenecks): Encontrando Limitações Sem Termômetros

Como o WebAP entende exatamente o que está a falhar ao lidar com a carga sem acesso aos sensores do dispositivo? Analisamos as proporções de timing dentro da própria engine.

• CPU Bottleneck: O Tracker divide o tempo puro da thread principal do processador pelo tempo total do frame. Se este rácio exceder 85%, a conclusão é óbvia. O frame está limitado pela lógica ou cálculos físicos. Diminuir a resolução da tela ou desativar sombras é inútil.
• GPU Bottleneck: Se os FPS globais estiverem abaixo do normal, mas a porção da CPU for inferior a 85%, indica que o processador está ocioso. A placa de vídeo está a falhar em renderizar o frame a tempo (gargalo de Fillrate, shaders complexos ou Overdraw).
• Target Frame Rate: Se o tempo médio de espera do VSync for maior que zero, significa que tanto o processador quanto a placa de vídeo estão terminando a renderização mais rapidamente do que a taxa de atualização do monitor. O sistema opera com Performance Headroom, e o Indexer pode aumentar suavemente a qualidade gráfica.

Zero-GC: Performance Primeiro

Um plugin desenhado para salvar um jogo do lag não tem o direito de ter lag ele próprio. O núcleo do WebAP foi concebido tendo em mente uma rigorosa economia de memória (Zero-GC) ao longo do Hot Path.

• Buffers Circulares O(1): Em vez de List<float> e loops pesados no Update, o Tracker utiliza arrays de tamanho fixo (Ring Buffers). O cálculo médio de FPS é executado em tempo constante.
• Zero Alocações no Update: O núcleo não contém chamadas de new, boxing ou lambdas. Simplesmente não há nada para o Garbage Collector (GC) limpar.
• Cache de Delegados: Mesmo para tarefas complexas (interceptando cliques no WebScaledPhysics2DRaycaster), abandonamos a lenta reflexão (MethodInfo.Invoke) em favor de delegados rápidos compilados.

Invisibilidade

Graças a estas otimizações, o overhead para todo o pipeline do WebAP é mínimo. O seu processador não vai sequer notar que está a ser monitorizado.