Верстка интерфейсов игр в Unity UI (uGUI)

Верстка интерфейсов игр в Unity UI (uGUI)

Вы открываете инвентарь на мобильном устройстве, и FPS падает на 15%. Frame Debugger показывает 214 draw calls для одного экрана. Знакомая ситуация? Мы сталкиваемся с этим регулярно и исправляем за неделю. Unity UI (uGUI) — мощная система, но её производительность закладывается на этапе архитектуры Canvas, а не в количестве элементов. За 5 лет работы мы оптимизировали UI более чем в 50 проектах — от инди до AAA. Расскажем, как избежать типовых ошибок.

Unity UI Optimization Guide помогает понять базовые принципы: Canvas собирает UI-элементы в batch, если одинаковый материал и одна текстура из Sprite Atlas.

Почему uGUI может тормозить?

Canvas собирает UI-элементы в batch — группу с одним draw call. Условие батчинга: одинаковый материал, одна текстура (Sprite Atlas), без перекрытий с чужеродными элементами. Разрушают батчинг три вещи:

1. Смешение текстур. Иконка из Атласа A, кнопка из Атласа B, текст через TextMeshPro — каждое переключение текстуры даёт новый draw call. Решение: все визуальные элементы одного экрана в один Sprite Atlas. TextMeshPro-тексты — отдельный batch, но хотя бы один.
2. Вложенные Mask. Каждый Mask добавляет 2 stencil-прохода и разрывает батч снаружи и внутри. Для статичных элементов с обрезанными углами проще нарисовать текстуру с нужной формой, чем ставить Mask.
3. Неправильный порядок Sibling Index. Если Image A и B перекрываются и из одного атласа, батч всё равно может разорваться из-за z-порядка. Unity batches работают только если нет перекрытий между элементами из разных атласов.

Диагностика: Frame Debugger → Enable → ищем секцию UI. Хорошая цифра для HUD — 5–15 draw calls. Больше 50 — повод для оптимизации.

Как мы уменьшаем draw calls: кейс из нашей практики

Пришёл проект с жалобой на 15% просадку FPS при открытии инвентаря. Frame Debugger показал 214 draw calls для 48 слотов. Каждый слот — отдельный Prefab с иконкой из PNG (не атлас), TextMeshPro-количеством, фоновой рамкой из другого PNG и Outline-компонентом (генерирует дополнительную mesh).

Решение: упаковали все иконки в два Sprite Atlas (предметы и UI-хром раздельно), заменили TextMeshPro Outline на SDF Outline в материале TMP, добавили Virtual Scroll List (pool-based) для сетки предметов. Итог: 22 draw calls на том же экране. FPS вернулся к норме. Выгода: экономия до 40% времени рендеринга. Гарантируем аналогичный подход для вашего UI.

Что входит в нашу работу по верстке UI

• Аудит текущего UI: Frame Debugger, Profiler, анализ архитектуры Canvas.
• Оптимизация атласов: нарезка, объединение, настройка Fallback Fonts.
• Верстка RectTransform с привязкой якорей для адаптации под разрешения.
• Настройка Canvas Scaler под целевые платформы.
• Реализация виртуального скролла для динамических списков (ScrollView с pool).
• Интеграция анимаций (DoTween, Animator) без потери производительности.
• Документация по UI-архитектуре и стилю кода.
• Обучение команды работе с батчингом и профилированием.

RectTransform: правила, которые спасают от боли

Якоря (Anchors) и Pivot — не одно и то же. Якорь определяет точку привязки к родителю, Pivot — точку вращения и масштабирования элемента. Типичная ошибка: якоря выставлены в левый верхний угол, а элемент должен быть по центру. При смене разрешения элемент уезжает. Правильно: якорь → center/middle, anchored position = (0, 0).

Для адаптации используем Canvas Scaler с Scale With Screen Size. Reference Resolution 1920×1080 и Match = 0.5 — рабочая база. Для мобильных с Match = 0.8–1.0 (в пользу Height) UI не расплывается на узких экранах.

ContentSizeFitter + VerticalLayoutGroup — удобно для динамических списков, но каждое изменение вызывает Layout Rebuild. Для ScrollView с сотнями элементов применяем Virtual Scroll List: держим в памяти только видимые — до 10–15 активных объектов вместо сотен.

Как настроить Canvas Scaler для мобильных устройств?

Для мобильных с разными соотношениями сторон Match лучше поднять до 0.8–1.0 в пользу Height. Иначе на iPhone с 19.5:9 UI расплывается по горизонтали. Мы также настраиваем Reference Resolution под целевое разрешение — обычно 750×1334 (iPhone 6/7/8) с режимом Scale With Screen Size. Подробности — на официальной документации Canvas Scaler.

TextMeshPro: шрифты и производительность

TextMeshPro — стандарт для текста. Использует SDF рендеринг, что даёт чёткость на любом масштабе. Для локализации кириллицы или CJK настройте Fallback Font Asset: основной шрифт для латиницы с прописанным Fallback на нужный язык. TextMeshPro автоматически подгружает недостающие глифы, и текст остаётся в 1-2 draw calls.

Atlas Population Mode: Dynamic добавляет глифы по мере встречи — хорошо для dev, плохо для релиза (микрофризы при первом рендере). Для продакшна используем Static с предварительно заполненным атласом через Font Asset Creator.

Процесс верстки