Оптимізація 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 годин.