Адаптація графіки під різні формати екранів (Aspect Ratio)

Сьогодні Unity-проєкт повинен коректно відображатися на 16:9, 18:9, 19.5:9, 4:3 (iPad), 1:1 (складні пристрої) та 21:9 (ультраширокі монітори). Якщо при проектуванні UI використовували лише Canvas Scaler з Screen Match Mode = Match Width Or Height і magic number 0.5 — на iPad'і UI поїде, на 21:9 — пусті смуги або обрізані елементи.

Ми, команда геймдев-інженерів з 10-річним досвідом (понад 50 проєктів з адаптації графіки), забезпечуємо повну адаптацію: від аудиту UI до впровадження Aspect Ratio Manager. Наша робота гарантує коректне відображення на будь-яких пристроях — від ультрашироких моніторів до мобільних з Dynamic Island. Зв'яжіться з нами для оцінки вашого проєкту.

Чому Canvas Scaler не вирішує проблему?

Canvas з фіксованими розмірами. Кнопка, закріплена по Anchor до правого нижнього кута, при переході з 16:9 на 21:9 спливає за екран — тому що її позиція задана в абсолютних пікселях, а не через Anchors правильно. Це сигнал, що UI спочатку верстався без урахування варіативності співвідношень.

Як працювати з Safe Area на мобільних пристроях?

Safe Area на мобільних пристроях. На iPhone з Dynamic Island і на Android-пристроях з punch-hole камерою верхній кут екрана фізично зайнятий. Якщо статус-бар та ігрові кнопки не враховують Screen.safeArea — UI перекривається вирізом камери. Unity сам не застосовує Safe Area до Canvas — це потрібно робити через скрипт, який зчитує Screen.safeArea і оновлює RectTransform кореневого елемента. Згідно з документацією Unity, Safe Area необхідно обробляти вручну: Safe Area.

Адаптація ортографічної камери під різні співвідношення

Ортографічна ігрова камера з фіксованим Orthographic Size. У 2D-грі з фіксованим Camera.orthographicSize = 5 при переході з 16:9 на 4:3 гравець бачить менше світу по горизонталі. Для платформера це означає, що персонаж не встигає бачити перешкоди. Рішення: розраховуємо Orthographic Size динамічно через цільовий width: orthographicSize = targetWidth / (2 * Camera.aspect).

Як вибрати стратегію: letterbox, pillarbox чи crop?

Три стратегії заповнення неспівпадаючого співвідношення. Для кожної гри — своя. Файтинг на 21:9: pillarbox (смуги з боків) виглядає дивно — краще crop з розширенням арени. Стратегія на iPad: letterbox небажаний — краще показувати більше карти. Вибір стратегії — дизайн-рішення, але його потрібно прийняти явно і реалізувати технічно.

1. Визначте жанр і цільові пристрої.
2. Виберіть primary aspect ratio (під нього проектуєте UI).
3. Для інших співвідношень вирішіть: letterbox, pillarbox чи crop.
4. Реалізуйте через Camera Viewport Rect або окремі камери.

Практичний підхід: Camera Viewport Rect і Multiple Canvas

Camera Viewport Rect. Для Letterbox/Pillarbox керуємо camera.rect залежно від поточного aspect ratio. Для 21:9 на 16:9-контенті: обчислюємо потрібний Viewport Rect так, щоб ігрова область центрувалася, а смуги малювалися через окрему камеру з Solid Color background.

Multiple Canvas і Reference Resolution. Розділяємо UI на кілька Canvas з різними налаштуваннями масштабування. HUD (здоров'я, міні-карта) — Canvas Scaler Scale With Screen Size, Match = 1 (Match Height). Діалоги та меню — Match = 0 (Match Width). Це дає більш передбачуваний масштаб різних категорій елементів.

З нашої практики: адаптація мобільної стратегії

Мобільна стратегія, реліз на iOS та Android. Розробка велася під iPhone 14 (19.5:9). При тестуванні на iPad Pro (4:3) виявилося: нижня панель ресурсів обрізана знизу, карта світу відображає лише 60% потрібної області, кнопка «Атака» перекрита Safe Area. Рішення зайняло 5 днів: написали AspectRatioManager з трьома профілями (narrow: < 1.6, standard: 1.6–2.0, wide: > 2.0), під кожен профіль — окремі Anchor Preset'и для критичних UI-елементів, плюс Safe Area Controller. Фінальний тест на 7 пристроях з різними співвідношеннями — всі екрани коректні.

public class AspectRatioManager : MonoBehaviour {
    public enum AspectProfile { Narrow, Standard, Wide }
    private AspectProfile currentProfile;

    void Update() {
        float ratio = (float)Screen.width / Screen.height;
        if (ratio < 1.6f) currentProfile = AspectProfile.Narrow;
        else if (ratio <= 2.0f) currentProfile = AspectProfile.Standard;
        else currentProfile = AspectProfile.Wide;
        ApplyProfile();
    }

    void ApplyProfile() {
        // Apply anchor presets and camera rect based on profile
    }
}

Шейдер-рівень адаптації

Shader-рівень адаптації. Для фонових зображень (завантажувальний екран, головне меню) — шейдер з параметром Tiling, який адаптує UVs під поточний aspect ratio. Зображення не тягнеться і не обрізається, а масштабується з розумним кадруванням (аналог CSS object-fit: cover).

Тестування на реальних пристроях

Використовуємо Unity Device Simulator (Window → General → Device Simulator) для попередньої перевірки. Але фінальне тестування — тільки на реальних пристроях: iOS Safe Area в симуляторі розраховується інакше, ніж на фізичному iPhone.

Матриця тестування:

Що входить в роботу

• Аудит поточного UI зі звітом по проблемах (2–3 дні)
• Розробка Aspect Ratio Manager з профілями під різні співвідношення
• Налаштування Safe Area Controller для мобільних пристроїв
• Оптимізація Anchor Preset'ів та Multiple Canvas
• Реалізація кастомних шейдерів для фонів
• Тестування на 7+ реальних пристроях
• Документація та рекомендації по підтримці

Орієнтовні терміни

Вартість розраховується індивідуально залежно від складності проєкту. Економія часу на доопрацювання після релізу може досягати 40% бюджету. Замовте аудит вашого UI або отримайте консультацію — ми оцінимо проєкт безкоштовно.

Типові проблеми продуктивності ігор

Проект запускається на топових девайсах розробника без питань. На mid-range Android п'ятирічної давності — 20 fps і перегрів через 5 хвилин. На iPhone 11 — стабільні 60, але на iPhone XR — просідання у важких сценах. Ми стикаємося з цим кожен день. Оптимізація — не «потім», а архітектурне рішення з першого коміту. За 8 років роботи ми провели оптимізацію більш ніж для 50 ігор — від гіперказуалки до AAA на консолях. Гарантуємо: після нашого аудиту ви отримаєте не просто список проблем, а конкретний план з вимірними цілями та термінами. Замовте аудит продуктивності — оцінимо ваш проект за 3 дні і покажемо, як знизити draw calls на 40% без втрати якості.

Як профілювати продуктивність ігор?

Перш ніж оптимізувати — виміряти. Оптимізація без профілювання — вгадування.

Профілюйте на цільовому залізі, а не в редакторі. Editor додає оверхед — цифри з Play Mode не репрезентативні. Розділяйте GPU та CPU bottleneck: на CPU багато draw calls або важка логіка, на GPU — складні шейдери або overdraw. Документація Unity: профілювання на пристрої — обов’язковий крок для мобільних ігор. Типовий час профілювання одного сценарію — 5–8 годин, включаючи збір метрик на 3–5 пристроях різних поколінь. Аналізуємо 10–15 ключових ігрових сценаріїв за 3 робочих дні.

Як зменшити кількість draw calls?

Draw call — команда CPU до GPU «намалюй це». Кожен виклик має overhead незалежно від складності геометрії. На мобільних 200–300 draw calls за кадр — межа. Мета: мінімізувати їх кількість, об’єднуючи геометрію з однаковим матеріалом.

Static Batching об’єднує нерухомі меші при збірці. Вимога: прапорець Static на об’єкті та однаковий матеріал. Ефективний для статичного оточення, але збільшує споживання пам’яті — об’єднаний меш зберігається окремо. Static Batching може знизити draw calls в 3 рази, але збільшує пам’ять на 20% порівняно з іншими методами. У сценах з тисячами статичних об’єктів слідкуйте за пам’яттю через Memory Profiler.

Dynamic Batching об’єднує меші в рантаймі з жорсткими обмеженнями: менше 900 вертексних атрибутів на меш, однаковий матеріал та масштаб. На практиці ефективний лише для дрібних об’єктів (партикли, UI). В URP за замовчуванням вимкнений — його витіснив SRP Batcher.

SRP Batcher — не класичний батчінг, а оптимізація CPU-overhead при підготовці draw calls. Замість того щоб кожен кадр заново завантажувати uniform-дані шейдера, SRP Batcher кешує їх у GPU-пам’яті та оновлює лише ті, що змінилися. Draw calls залишаються колишніми за кількістю, але кожен займає менше часу CPU — SRP Batcher дає приріст в 2–3 рази по CPU-часу рендеру. Вимога: шейдер має бути сумісний з SRP Batcher (декларувати per-object властивості в UnityPerDraw CBUFFER). Стандартні URP Lit/Unlit шейдери сумісні. Кастомні — перевіряємо в Inspector матеріалу: SRP Batcher compatible: Yes/No. Для ввімкнення переконайтеся, що в URP Asset опція SRP Batcher активна, а для кастомних шейдерів використовуйте макрос UNITY_INSTANCING_BUFFER і декларуйте per-object властивості в блоці CBUFFER_START(UnityPerDraw). Після ввімкнення в Profiler має знизитися час RenderLoop.Draw на CPU.

GPU Instancing — для множини копій одного меша з одним матеріалом (дерева, трава, NPC). Відправляє один draw call з масивом per-instance даних. Вмикається на матеріалі: Enable GPU Instancing. Обмеження: всі інстанси в одному batch повинні мати однаковий матеріал і меш. Graphics.DrawMeshInstanced / Graphics.DrawMeshInstancedIndirect — для процедурного рендерингу без GameObject overhead.

Вибір методу залежить від сценарію: Static Batching підходить для статичного оточення, SRP Batcher виграє в проектах з множиною унікальних матеріалів, GPU Instancing незамінний для масових об’єктів (ліс, натовп), Dynamic Batching — лише для дрібних та рідкісних випадків. На практиці ми комбінуємо все, починаючи з профілювання.

Детальніше про технологію — на Wikipedia.

Чому оптимізація пам'яті критична для мобільних ігор?

Мобільні платформи — жорсткі обмеження по RAM. iOS вбиває додаток при перевищенні пам’яті без попередження (memory pressure kill). Android — аналогічно, але з onLowMemory callback. Цільові бюджети: iOS — <1 GB для сучасних пристроїв, <512 MB для підтримки iPhone 8/X; Android — <800 MB для широкої сумісності (ОС займає 400–600 MB). Типова економія після нашої оптимізації — 30–50% оперативної пам’яті при збереженні якості. Середня економія бюджету на етапі оптимізації — від $3,000 до $8,000 залежно від складності проекту, що підтверджується нашими кейсами.

Addressables та Asset Bundles: як не перевищити бюджет

Завантажувати все одразу при старті — неприйнятно для великих проектів. Addressables (надбудова над Asset Bundles) — система адресованого асинхронного завантаження асетів. Явне вивантаження: Addressables.ReleaseInstance / Addressables.Release. Addressables не вивантажують асети автоматично при знищенні об’єкта. Типова помилка: Addressables.InstantiateAsync у циклі без Release — пам’ять росте до крашу. Reference counting: асет вивантажується тільки коли всі його handles звільнені. Архітектурний патерн: сервіс/менеджер тримає handle завантаженого асета, звільняє при переході між сценами.

Groups та Bundle Strategy: групуємо асети за логікою завантаження. Наприклад, всі асети одного рівня — в один bundle, шарені (UI, шрифти) — в окрему групу з Prevent Updates. Така стратегія економить до 30% пам’яті.

Texture Memory: звідки береться 70% займаного об'єму

Текстури — основний споживач пам’яті. Аналіз через Memory Profiler: вкладка All Of Memory → Texture2D — одразу видно список найважчих текстур. На практиці ми знаходимо текстури з завищеним Max Size (4096 для мобільної іконки — типова помилка). Заходи: Mipmap для 3D-текстур (ввімкнути), для UI (вимкнути); Streaming Mipmaps для open world — завантажує mip-рівні по мірі наближення камери. Красовська проблема: текстури, на які посилаються невикористовувані Materials, залишаються в пам’яті — Memory Profiler покаже reference chain. Видаляйте зайві матеріали. Після заміни всіх текстур формату RGBA32 на ASTC 6×6 на Android економія досягає 60% без втрати якості.

GC Allocations: як усунути фризи в Hot Path

C# garbage collector в Unity — stop-the-world. Якщо за кадр алоційовано багато heap-пам’яті, GC-пауза викликає видимий фриз. Ціль: нульові алокації в hot path (Update, FixedUpdate, рендер). Типові джерела: string конкатенація в Update (замінюємо на StringBuilder), LINQ в hot path (ручні цикли з предалоційованими списками), GetComponent<T>() кожен кадр (кешуємо в Awake/Start), boxing value types при передачі в object параметри. Після профілювання за допомогою Unity Profiler ми знижуємо алокації в hot path на 95% — фризи зникають.

Як відсікти зайві 40% draw calls? LOD та Culling

LOD Group — перемикання на спрощену геометрію при віддаленні об’єкта від камери. Стандарт для 3D оточення: LOD0 (100%), LOD1 (30–50% трикутників), LOD2 (10–15%), Culled. Для мобільних поріг Culled ставимо агресивніше — менше малюємо за кадр. LOD знижує draw calls на 40–60% залежно від кількості об’єктів.

Occlusion Culling — Unity не рендерить об’єкти за стінами. Вимагає запечені occlusion дані. Для indoor сцен знижує draw calls на 20–40%.

Frustum Culling працює автоматично — об’єкти поза FOV камери не рендеряться. Але draw call на перевірку все одно відбувається. Для сцен з тисячами об’єктів — кастомний spatial partitioning (Quadtree, Octree). В одному з проектів впровадження оклюзійного калінгу та LOD знизило загальну кількість draw calls з 2800 до 450 на Android.

Оптимізація VR: як утримати 72 FPS на Quest 3

VR — окремий клас задач. Фреймрейт 72/90 Hz не можна порушувати, інакше motion sickness. Додатково до стандартних методів: Single Pass Instanced Rendering — рендер для обох очей за один прохід (знижує draw calls в 2 рази); Fixed Foveated Rendering (Quest) — зниження роздільної здатності на периферії; Late Latching (Quest 3) — оновлення позиції контролера максимально пізно перед рендером; Dynamic Resolution в URP/HDRP — автоматичне зниження роздільної здатності рендера при просадці fps. Для Quest профілюємо через OVR Metrics Tool — показує CPU/GPU time прямо в гарнітурі. Після застосування цих методів частота кадрів на Quest 2 стабілізується на 72 FPS навіть у сценах з 1.5 млн полігонів.

Які етапи оптимізації та терміни?

Ми пропонуємо комплексну послугу «під ключ»:

1. Профілювання на цільових пристроях — збір метрик (FPS, draw calls, пам’ять, GC). Аналізуємо 10–15 ключових сценаріїв за 3–5 робочих днів.
2. Звіт з пріоритетами — які проблеми критичні, які можна відкласти. Пріоритети виставляємо на основі впливу на ігровий досвід.
3. Впровадження оптимізацій — батчінг, LOD, Addressables, шейдери, occlusion culling. Середній цикл впровадження — 2–4 тижні.
4. Повторне профілювання — замір покращень. Типовий приріст FPS — 30–60% на мобільних пристроях.
5. Документація — рекомендації по підтримці та подальшій розробці.
6. Навчання команди — як не допустити регресу. Проводимо воркшопи з профілювання та оптимізації.

Завдяки запобіганню переробок на пізніх етапах замовник отримує значну економію. Отримайте консультацію — ми безкоштовно оцінимо ваш проект і покажемо потенціал оптимізації. Звертайтеся, щоб дізнатися точні терміни та вартість для вашого стеку.