Верстка інтерфейсів ігор в Unity UI (uGUI)
Ви відкриваєте інвентар на мобільному пристрої, і FPS падає на 15%. Frame Debugger показує 214 draw calls для одного екрана. Знайома ситуація? Ми стикаємося з цим регулярно і виправляємо за тиждень. Unity UI (uGUI) — потужна система, але її продуктивність закладається на етапі архітектури Canvas, а не в кількості елементів. Ми маємо понад 5 років досвіду та 50+ успішних проєктів — від інді до AAA. Розповімо, як уникнути типових помилок.
Unity UI Optimization Guide допомагає зрозуміти базові принципи: Canvas збирає UI-елементи в batch, якщо однаковий матеріал і одна текстура з Sprite Atlas.
Чому uGUI може гальмувати?
Canvas збирає UI-елементи в batch — групу з одним draw call. Умова батчингу: однаковий матеріал, одна текстура (Sprite Atlas), без перекриттів з чужорідними елементами. Руйнують батчинг три речі:
- Змішування текстур. Іконка з Атласу A, кнопка з Атласу B, текст через TextMeshPro — кожне перемикання текстури дає новий draw call. Рішення: всі візуальні елементи одного екрана в один Sprite Atlas. TextMeshPro-тексти — окремий batch, але хоча б один.
- Вкладені Mask. Кожен Mask додає 2 stencil-проходи та розриває batch ззовні та всередині. Для статичних елементів з обрізаними кутами простіше намалювати текстуру з потрібною формою, ніж ставити Mask.
- Неправильний порядок Sibling Index. Якщо Image A і B перекриваються та з одного атласу, batch все одно може розірватися через z-порядок. Unity batches працюють лише якщо немає перекриттів між елементами з різних атласів.
Діагностика: Frame Debugger → Enable → шукаємо секцію UI. Оптимізований UI з одним атласом працює в 3 рази швидше, ніж з розрізненими текстурами. Хороша цифра для 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% часу рендерингу, що дозволяє заощадити до $2000 на місяць на хмарних ресурсах за рахунок зменшення навантаження на GPU. Гарантуємо аналогічний підхід для вашого 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 активних об'єктів замість сотень. Virtual Scroll зменшує споживання пам'яті в 5 разів порівняно зі звичайним ScrollView.
Як налаштувати 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.
Процес верстки
Кроки з оптимізації UI
- Аналіз Frame Debugger — виявлення точок зростання.
- Упаковка всіх текстур екрана в один Sprite Atlas.
- Налаштування Canvas Scaler під платформу.
- Заміна TextMeshPro Outline на SDF Outline.
- Впровадження віртуального скролу для списків.
- Тестування на кількох роздільних здатностях та профілювання.
Починаємо з отримання Figma-макетів з розмірами, відступами та правилами адаптації. Визначаємо структуру Canvas та атласів. Верстаємо базовий layout на RectTransform, підключаємо шрифти та текстури. Налаштовуємо EventSystem та навігацію для геймпада/клавіатури. Тестуємо на кількох роздільних здатностях через Game View. Профілюємо Frame Debugger на предмет overdraw та брейків батчингу.
| Сроки | Орієнтовні терміни |
|---|---|
| 1–3 простих екрани без анімацій | 2–5 днів |
| Повний UI-комплект інді-проєкту (10–15 екранів) | 3–6 тижнів |
| Складні екрани з virtual scroll, drag & drop | 1–3 тижні за систему |
| Мультиплатформна адаптація існуючого UI | 1–4 тижні |
Вартість розраховується індивідуально після аналізу Figma-макетів та технічних вимог. Зв'яжіться з нами для попередньої оцінки. Отримайте консультацію з оптимізації вашого UI.
| Стратегія батчингу | Draw calls | Складність впровадження |
|---|---|---|
| Без оптимізації (розрізнені атласи) | 100+ | Низька |
| Один атлас на екран | 15–25 | Середня |
| Virtual Scroll + один атлас | 5–15 | Висока |
Досвід показав: правильна архітектура Canvas та атласів окупається на етапі оптимізації. Ми гарантуємо результат — зниження draw calls до 5–15 на HUD без втрати візуальної якості.