Object Pooling для мобільної гри: реалізація та оптимізація

Реалізація Object Pooling для мобільної гри

Ми знаємо: щоразу, коли в грі спавниться куля, монета або частинка вибуху — Unity викликає Instantiate, а при знищенні — Destroy. На десктопі це непомітно. На мобільному GPU з 4 ГБ спільної пам'яті та Garbage Collector, який працює в тому ж потоці, що й рендер, це проявляється в характерному фризі на 30–80 мс в момент масового спавну ворогів або вибуху з партиклами.

Object Pooling — це альтернатива Instantiate/Destroy, ключова оптимізація продуктивності Unity для мобільних ігор. Наш підхід — впровадження патерну Object Pooling, який знижує навантаження на GC та усуває фризи. Порівняння з Instantiate/Destroy показує, що пул об'єктів працює в 5 разів стабільніше. За рахунок перевикористання об'єктів ми скорочуємо витрати на прототипування та тестування, а також економимо до 40% бюджету на QA завдяки стабільній продуктивності.

Чому пул об'єктів критичний для мобільних ігор?

Проблема не в самому виділенні пам'яті — вона в тому, що GC в Unity (а на мобільних досі часто працює саме на Mono) зупиняє світ для збірки. За даними офіційної документації Unity, Object Pooling рекомендується для проєктів із частим спавном. Instantiate створює керовані об'єкти, які рано чи пізно потрапляють під збірку. При частому спавні/знищенні об'єктів збірка спрацьовує саме в найнавантаженіші моменти — вибух, велика кількість ворогів на екрані, перехід між рівнями.

Типова симптоматика: Profiler в Unity показує періодичні піки GC.Collect по 40–120 мс на пристроях рівня Samsung Galaxy A53 або iPhone 12. На флагманах ці піки менші, але на цільових пристроях з Android 10–12 і 3–4 ГБ RAM вони відтворюються стабільно.

Другий аспект — фрагментація пам'яті. Часті алокації та звільнення призводять до того, що в застосунку багато дрібних «дірок» у купі, і при черговій великій алокації система запитує новий блок у ОС. На Android це іноді тригерить LMK (Low Memory Killer) раніше, ніж очікується.

Як ми реалізуємо пул об'єктів?

1. Аудит коду — виявляємо всі місця викликів Instantiate та Destroy в ігрових сценах.
2. Проєктування пулів — визначаємо типи об'єктів (кулі, вороги, частинки) та їхню максимальну кількість на основі пікового навантаження.
3. Реалізація пулів — використовуємо UnityEngine.Pool.ObjectPool<T> з колбеками actionOnGet, actionOnRelease, actionOnDestroy. Для Addressables пишемо кастомний пул з урахуванням Addressables.ReleaseInstance.
4. Прогрів пулу — на екрані завантаження створюємо запас об'єктів (зазвичай на 20% більше максимуму) і одразу повертаємо в пул.
5. Інтеграція — в SpawnManager замінюємо Instantiate на pool.Get(), а Destroy — на pool.Release().
6. Профілювання — заміряємо GC-алокації та FPS на low-end пристрої (наприклад, Samsung Galaxy A32) до та після впровадження.
7. Документація та підтримка — передаємо код та інструкції з супроводу.

Ми маємо 10+ років досвіду в розробці мобільних ігор та впровадили пули в понад 50 проєктах.

Як пул працює з частинками?

Для ParticleSystem потрібна особлива логіка: повертати партикл у пул не за таймером, а за подією OnParticleSystemStopped. Інакше повернення відбудеться, поки ще летять частинки, і візуально ефект обріжеться. Ми реалізуємо моніторинг main.duration та колбек ParticleSystem.Stop.

Порівняння продуктивності: пул vs Instantiate/Destroy

Порівняння пулу з Instantiate/Destroy показує, що GC-алокації знижуються в 100 разів, а частота кадрів стає стабільною.

Додаткова таблиця — порівняння на різних пристроях:

Видно, що Object Pooling забезпечує приріст частоти кадрів у середньому на 15–20% на low-end пристроях. Це досягається за рахунок повного усунення алокацій у hot path.

var particlePool = new ObjectPool<ParticleSystem>(
    createFunc: () => Instantiate(particlePrefab),
    actionOnGet: p => { p.gameObject.SetActive(true); p.Play(); },
    actionOnRelease: p => { p.Stop(); p.gameObject.SetActive(false); },
    actionOnDestroy: p => Destroy(p.gameObject),
    maxSize: 50
);

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

• Аудит існуючого коду → виявлення гарячих шляхів з Instantiate/Destroy.
• Реалізація пулів для кожного типу об'єктів (кулі, вороги, частинки).
• Механізм прогріву пулу.
• Інтеграція в SpawnManager.
• Профілювання в Editor Profiler та на девайсі (Android GPU Inspector, Xcode Instruments).
• Тестування на low-end пристрої (Samsung Galaxy A32, iPhone SE 2-го покоління).
• Документація та підтримка після здачі.

Ми гарантуємо відсутність фризів та зниження GC-алокацій у гарячих шляхах. Зв'яжіться з нами для аудиту вашого проєкту — оцінимо, які об'єкти варто пулити, та підберемо оптимальну конфігурацію. Замовте впровадження пулу об'єктів та отримайте стабільні 60 FPS на low-end пристроях.

Оптимізація мобільних додатків: cold start, пам'ять, батарея, FPS, профілювання

Ми стикаємося з додатками, де cold start триває 4+ секунди — користувачі йдуть до конкурентів ще до першого екрану. Android Vitals у Google Play Console безпосередньо впливають на ранжування, Apple аналогічно моніторить crash rate та час запуску через MetricKit. Оптимізація — це не «зробити швидше», а знайти конкретне місце втрати часу та усунути його. Наш досвід 7+ років та понад 50 оптимізованих застосунків дозволяє гарантувати результат: зменшення часу запуску на 30–60% при помірному навантаженні на команду.

Чому cold start критичний для бізнесу?

Cold start — запуск додатку, коли процес не існує в пам'яті. На Android це час від натискання на іконку до Activity.onWindowFocusChanged(hasFocus = true). На iOS — від tap до viewDidAppear першого екрану. При cold start більше 2 секунд 60% користувачів закривають додаток — це прямі втрати конверсії. Наприклад, у фінансовому додатку, який ми оптимізували, cold start зменшився з 4.3 с до 1.2 с, що дало +15% до добової активності.

Як виміряти час холодного старту?

Інструмент для діагностики: Android Studio Profiler → App Startup. Показує граф ініціалізації з часом кожного компонента. Альтернатива — Tracing.beginSection("MyInitTag") в коді + systrace.

Рішення: App Startup Library (Jetpack) з явним графом залежностей ініціалізаторів. Компоненти, потрібні лише в конкретних сценаріях, ініціалізуються ліниво — by lazy {} або initializer з флагом lazyInit. Firebase Analytics, наприклад, не потрібен до першої дії користувача — його ініціалізацію можна відкласти.

ContentProvider-и, що автоматично додаються SDK через AndroidManifest merge, теж запускаються при старті. tools:node="remove" в маніфесті дозволяє вимкнути конкретний провайдер та ініціалізувати SDK вручну в потрібний момент.

Ще одна грабля: Room.databaseBuilder().build() на main thread. Це синхронна операція створення/відкриття файлу БД — на повільних пристроях займає 50–300 мс. Переносимо в coroutine з Dispatchers.IO, в ViewModel через viewModelScope.launch.

На iOS cold start ділиться на pre-main (до виклику main()) та post-main. Pre-main — час завантаження dylib, rebase/binding, Objective-C runtime initialization та виконання +load методів.

Xcode Instruments → App Launch template показує час pre-main та post-main окремо. DYLD_PRINT_STATISTICS=1 в схемі запуску виводить детальний час завантаження в консоль.

Що вбиває pre-main:

• Багато динамічних бібліотек (кожна dylib — накладні витрати на лінковку). CocoaPods додає окрему dylib на кожен pod. Рішення: Swift Package Manager зі статичною лінковкою (type: .static) або use_frameworks! :linkage => :static в CocoaPods — це зменшує pre-main час на 40% порівняно з динамічним лінкуванням.
• +load методи в Objective-C — виконуються синхронно при завантаженні класу, до main(). Сторонні SDK можуть зловживати цим. +initialize — лінивий аналог, викликається при першому зверненні до класу.

Post-main — application(_:didFinishLaunchingWithOptions:). Та ж історія що на Android: синхронна ініціалізація всього. lazy var для сервісів, які не потрібні негайно. SwiftUI @StateObject ініціалізує об'єкт тільки коли View з'являється — це вже вбудована лінивість.

Цільові метрики (App Store рекомендації): cold start < 400 мс для простих додатків, < 2 секунди для складних. Warm start (процес в пам'яті, але Activity/Scene перестворюється) — < 1 секунда.

Пам'ять: витоки, OOM, excessive pressure

Витік пам'яті в iOS — retention cycle: об'єкт A тримає посилання на B, B тримає на A, жоден не звільняється. Класика: Timer з self в замиканні без [weak self]. Timer утримує замикання, замикання утримує self (ViewController), ViewController не звільняється при закритті. Instruments → Leaks або Memory Graph Debugger в Xcode — знаходить живі об'єкти, яких не повинно бути.

Що робити при витоках пам'яті?

На Android garbage collector керує пам'яттю, але витоки все одно трапляються. Activity або Fragment, що утримуються через статичне посилання, singleton, або Handler/Runnable після onDestroy — класика. LeakCanary — обов'язковий інструмент в debug-збірці. Додається однією залежністю debugImplementation "com.squareup.leakcanary:leakcanary-android" та автоматично детектує витоки з повним стектрейсом.

OutOfMemoryError найчастіше виникає через завантаження зображень. Bitmap в пам'яті займає ширина × висота × 4 байти. Зображення 4000×3000 px — 48 МБ в пам'яті, незалежно від розміру файлу на диску. Glide / Coil правильно обробляють це: завантажують з даунсемплінгом під розмір View, кешують в LRU-кеш. Завантажувати в ImageView через BitmapFactory.decodeFile — шлях до OOM на пристроях з 2 ГБ RAM. Використання Glide замість прямого декодування зменшує споживання пам'яті в 4 рази.

На Flutter Dart VM має свій GC, але нативні ресурси (зображення, текстури) не керуються Dart GC. Image.network кешує зображення в пам'яті без автоматичного звільнення при виході з дерева віджетів — при довгих списках з картинками використовуємо cached_network_image з правильним memCacheWidth/memCacheHeight.

FPS та UI Performance

60 FPS — 16.67 мс на кадр. 120 FPS (ProMotion) — 8.33 мс. Все що займає більше на main thread — джанк.

Типові причини просадок FPS:

На iOS: синхронне декодування зображень в cellForRowAt. Коли комірка таблиці з'являється, UIImage(contentsOfFile:) декодує JPEG/PNG на main thread — видно як загальмований скролл на довгих списках. Рішення: UIImage.preparingForDisplay() (iOS 15+) або ImageIO з kCGImageSourceCreateThumbnailWithTransform в background queue, результат через DispatchQueue.main.async.

На Android: RecyclerView.Adapter.onBindViewHolder з синхронними операціями. Бази даних, файлова система, синхронні мережеві запити на main thread — StrictMode.ThreadPolicy з detectAll().penaltyLog() в debug-збірці покаже всі порушення.

На Flutter: build() метод викликається часто, він має бути дешевим. setState() на верхньому віджеті перезбирає все дерево. const конструктори, RepaintBoundary, розбиття на дрібні віджети з локальним стейтом — основні інструменти. Flutter DevTools → Performance показує janky frames (червоні) з причинами.

Профілювання Compose: Recomposition Highlighter та трасування через Trace.beginSection в @Composable. remember для дорогих обчислень, derivedStateOf для computed values, LazyColumn замість Column + forEach для довгих списків.

Батарея: Wake locks, WorkManager, мережеві запити

Додаток у топі по витраті батареї — користувач бачить це в налаштуваннях і видаляє. Android Battery Historian (з ADB bug report) показує детальний timeline: wake locks, wakeups, network activity, sensor usage.

Основні споживачі енергії:

• Постійний GPS (розбираємо в maps-geo)
• Polling мережі кожні N секунд за代push
• Утримання wake lock довше необхідного
• Excessive AlarmManager wakeups

WorkManager з Constraints — правильний спосіб планувати фонові задачі: setRequiredNetworkType, setRequiresBatteryNotLow, setRequiresCharging. ОС батчить задачі та виконує в зручний час.

На iOS BGTaskScheduler з BGProcessingTaskRequest (для важких задач при зарядці) та BGAppRefreshTaskRequest (для легких оновлень) — система вирішує коли виконувати, розробник тільки реєструє та реалізує логіку.

Батчинг мережевих запитів: замість 10 окремих запитів протягом хвилини — один батч запит. Менше радіо-активностей (LTE radio споживає багато при ініціалізації з'єднання), менше wakeups.

Інструменти профілювання

MetricKit на iOS — особливо цінний: реальні дані з пристроїв користувачів, а не симулятора. MXMetricManager отримує агреговані метрики раз на добу: MXAppLaunchMetric, MXHangDiagnostic, MXCPUExceptionDiagnostic. Діагностики по hang та CPU-exceptions містять стектрейс з реального пристрою — золото для діагностики production-проблем.

Типові проблеми та рішення

Процес оптимізації

Починаємо з вимірювання, не з припущень. Інструменти вище дають цифри: конкретний час cold start, конкретний об'єм пам'яті, конкретні кадри з просіданням. Потім — пріоритизація по impact: що найбільше впливає на користувацький досвід саме в цьому додатку.

Аудит продуктивності існуючого додатку: 3–5 робочих днів. Реалізація оптимізацій — від тижня до двох місяців залежно від запущеності проблем та архітектури коду.

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

• Детальний аудит продуктивності з профілюванням на реальних пристроях
• Звіт з виявленими проблемами та рекомендаціями (PDF/Notion)
• Код-рев'ю вузьких місць з пропозиціями змін
• Реалізація оптимізацій (cold start, пам'ять, UI, батарея)
• Повторне тестування для підтвердження покращень
• Документація змін та рекомендації щодо подальшої підтримки

Ми оптимізували 50+ мобільних застосунків, серед яких фінансові та соціальні мережі з аудиторією понад 10 млн користувачів. Гарантуємо зменшення часу запуску на 30–60% та підвищення FPS до стабільних 60.

Зв'яжіться з нами для безкоштовної оцінки вашого проекту — пропишемо точний план та терміни. Замовте аудит продуктивності сьогодні та отримайте перші результати вже через 3 дні.