Как это работает?

Секрет эффективности WebAP кроется в его модульности и математическом подходе. Плагин не пытается "угадать" причину лагов или слепо сбросить разрешение экрана.

Вся система работает как четко отлаженный конвейер, состоящий из трех главных слоев: Tracker, Indexer и Scalers.

Конвейер принятия решений

Архитектура плагина строго разделяет сбор данных, принятие решений и их исполнение.

1. Tracker (Наблюдатель)

Каждый кадр Tracker собирает сырые данные о времени кадра и чистом процессорном времени. Он вычисляет скользящее среднее (Moving Average), чтобы сгладить случайные спайки от Garbage Collector'а или подгрузки ассетов.
Трекер не принимает решений, он лишь отвечает на два вопроса:

• "Успеваем ли мы за Target Min FPS?"
• "Какая именно подсистема сейчас тормозит (Bottleneck)?"

2. Indexer (Мозг)

Indexer принимает данные от Tracker и решает, что с этим делать. Это арбитр системы.
Если FPS падает, Indexer:

1. Проверяет, не находится ли система в Cooldown.
2. Проверяет систему штрафов Anti Yo-Yo (см. подробнее Anti Yo-Yo Penalty).
3. Вычисляет cтоимость всех доступных Scalers.
4. Отдает приказ тому Scaler'у, который даст максимум производительности при минимальном визуальном ущербе.

3. Scalers (Исполнители)

Scalers получают приказ от Indexer и делают грязную работу. Они обращаются к API Unity и применяют нужные настройки (снижают разрешение, отсекают слои, отключают сглаживание).

Bottlenecks: Поиск узких мест без градусников

Как WebAP понимает, что именно не справляется с нагрузкой, не имея доступа к датчикам устройства? Мы анализируем пропорции таймингов внутри самого движка.

• CPU Bottleneck: Трекер делит чистое время работы главного потока процессора на общее время кадра. Если это соотношение превышает 85%, вывод очевиден. Кадр уперся в вычисления логики или физики. Снижать разрешение экрана или отключать тени бесполезно.
• GPU Bottleneck: Если общий FPS ниже нормы, но при этом доля CPU составляет менее 85%, значит процессор простаивает. Видеокарта не успевает отрисовать кадр (упор в Fillrate, сложные шейдеры или Overdraw).
• Target Frame Rate: Если среднее время ожидания VSync больше нуля, значит и процессор, и видеокарта успевают всё отрисовать быстрее частоты обновления монитора. Система работает с запасом мощности, и Indexer может плавно повышать качество графики.

Zero-GC: Производительность прежде всего

Плагин, спасающий игру от лагов, не имеет права лагать сам. Ядро WebAP спроектировано с учетом жесткой экономии памяти (Zero-GC) в горячем цикле выполнения (Hot Path).

• Кольцевые буферы O(1): Вместо List<float> и тяжелых циклов в Update, Трекер использует массивы фиксированного размера (Ring Buffers). Расчет среднего FPS выполняется за константное время.
• Без аллокаций в Update: В ядре нет вызовов new, боксинга или лямбд. Мусоросборщику (Garbage Collector) просто нечего чистить.
• Кэширование делегатов: Даже для сложных задач (перехват кликов в WebScaledPhysics2DRaycaster) мы отказались от медленной рефлексии (MethodInfo.Invoke) в пользу быстрых скомпилированных делегатов.

Незаметность

Благодаря этим оптимизациям накладные расходы на работу всего конвейера WebAP минимальны. Ваш процессор даже не заметит, что за ним следят.