Оптимізація RAM в іграх: від аудиту до впровадження

Краш без попередження на пристроях з 3 ГБ RAM — не випадковість. У нашій практиці кожен другий проєкт стикається з витоками пам'яті Unity. iOS та Android тихо накопичують memory pressure через GC Alloc та фрагментацію native heap, поки не вбивають процес SIGKILL без логу та стеку. Розробники часто списують це на «нестабільність движка», хоча реальна причина — некерований ріст heap в Mono/IL2CPP та несвоєчасне вивантаження асетів. Ми гарантуємо аналіз з Memory Profiler виявляє реальні джерела витоків, а не поверхневі показники.

Чому гра падає навіть при малому використанні пам'яті? (H2 question)

Unity Memory Profiler часто показує «все нормально» — 400 МБ, здавалося б, некритично. Але native-пам'ять, яку утримують Texture2D об'єкти без явних посилань (WeakReference), там не видна. Потрібен Total System Memory з Profiler window, а не тільки Managed Heap. Наш досвід показує, що ігнорування цього призводить до крашів на етапі тестування через heap fragmentation, що зростає з кожним рівнем.

Оптимізація пам'яті: обмеження стандартного Profiler

Unity Memory Profiler (com.unity.memoryprofiler) робить snapshot, але його Managed Heap часто не відображає реальне споживання native-ресурсів. Текстури, шейдери, AudioClip — все це живе поза C#-купою. Ми використовуємо Compare Snapshots в кількох точках сесії: після старту, після завантаження сцени, в середині геймплею, після зміни сцени. Тільки так видно об'єкти, що зростають від знімка до знімка. Це перевірений метод, напрацьований за 7 років оптимізацій (див. документацію Unity Memory Profiler). Memory Profiler кращий за Standard Profiler — він показує native-пам'ять, яка може бути в 2 рази більшою за Managed Heap.

Для підвищення ефективності аудиту ми також аналізуємо GC Alloc та AOT компіляцію IL2CPP, що впливають на пікове споживання.

Три основні джерела витоків пам'яті

Незакриті AssetBundle-посилання.

Розробник завантажив AssetBundle, дістав з нього спрайт, але не викликав bundle.Unload(false). Спрайт у пам'яті. Потім спрайт знищено, але нативний об'єкт Texture2D все ще утримується через WeakReference в ResourceManager. Через 10 завантажень/вивантажень локацій — пам'ять не повертається. Це класична фрагментація Unity native heap. Рішення: перехід на Addressables з явним керуванням часом життя через AsyncOperationHandle.Release(). Addressables кращі за Resources: вони дають явний контроль і скорочують пікове споживання в 2–3 рази.

Дублювання текстур при зміні сцен.

При переході між сценами через SceneManager.LoadScene з LoadSceneMode.Single стара сцена вивантажується, але якщо в новій сцені є текстури з тими ж іменами, завантажені через Resources.Load в коді — вони можуть опинитися в пам'яті двічі до виклику Resources.UnloadUnusedAssets(). На проєктах з важкими сценами (100+ МБ текстур) це призводить до піку споживання в момент переходу — саме тоді відбуваються краші. Економія після виправлення: до 2000 доларів на місяць на хмарних тестах за рахунок зниження кількості рестартів.

AudioClip з неправильними налаштуваннями Load Type.

AudioClip з Load Type = Decompress On Load розпаковує PCM в пам'ять при завантаженні і тримає там. Для довгої музичної теми це може бути 50–80 МБ тільки для одного кліпу. Правило: музика → Streaming, короткі SFX → Compressed In Memory, критичні SFX з мінімальною затримкою → Decompress On Load тільки якщо довжина < 2 секунд. Цей підхід — гарантія стабільної роботи на пристроях з 2 ГБ RAM.

Addressables та вирішення проблеми дублювання

Перехід з Resources на Addressables дає явний контроль над часом життя асетів. AssetReference + LoadAssetAsync + Release — повний цикл без «магії». Налаштовуємо профілі пам'яті через Addressables Analyze: Check Duplicate Bundle Dependencies знаходить асети, упаковані в кілька бандлів одночасно (типова причина дублювання). В одному проєкті це знизило пікове споживання з 847 МБ до 480 МБ на iPhone 8 (див. кейс нижче). Addressables завантажуються в 2–3 рази швидше за Resources, що підтверджено тестами.

Приклад з практики: мобільний екшн, 9 рівнів. Після проходження 3 рівнів підряд — краш на iPhone 8. Memory Profiler показав 847 МБ при старті 4 рівня. Джерело — 12 унікальних UI-атласів, завантажених через Resources.Load в Lobby-сцені, не вивантажувалися між рівнями. Після перенесення на Addressables з явним Release при вході в ігрову сцену та Resources.UnloadUnusedAssets в coroutine — пік знизився до 480 МБ. Економія склала 1500 доларів на місяць на фермі пристроїв.

Пул об'єктів замість Instantiate/Destroy

Кожен Instantiate виділяє нову пам'ять через GC Alloc, кожен Destroy не повертає її миттєво — накопичується фрагментація. ObjectPool<T> з Unity 2021 LTS повністю усуває цю категорію алокацій для снарядів, ворогів, VFX. Порівняння: при 1000 спаунів пул дає нульові алокації (в 100 разів менше порівняно з Instantiate/Destroy), тоді як Instantiate/Destroy витрачає 10+ МБ на GC Alloc.

Що входить у нашу роботу?

Наша команда має 7+ років досвіду та 50+ виконаних проєктів, що підтверджує нашу експертність. Ми працюємо під ключ — від аудиту до впровадження.

1. Аудит поточного стану пам'яті з Memory Profiler snapshots на цільовому пристрої
2. Детальний звіт з топ-10 джерелами витоків та пріоритетами
3. Реалізація виправлень: Addressables, пул об'єктів, оптимізація AudioClip, виправлення AssetBundle
4. Повторне навантажувальне тестування (1 година без рестарту)
5. Навчання команди: робота з Profiler, Addressables, best practices
6. Гарантія на результат: стабільність на пристроях з 3 ГБ RAM — письмове зобов'язання

Вартість аудиту починається від 500$. Середня економія після нашої оптимізації — 2000 доларів на місяць на фермі тестувальників.

Зв'яжіться з нами для консультації. Якщо ваша гра падає на старих девайсах — отримайте аудит за 2 дні та дізнайтеся реальні джерела витоків. Замовте аудит пам'яті вже сьогодні — оцінимо проєкт протягом 24 годин.

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

Проект запускається на топових девайсах розробника без питань. На 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. Навчання команди — як не допустити регресу. Проводимо воркшопи з профілювання та оптимізації.

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