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