Фоновая синхронизация срабатывает вручную, но пропускается при заблокированном экране: как проверить, что её ограничила энергосберегающая политика ОС, а не ошибка планировщика приложения?
Нужно разделить проверку на этапы: была ли задача запланирована приложением, передала ли её ОС на выполнение, стартовала ли она фактически и завершилась ли успешно. Если синхронизация стабильно работает на переднем плане, а при заблокированном экране задерживается или не запускается только при включённых энергосберегающих ограничениях, вероятна политика ОС, а не ошибка планировщика.
Однако отсутствие запуска само по себе ничего не доказывает. Фоновые задачи на мобильных платформах обычно выполняются с ограничениями и не гарантируют точное время запуска.
Мобильные ОС изначально ограничивали фоновую активность ради автономности, нагрева и стабильности устройства. Постоянные фоновые таймеры и сетевые соединения быстро разряжали батарею и мешали системе распределять ресурсы между приложениями.
Поэтому Android использует, среди прочего, режимы Doze и App Standby, а производители могут добавлять собственные ограничения. На iOS система сама управляет допустимостью фонового выполнения и может переносить фоновую работу на более подходящий момент.
Типичный сценарий выглядит так: приложение планирует синхронизацию, пользователь блокирует экран, устройство некоторое время бездействует, а обновление данных не происходит. Пользователь воспринимает это как дефект, хотя задача могла быть корректно зарегистрирована, но отложена ОС.
Риски неверного вывода существенны: команда может исправлять рабочий планировщик, хотя проблема находится в ограничениях платформы, либо наоборот — списать обычный дефект приложения на энергосбережение. Особенно сложна диагностика на Android из-за различий между версиями ОС и политиками производителей устройств.
Сначала нужно добавить наблюдаемость в жизненный цикл задачи: фиксировать момент планирования, идентификатор задачи, факт её передачи на выполнение, фактический старт, состояние устройства и итог завершения. Отдельно следует записывать причину завершения и сетевой результат, чтобы не путать запрет запуска с ошибкой внутри синхронизации.
Затем выполняется контрольная матрица:
Если задача выполняется на переднем плане, но не стартует в фоне, важно определить границу сбоя. Запись о планировании без записи о фактическом старте указывает на перенос или подавление системой. Запись о старте с последующей ошибкой указывает уже на код задачи, доступ к данным или сеть.
Для проверки причинности нужно повторить сценарий в одинаковых условиях, меняя только один фактор: например, включить или выключить ограничение батареи. Единичный успешный запуск не доказывает исправность, потому что ОС может временно разрешить выполнение из-за зарядки, активности пользователя или другого системного события.
На Android следует учитывать Doze, App Standby, ограничения фоновой активности и фирменные менеджеры батареи. На iOS нельзя обещать пользователю выполнение строго в заданную минуту: фоновые возможности предоставляются системой по условиям устройства и приоритету задачи.
Надёжный продуктовый дизайн не должен зависеть от единственного фонового запуска. Синхронизация должна быть идемпотентной, повторяться при следующем удобном запуске и корректно обрабатывать пропуски. Если бизнес-требование допускает задержку, его нужно формулировать как гарантированное обновление при следующем доступном запуске, а не как точный момент выполнения.
Приложение учёта расходов должно синхронизировать операции каждые тридцать минут. На тестовом устройстве синхронизация работает при открытом приложении, но перестаёт происходить ночью.
Рассматривались три варианта. Первый — увеличить частоту фонового планировщика; это не решает системное ограничение и может повысить расход батареи. Второй — считать пропуск дефектом Android; это даёт быстрый вывод, но игнорирует Doze и различия производителей. Третий — собрать телеметрию этапов задачи и повторить тест с разными настройками батареи; этот вариант требует больше подготовки, зато позволяет локализовать причину.
Выбрали третий вариант. Логи показали, что задача регистрировалась, но при заблокированном экране не получала времени выполнения до выхода устройства из режима бездействия. После изменения логики приложение выполняло синхронизацию при следующем разрешённом запуске, не создавало дубликаты и показывало пользователю время последнего успешного обновления.
Нет. Сначала нужно установить, был ли запуск разрешён системой и дошёл ли он до кода приложения. Фоновая работа может быть отложена из-за режима бездействия, низкого заряда, ограничений приложения, политики производителя или условий сети.
Доказательством дефекта будет, например, подтверждённый старт задачи с последующим неверным завершением, исключением или неправильным изменением состояния. Если же приложение только зарегистрировало задачу, а системного события запуска не было, причина может находиться вне его планировщика.
Зарядка изменяет условия энергосбережения и часто делает систему более склонной разрешать отложенную работу. Поэтому задача может выполниться во время зарядки, но не в обычном сценарии с заблокированным экраном и питанием от батареи.
Зарядку нужно рассматривать как отдельный фактор матрицы, а не как универсальный способ подтвердить корректность. Результат следует проверять минимум в режимах работы от батареи и от сети, с одинаковым временем бездействия и состоянием приложения.
При задержке ОС задача обычно остаётся зарегистрированной и может выполниться позже, когда условия станут подходящими. При явном запрете фоновой активности, ограничении батареи или принудительной остановке приложение может не получать запуск до изменения настройки или нового действия пользователя.
Для различения нужно проверить состояние задачи после предполагаемого окна запуска, системные настройки приложения и поведение после снятия ограничения. Нельзя автоматически восстанавливать работу обходными механизмами: это может нарушить правила платформы и увеличить расход батареи. Корректнее обеспечить повторную синхронизацию при следующем запуске приложения и явно сообщить пользователю о времени последнего успешного обновления.