Как устроен геофенсинг на Android, который не убивает батарею: разбор архитектуры на примере Muffle

Разработчик приложения Muffle объяснил, как сделать автоматическое переключение звуковых профилей по геолокации без постоянного GPS-опроса и без разряда к полудню. Разбираем архитектурные решения, инженерные компромиссы и то, чего в этом разборе не хватает.

Дело почти никогда не в GPS: если приложение разряжает телефон, чаще виноват ForegroundService, который разработчик забыл остановить, а не спутники над головой.

История, с которой начинается разбор, одновременно бытовая и показательная. Пятничная проповедь, тишина, и тут звонок — чужой, но смущение коллективное. Отсюда идея Muffle: приложение само переводит телефон в беззвучный режим, когда владелец входит в мечеть, переговорку, аудиторию или поликлинику, и возвращает громкость на выходе. Формулировка «просто работало бы в фоне и не превращало телефон в грелку» — это, по сути, техническое задание, и именно оно диктует архитектуру.

Почему наивный подход убивает батарею

Самый очевидный способ сделать такое приложение — опрашивать координаты через LocationManager с запросом высокой точности и сравнивать их с координатами нужных зданий. Технически это работает, ресурсно — нет. Запрос высокой точности означает, что приложение требует от системы держать GPS-радио активным: чип регулярно ловит спутники, считает решение и отдаёт координаты. Радиомодуль в этом режиме входит в число самых прожорливых компонентов смартфона, и если опросить его «на постоянку», разряд к трем часам дня — прогнозируемый исход. Плюс такой подход страдает от фоновых ограничений Android: начиная с Android 8 (API 26) систематические фоновые службы жёстко ограничены, а с более поздних версий добавляются режимы энергосбережения (Doze, App Standby), которые и вовсе режут частоту обновлений. То есть наивный опрос ещё и плохо работает — он и дорогой, и ненадёжный.

Правильный ответ Google называется GeofencingClient — API из состава Google Play Services. Меняется сама парадигма: приложение не спрашивает «где я?», оно регистрирует зоны (геозоны) и подписывается на события перехода их границ. Дальше тяжёлую работу берёт на себя система: так называемый fused location provider, который смешивает данные GPS, Wi-Fi-сканирования, сотовой сети и датчиков движения, батчит обновления и будит приложение только при переходе через границу зоны. Когда телефон лежит на столе, потребление такого механизма близко к нулю, потому что собственного цикла опроса у приложения просто нет. Это тот случай, когда разработчику выгоднее довериться инфраструктуре платформы, а не писать свою логику.

Тонкая настройка радиуса: 50 метров оказались слишком мало

Первое практическое решение — радиус геозоны. Автор Muffle пришёл к 100 метрам, назвав их «золотой серединой» между ложными срабатываниями и точностью для здания или кампуса. Путь к этому значению показательнее самого числа.

Исходная гипотеза — «чем точнее, тем лучше» — привела к радиусу 50 метров, и она не выдержала контакта с городской средой. В плотной застройке GPS-сигнал слабый, отражается от высотных зданий и «плывёт»: устройство начинает переключаться между состояниями «внутри» и «снаружи» зоны. Это называют «флаппингом»: телефон за три минуты несколько раз вибрирует, замолкает, включает звук и снова замолкает. Для пользователя это не точность, а раздражение.

Отсюда два вывода. Во-первых, геозона — это не «точка на карте с погрешностью метров», а вероятностная область, и радиус должен быть заведомо больше реальной погрешности определения местоположения, которая в центре мегаполиса легко доходит до десятков метров. Во-вторых, нужен механизм подавления дребезга — дебаунс: буферная зона плюс небольшая временная задержка, прежде чем звуковой профил действительно переключится. Формально это снижает «резкость» реакции, зато убирает ложные переключения. Компромисс классический: чуть позже сработает — но сработает один раз, а не пять.

Почему приёмник широковещания обязан быть «тощим»

Когда геозона срабатывает, система доставляет приложению PendingIntent — отложенный намерение, которое Android выполнит при наступлении события. Тут есть два подводных камня.

Первый — флаги. Начиная с Android 12 (API 31) PendingIntent по умолчанию считается неизменяемым (immutable), а для работы с геозонами Google требует изменяемый (FLAG_MUTABLE): Google Play Services должен иметь возможность вложить данные о событии в интент перед доставкой. Приложение, которое соберёт запрос с FLAG_IMMUTABLE, просто не получит срабатываний.

Второй — объём работы в обработчике. onReceive() у BroadcastReceiver выполняется в условиях жёсткого лимита времени; если тащить туда запись в базу или сетевые запросы, система имеет полное право убить процесс ради экономии памяти. В архитектуре Muffle приёмник делает ровно одну вещь: перекладывает задачу в WorkManager — менеджер фоновых задач Android, который ставит работу в очередь и выполняет её с учётом ограничений системы (заряд, сеть, режим энергосбережения), не блокируя главный поток и не провоцируя ANR (диалог «приложение не отвечает»). Тем самым событие геолокации развязывается с бизнес-логикой звуковых профилей: приёмник отвечает только за доставку, воркер — за исполнение.

Забытый exit-событие: проблема, которая стоила дороже всего

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

Выход — система восстановления состояния. Каждый запуск приложения сверяет текущее местоположение с активными геозонами из локальной базы; если пользователь находится внутри какой-то зоны, состояние принудительно синхронизируется. По словам разработчика, эта «перезагрузочная безопасность» оказалась сложнее самой реализации геозон, потому что потребовала хранить последнее известное состояние локально и независимо от эфемерного состояния системного геозона-регистра. Здесь хорошо видно общий принцип: состояние, от которого зависит поведение устройства, нельзя доверять volatile-хранилищу — у него нет гарантии, что оно доживёт до перезагрузки.

Где на самом деле сидело потребление батареи

Самая полезная часть разбора — признание ошибки в диагностике. Недели ушли на оптимизацию кода геолокации, а реальной причиной разряда оказался ForegroundService — служба переднего плана, которую приложение держало, чтобы «не заснуть». Такая служба обязана показывать уведомление и в идеале использоваться только для того, что реально требует постоянного внимания (навигация, воспроизведение, загрузка). Держать её ради геозон — это ещё и держать wake lock, блокировку пробуждения процессора, дольше необходимого. Итоговая схема строже: AlarmManager для временных триггеров (например, расписания), GeofencingClient — только для релевантных геозон, без постоянной службы.

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

Чего в этом разборе не хватает

При всём уважении к инженерной части, это разбор от первого лица, а не измерительный отчёт, и к цифрам в нём стоит относиться аккуратно. Автор оперирует радиусами и архитектурными решениями, но не приводит ни одного измеренного показателя потребления: нет процентов заряда за сутки, нет сравнения с фоном, нет моделей устройств и версий Android, на которых проводились тесты. Утверждение, что GeofencingClient «потребляет почти ноль батареи», корректно направляюще — но фактически это зависит от частоты событий, количества зон и того, как сам fused provider работает на конкретном устройстве. Документированные ограничения платформы тоже стоит держать в уме: активных геозон на приложение — не больше сотни, а сам механизм привязан к Google Play Services, то есть на устройствах без GMS (часть аппаратов Huawei) он не работает в принципе.

И последнее: Muffle — это всё-таки конкретное приложение, и разбор заканчивается ссылкой на него в Google Play. Это нормальная практика для dev-блога, но архитектурные уроки от этого не становятся менее применимыми. Доверяйте системным API вместо собственных циклов опроса, закладывайтесь на перезагрузки, обрывы сигнала и «дребезг» состояний, а не только на идеальный сценарий, — именно в этих краях и живёт настоящая инженерия.