Почему приложение быстро разряжает телефон и как разработчику этого избежать

Есть два типа приложений: одни пользователь открывает, пользуется и спокойно закрывает. А другие после закрытия продолжают жить свою лучшую жизнь: что-то грузят, синхронизируют, слушают сеть, будят процессор и делают вид, что так и надо.

И вот человек просто хотел посмотреть список задач, а через час у него телефон горячий, батарея на 18%, а в настройках написано: «Ваше приложение использовало 47% заряда». Поздравляем. Вы стали главным злодеем дня.

⚙️ Главный пожиратель заряда — хаос внутри приложения

Конечно, экран потребляет много энергии. Но разработчик часто убивает батарею не экраном, а тем, что приложение делает слишком много лишнего.

• слишком часто ходит в сеть;

• держит фоновые процессы;

• постоянно обновляет данные;

• использует GPS без необходимости;

• запускает тяжёлые вычисления не вовремя;

• не умеет нормально «засыпать»;

• бесконечно повторяет запросы при плохом интернете.

То есть проблема не в том, что приложение работает. Проблема в том, что оно работает как тревожный стажёр в первый день: каждую секунду что-то проверяет, переспрашивает и паникует.

👻 Фоновые процессы: «я закрыл приложение, почему оно всё ещё живое?»

Фоновая работа — это когда приложение делает что-то, даже если пользователь сейчас им активно не пользуется. Например, синхронизирует данные, загружает файлы, обновляет геолокацию, отправляет аналитику или проверяет новые сообщения.

Само по себе это нормально. Проблема начинается, когда фоновые процессы работают слишком часто или без реальной причины.

Каждые 10 секунд:
- проверить сервер
- обновить данные
- отправить аналитику
- проверить геолокацию
- повторить

Пользователь в это время спит. Телефон лежит на тумбочке. А приложение такое: «Я вообще-то бизнес-процессы оптимизирую».

Как делать лучше

• не синхронизировать всё подряд, если данные не изменились;

• объединять несколько фоновых задач в одну;

• учитывать заряд батареи;

• учитывать тип подключения: Wi-Fi или мобильная сеть;

• не запускать тяжёлые задачи в энергосберегающем режиме;

• использовать системные механизмы фоновых задач, а не вечный самодельный цикл.

Главная мысль простая: фон — не место для вечеринки. Это место для аккуратной, редкой и полезной работы.

🌐 Сеть: каждый запрос — это маленький удар по батарее

Многие думают, что сетевой запрос — это просто:

fetch('/api/data')

Красиво, коротко, почти невинно. Но для смартфона сетевой запрос — это целая движуха: включить радиомодуль, установить соединение, передать данные, дождаться ответа, обработать результат, а иногда ещё и повторить, если сеть плохая.

Особенно больно, если приложение делает много мелких запросов при запуске.

GET /user
GET /profile
GET /settings
GET /notifications
GET /stats
GET /banner
GET /recommendations

Пользователь просто тапнул по иконке, а приложение уже устроило серверный корпоратив.

Что убивает батарею в сетевой работе

Частые polling-запросы

Polling — это когда приложение постоянно спрашивает сервер:

Есть новости?
А сейчас?
А сейчас?
А сейчас?

Сервер отвечает: «Нет». Приложение: «Понял, спрошу через 3 секунды». Для батареи это боль.

Если интернет плохой, приложение может начать повторять запросы слишком агрессивно:

Запрос не прошёл.
Повтор.
Повтор.
Повтор.
Повтор.

Телефон в этот момент примерно такой: «Брат, я устал».

Слишком большие ответы API

Если вместо нужных пяти полей API отдаёт весь роман «Война и JSON», телефон тратит энергию на скачивание, парсинг и хранение лишних данных.

📡 Как оптимизировать сеть и не бесить пользователя

Объединяй запросы

Если при запуске нужно получить несколько блоков данных, иногда лучше сделать один агрегированный запрос, чем десять мелких.

Плохо:

GET /name
GET /avatar
GET /balance
GET /settings

Лучше:

GET /home-screen

Но без фанатизма. Один огромный монстр-эндпоинт тоже может стать проблемой.

Используй кеш

Если данные не меняются каждую секунду, не надо каждый раз грузить их заново. Кешировать можно настройки, аватарки, справочники, темы оформления, статические списки и часть контента.

Пользователь не заметит, что справочник категорий обновляется не каждую секунду. А вот минус 20% батареи — заметит.

Делай backoff для повторных запросов

Если запрос не прошёл, не надо долбить сервер как дятел на кофеине. Лучше постепенно увеличивать задержку.

1 секунда
2 секунды
5 секунд
10 секунд
30 секунд

Это называется exponential backoff. По-человечески: «не получилось — не истерим, пробуем позже».

Не обновляй всё, если изменилось чуть-чуть

Если пользователь изменил имя профиля, не надо перезагружать весь аккаунт, историю заказов, настройки, аватар, уведомления и гороскоп на завтра. Обновляй только то, что действительно изменилось.

📍 Геолокация: GPS — это режим «сожги батарею красиво»

Геолокация — один из самых опасных инструментов для батареи. Особенно если приложение просит точную геолокацию и обновляет её постоянно.

Есть огромная разница между «нужно примерно понять город пользователя» и «нужно отслеживать движение курьера в реальном времени».

Но некоторые приложения ведут себя так, будто доставка пиццы, карта пробежки и прогноз погоды — это один и тот же уровень точности.

Плохой подход:

Получать точную геолокацию каждые 5 секунд,
даже если пользователь просто смотрит каталог товаров.

Хороший подход:

• использовать примерную геолокацию, если точная не нужна;

• снижать частоту обновлений;

• выключать отслеживание, когда оно больше не нужно;

• не запускать GPS в фоне без серьёзной причины;

• объяснять пользователю, зачем нужна геолокация.

Главное правило: если можно не использовать GPS — не используй GPS.

🔔 Уведомления и пуши: не буди приложение ради ерунды

Пуш-уведомления могут быть полезными. Но если приложение использует их как повод постоянно просыпаться и что-то пересчитывать — батарея плачет.

Плохой пример:

Пришёл пуш.
Приложение проснулось.
Загрузило профиль.
Загрузило новости.
Загрузило баннеры.
Отправило аналитику.
Обновило кеш.
Проверило ещё 5 эндпоинтов.

А пуш был просто: «У нас новая акция». Ну спасибо.

Пуш должен запускать только минимально нужную работу. Если уведомление можно показать без тяжёлой синхронизации — показывай. Если данные нужны только после открытия приложения — не загружай их заранее.

🌀 Анимации и UI: красиво не значит бесконечно

Современные приложения любят анимации. И это нормально. Проблема начинается, когда анимации работают постоянно, экран перерисовывается слишком часто, список рендерится целиком, видео или GIF крутятся без остановки, а тяжёлый UI живёт даже вне экрана.

Например, бесконечный shimmer-loader, который работает даже после загрузки данных, — это не дизайн. Это маленький вентилятор для батареи.

Что помогает

• останавливать анимации, когда экран неактивен;

• не рендерить элементы, которые пользователь не видит;

• использовать виртуализацию списков;

• не запускать тяжёлые эффекты без смысла;

• следить за частотой перерисовок.

Красивый интерфейс — это круто. Но если он превращает телефон в грелку, пользователь не скажет: «Вау, какой плавный градиент». Он скажет: «Удалить приложение».

📊 Аналитика: полезная, пока не стала шпионским пылесосом

Аналитика нужна. Без неё сложно понимать, что происходит в продукте. Но иногда приложение отправляет события буквально на каждый чих.

user_opened_screen
user_saw_button
user_hovered_button
user_breathed_near_button
user_almost_clicked_but_changed_mind

Если таких событий много, они начинают влиять и на сеть, и на батарею.

Как лучше

• отправлять события пачками;

• не слать аналитику мгновенно на каждое действие;

• фильтровать мусорные события;

• не собирать то, что потом никто не анализирует;

• отправлять данные в удобный момент, а не постоянно.

Хорошая аналитика отвечает на вопросы бизнеса. Плохая аналитика просто создаёт ощущение, что «мы всё логируем», а потом никто это не открывает.

🧠 Тяжёлые вычисления: не делай всё на главном потоке

Если приложение обрабатывает изображения, шифрует данные, парсит большие JSON, строит графики или делает сложные расчёты — это может активно расходовать батарею.

Особенно если всё происходит часто, на главном потоке, без кеша, при каждом открытии экрана и без проверки, изменились ли данные.

Плохой пример:

Пользователь открыл экран.
Приложение заново пересчитало всю статистику за год.
Пользователь закрыл экран.
Открыл снова.
Приложение снова пересчитало всю статистику за год.

Это уже не приложение. Это тренажёр для процессора.

Как лучше

• кешировать результаты;

• пересчитывать только изменённые данные;

• переносить тяжёлые задачи в background worker;

• разбивать вычисления на части;

• не делать тяжёлую работу при каждом рендере;

• профилировать код, а не гадать по кофейной гуще.

🧪 «Работает у меня» — не значит работает нормально у пользователя

На телефоне разработчика всё может быть отлично: новый смартфон, быстрый интернет, зарядка рядом, свежая батарея, тестовые данные маленькие, приложение открыто две минуты.

А у пользователя — старый Android, 19% заряда, мобильная сеть в лифте, 2000 сообщений в истории, включён энергосберегающий режим, параллельно работает навигатор, и телефон уже видел жизнь.

Поэтому важно тестировать не только идеальный путь, но и реальные условия:

• слабая сеть;

• режим энергосбережения;

• старые устройства;

• долгие сессии;

• фоновая работа;

• большой объём данных;

• повторное открытие приложения после сна.

🚀 Где тут место новичку-разработчику?

Оптимизация батареи звучит как что-то из мира «сеньоры в капюшонах читают профайлеры при свечах». Но на самом деле базовые принципы можно понять довольно быстро.

Главная идея простая: смартфон — это не сервер в дата-центре. У него есть батарея, слабая сеть, ограничения операционной системы и пользователь, который не обязан терпеть плохую оптимизацию.

Если ты учишься программированию и хочешь не просто писать «работает», а понимать, почему работает хорошо или плохо, такие темы очень полезно разбирать на практике.

В приложении Кодик можно изучать программирование постепенно: с упражнениями, практикой и нормальным объяснением без ощущения, что тебя бросили в документацию и сказали «плыви».

А ещё у Кодика есть Telegram-канал, где выходят полезные посты для разработчиков. Это удобный способ повторять темы, ловить новые идеи и не выпадать из обучения.

Потому что хороший разработчик — это не тот, кто просто сделал кнопку. А тот, кто сделал кнопку, после которой телефон не умер.