Оптимізація споживання батареї мобільною грою
Гра, яка розряджає телефон за півтори години, отримує однозіркові відгуки — навіть якщо FPS стабільний і крахів немає. Відгуки "сідає батарея" в App Store та Google Play прямо впливають на конверсію встановлення. При цьому споживання енергії — це прямої наслідок того, як ефективно використовуються обчислювальні ресурси.
Звідки бере лишнє споживання
Неограниченный FPS. Найбільш поширена помилка. Application.targetFrameRate = -1 (або без явної установки) означає, що Unity рендерить так швидко, як може. На iPhone 15 Pro це 120 FPS у простому меню. Для меню достатньо 30 FPS — решта 70% CPU/GPU-часу витрачається впустину й нагріває пристрій.
Частинки та ефекти у фоні. Анімований фон у головному меню з 500 частинками працює постійно, навіть коли користувач дивиться на push-сповіщення. Немає паузи при втраті фокусу програми — нема заощаджень.
GPS, акселерометр, інші датчики. Якщо гра запитує Input.location або Input.gyro без необхідності, а розробник забув вимкнути — датчики опитуються постійно. На Android це кілька мВт додатково.
Мережеві запити без батчингу. Маленькі HTTP-запити кожні 5–10 секунд (аналітика, heartbeat, синхронізація) тримають радіомодуль в активному стану. Радіо — один з найбільш енергоємних компонентів телефону.
Управління FPS за контекстом
Правильна стратегія — різні цілі для різних станів:
// Геймплей: максимальна якість
Application.targetFrameRate = 60;
// Меню, паузи, діалоги
Application.targetFrameRate = 30;
// Фонові обчислення (завантаження, збереження)
Application.targetFrameRate = 15;
На iOS також врахуйте ProMotion-дисплеї (120 Hz на iPhone 13 Pro+). За замовчуванням Unity працює на 60 FPS навіть на 120 Hz екранах, але явна установка CADisplayLink.preferredFrameRateRange через Native Plugin варта того, якщо потрібна більш тонка настройка.
OnApplicationPause(true) — тут зменшуйте FPS до мінімуму або повністю зупиняйте рендеринг.
Ефективність шейдерів
На мобільному GPU важлива точність обчислень. Використання half замість float у шейдерах на Adreno та Mali дає реальну економію енергії, тому що ALU на цих чипах оптимізовані для half-precision. Для більшості ігрових ефектів (колір, UV, освітлення) точності half достатньо.
Складні фрагментні шейдери з великою кількістю вибірок текстури особливо дорогі. Кожен tex2D — це звернення до пам'яті з латентністю, що може зупинити конвеєр. Запікання lightmap замість динамічного освітлення зменшує навантаження на фрагментний шейдер.
Батчинг мережевих запитів
Замість відправки ігрових подій аналітики по одному — буферизація та відправка пакетом раз на хвилину. Firebase Analytics робить це автоматично. Якщо використовується власна аналітика через HTTP — явна RequestQueue з таймером.
На Android WorkManager з setRequiresBatteryNotLow(true) дозволяє відкладати некритичні запити до моменту, коли пристрій заряджається.
Перевірка результату
iOS: Xcode Energy Organizer + MetricKit. MXCPUMetric та MXGPUMetric в didReceive дають реальні дані про споживання з користувацьких звітів (агреговано, без PII).
Android: Android Vitals у Play Console → Battery → Excessive wakeups. Якщо програма пробуджує пристрій частіше 10 разів за годину у фоні — це прапор від Google, що впливає на видимість у пошуку.
Для локального тестування — adb shell dumpsys batterystats --reset перед тестом та adb shell dumpsys batterystats після. Показує детальний розподіл за компонентами.
Терміни оптимізації: три-п'ять робочих днів, залежить від кількості проблемних місць та наявності нативних плагінів.