AlarmManager ) позволяют выполнять операции, привязанные ко времени, вне рамок жизненного цикла приложения. Например, вы можете использовать сигнал тревоги для запуска длительной операции, такой как запуск службы один раз в день для загрузки прогноза погоды.Сигнализация обладает следующими характеристиками:
Они позволяют запускать Intents в заданное время и/или с заданными интервалами.
Вы можете использовать их совместно с широковещательными приемниками для планирования заданий или с объектами WorkRequest для выполнения других операций.
Они работают вне вашего приложения, поэтому вы можете использовать их для запуска событий или действий, даже когда ваше приложение не запущено и даже если само устройство находится в спящем режиме.
Они помогают минимизировать требования вашего приложения к ресурсам. Вы можете планировать операции, не полагаясь на таймеры или постоянно работающие службы.
Установить неточный будильник
Когда приложение устанавливает неточное оповещение , система отправляет его в какой-то момент в будущем. Неточные оповещения обеспечивают определенные гарантии относительно времени отправки сигнала тревоги, соблюдая при этом ограничения по экономии заряда батареи, такие как режим Doze .
Разработчики могут использовать следующие гарантии API для настройки времени доставки неточных оповещений.
Подать сигнал тревоги через определенное время
Если ваше приложение вызывает методы set() , setInexactRepeating() или setAndAllowWhileIdle() , будильник никогда не сработает раньше заданного времени срабатывания.
В Android 12 (уровень API 31) и выше система включает будильник в течение одного часа после заданного времени срабатывания, если не действуют какие-либо ограничения по энергосбережению, такие как режим экономии заряда батареи или режим Doze .
Отправить оповещение в заданный временной интервал.
Если ваше приложение вызывает setWindow() , будильник никогда не сработает раньше указанного времени срабатывания. Если не действуют ограничения по экономии заряда батареи, будильник будет отправлен в течение указанного временного окна, начиная с заданного времени срабатывания.
Если ваше приложение ориентировано на Android 12 или выше, система может задерживать срабатывание будильника с неточным временным интервалом как минимум на 10 минут. По этой причине значения параметра windowLengthMillis меньше 600000 обрезаются до 600000 .
Подавайте повторяющийся сигнал тревоги примерно через равные промежутки времени.
Если ваше приложение вызывает setInexactRepeating() , система запускает несколько оповещений:
- Первый сигнал тревоги срабатывает в течение указанного временного интервала, начиная с заданного момента срабатывания.
- Последующие сигналы тревоги обычно срабатывают по истечении указанного временного интервала. Время между двумя последовательными срабатываниями сигнала тревоги может варьироваться.
Установите точный будильник.
Система подает сигнал тревоги точно в точно определенный момент в будущем.
Большинство приложений могут планировать задачи и события, используя неточные будильники, для решения ряда распространенных задач . Если основная функциональность вашего приложения зависит от будильника с точным временем срабатывания — например, для приложения-будильника или приложения-календаря — то использование точного будильника допустимо.
Сценарии использования, которые могут не требовать точных сигналов тревоги
Ниже представлен список распространенных рабочих процессов, для которых может не потребоваться точное оповещение:
- Планирование операций по синхронизации на протяжении всего жизненного цикла вашего приложения.
- Класс
Handlerвключает в себя несколько полезных методов для обработки операций, связанных со временем выполнения, например, выполнения некоторой работы каждые n секунд, пока ваше приложение работает:postAtTime()иpostDelayed(). Обратите внимание, что эти API зависят от времени работы системы , а не от реального времени . - Запланированные фоновые работы, такие как обновление вашего приложения и загрузка журналов.
-
WorkManagerпредоставляет возможность планирования периодических работ, чувствительных ко времени . Вы можете указать интервал повторения иflexInterval(минимум 15 минут), чтобы определить точное время выполнения работы. - Указанное пользователем действие, которое должно произойти по истечении определенного времени (даже если система находится в режиме ожидания).
- Используйте неточный сигнал тревоги. В частности, вызовите метод
setAndAllowWhileIdle(). - Указанное пользователем действие, которое должно произойти по истечении определенного времени.
- Используйте неточный сигнал тревоги. В частности, вызовите метод
set(). - Действие, заданное пользователем, которое может произойти в течение указанного временного интервала.
- Используйте неточный будильник. В частности, вызовите
setWindow(). Обратите внимание, что если ваше приложение ориентировано на Android 12 или выше, минимальная допустимая длина окна составляет 10 минут.
Способы установки точного времени будильника
Ваше приложение может устанавливать точные оповещения одним из следующих способов. Эти методы расположены в порядке убывания важности: те, что находятся ближе к концу списка, выполняют более критичные по времени задачи, но требуют больше системных ресурсов.
-
setExact() Срабатывание будильника возможно практически в точно назначенное время в будущем, при условии, что другие меры по экономии заряда батареи не активированы.
Используйте этот метод для установки точных напоминаний, если только работа вашего приложения не является критически важной с точки зрения времени для пользователя.
-
setExactAndAllowWhileIdle() Срабатывание сигнализации возможно практически в точно заданное время в будущем, даже если действуют меры по экономии заряда батареи.
-
setAlarmClock() Система активирует оповещение в точно назначенное время в будущем. Поскольку эти оповещения хорошо видны пользователям, время их отправки никогда не корректируется. Система определяет эти оповещения как наиболее критические и при необходимости переходит в режим пониженного энергопотребления для отправки оповещений.
Потребление системных ресурсов
Когда система срабатывает точно по тем же сигналам, что и ваше приложение, устройство потребляет много ресурсов, например, заряда батареи, особенно если оно находится в режиме энергосбережения. Кроме того, система не может легко объединять эти запросы в пакеты для более эффективного использования ресурсов.
Настоятельно рекомендуется по возможности создавать неточные будильники . Для выполнения более длительных задач запланируйте их с помощью WorkManager или JobScheduler из BroadcastReceiver вашего будильника. Для выполнения задач, когда устройство находится в режиме Doze, создайте неточный будильник с помощью setAndAllowWhileIdle() и запустите задание из этого будильника.
Укажите соответствующее точное разрешение на подачу сигнала тревоги.
Если ваше приложение ориентировано на Android 12 или выше, вам необходимо получить специальный доступ к разделу «Будильники и напоминания». Для этого объявите разрешение SCHEDULE_EXACT_ALARM в файле манифеста вашего приложения, как показано в следующем фрагменте кода:
<manifest ...> <uses-permission android:name="android.permission.SCHEDULE_EXACT_ALARM"/> <application ...> ... </application> </manifest>
Если ваше приложение ориентировано на Android 13 (уровень API 33) или выше, у вас есть возможность объявить либо разрешение SCHEDULE_EXACT_ALARM , либо USE_EXACT_ALARM .
<manifest ...> <uses-permission android:name="android.permission.USE_EXACT_ALARM"/> <application ...> ... </application> </manifest>
Хотя разрешения SCHEDULE_EXACT_ALARM и USE_EXACT_ALARM указывают на одни и те же возможности, они предоставляются по-разному и поддерживают разные сценарии использования. Ваше приложение должно использовать точные оповещения и объявлять разрешение SCHEDULE_EXACT_ALARM или USE_EXACT_ALARM только в том случае, если функция, взаимодействующая с пользователем в вашем приложении, требует действий, выполняемых точно по времени.
USE_EXACT_ALARM
- Предоставляется автоматически
- Отменить пользователем невозможно.
- В соответствии с предстоящей политикой Google Play.
- Ограниченные варианты использования
SCHEDULE_EXACT_ALARM
- Предоставлено пользователем
- Более широкий набор вариантов использования
- Приложения должны подтвердить, что разрешение не было отозвано.
Разрешение SCHEDULE_EXACT_ALARM не предоставляется автоматически при новой установке приложений, ориентированных на Android 13 (уровень API 33) и выше. Если пользователь переносит данные приложения на устройство под управлением Android 14 с помощью операции резервного копирования и восстановления, разрешение SCHEDULE_EXACT_ALARM будет отклонено на новом устройстве. Однако, если существующее приложение уже имеет это разрешение, оно будет предоставлено автоматически при обновлении устройства до Android 14.
Примечание : Если точное время срабатывания сигнализации задано с помощью объекта OnAlarmListener , например, с использованием API setExact , разрешение SCHEDULE_EXACT_ALARM не требуется.
Использование разрешения SCHEDULE_EXACT_ALARM
В отличие от USE_EXACT_ALARM , разрешение SCHEDULE_EXACT_ALARM должно быть предоставлено пользователем. И пользователь, и система могут отозвать разрешение SCHEDULE_EXACT_ALARM .
Чтобы проверить, предоставлено ли вашему приложению разрешение, вызовите функцию canScheduleExactAlarms() перед попыткой установить точное оповещение. Когда разрешение SCHEDULE_EXACT_ALARM будет отозвано для вашего приложения, ваше приложение остановится, и все будущие точные оповещения будут отменены. Это также означает, что значение, возвращаемое функцией canScheduleExactAlarms() останется действительным на протяжении всего жизненного цикла вашего приложения.
Когда вашему приложению предоставляется разрешение SCHEDULE_EXACT_ALARMS , система отправляет ему широковещательное сообщение ACTION_SCHEDULE_EXACT_ALARM_PERMISSION_STATE_CHANGED . Ваше приложение должно реализовать приемник широковещательных сообщений , который выполняет следующие действия:
- Подтверждает, что ваше приложение по-прежнему имеет специальный доступ. Для этого вызовите метод
canScheduleExactAlarms(). Эта проверка защитит ваше приложение от ситуации, когда пользователь предоставляет приложению разрешение, а затем почти сразу же отзывает его. - Перепланирует все необходимые вашему приложению оповещения в зависимости от его текущего состояния. Эта логика должна быть аналогична той, что используется в вашем приложении при получении широковещательного сообщения
ACTION_BOOT_COMPLETED.
Предложите пользователям предоставить разрешение SCHEDULE_EXACT_ALARM
При необходимости вы можете перенаправить пользователей на экран «Оповещения и напоминания» в настройках системы, как показано на рисунке 1. Для этого выполните следующие шаги:
- В пользовательском интерфейсе вашего приложения объясните пользователю, почему вашему приложению необходимо устанавливать точные даты будильников.
- Вызовите интент, включающий действие
ACTION_REQUEST_SCHEDULE_EXACT_ALARM.
Установите повторяющийся будильник
Функция повторных оповещений позволяет системе уведомлять ваше приложение по заданному расписанию.
Неправильно спроектированный будильник может привести к быстрому разряду батареи и значительной нагрузке на серверы. По этой причине в Android 4.4 (уровень API 19) и выше все повторяющиеся будильники являются неточными .
Повторяющаяся сигнализация обладает следующими характеристиками:
Тип сигнала тревоги. Подробнее см. раздел «Выбор типа сигнала тревоги» .
Время срабатывания. Если указанное вами время срабатывания относится к прошлому, сигнал тревоги сработает немедленно.
Интервал срабатывания сигнала тревоги. Например, раз в день, каждый час или каждые 5 минут.
Ожидающее срабатывание намерения, которое происходит при активации будильника. При установке второго будильника, использующего то же ожидающее срабатывание намерения, он заменяет исходный будильник.
Чтобы отменить PendingIntent() , передайте флаг FLAG_NO_CREATE в PendingIntent.getService() , чтобы получить экземпляр намерения (если он существует), а затем передайте это намерение в AlarmManager.cancel()
Котлин
val alarmManager = context.getSystemService(Context.ALARM_SERVICE) as? AlarmManager val pendingIntent = PendingIntent.getService(context, requestId, intent, PendingIntent.FLAG_NO_CREATE) if (pendingIntent != null && alarmManager != null) { alarmManager.cancel(pendingIntent) }
Java
AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE); PendingIntent pendingIntent = PendingIntent.getService(context, requestId, intent, PendingIntent.FLAG_NO_CREATE); if (pendingIntent != null && alarmManager != null) { alarmManager.cancel(pendingIntent); }
Выберите тип сигнализации
Одним из первых вопросов, которые следует рассмотреть при использовании повторяющейся сигнализации, является выбор её типа.
Для будильников используются два основных типа времени: «прошедшее реальное время» и «часы реального времени» (RTC). В качестве эталона для «прошедшего реального времени» используется «время с момента загрузки системы», а для часов реального времени — время UTC (общее время). Это означает, что «прошедшее реальное время» подходит для установки будильника на основе истечения времени (например, будильника, срабатывающего каждые 30 секунд), поскольку на него не влияют часовой пояс или локаль. Тип часов реального времени лучше подходит для будильников, зависящих от текущей локали.
Оба типа имеют версию «пробуждения», которая активирует процессор устройства, если экран выключен. Это гарантирует срабатывание будильника в запланированное время. Это полезно, если ваше приложение имеет временную зависимость. Например, если у него есть ограниченное время для выполнения определенной операции. Если вы не используете версию «пробуждения» для вашего типа будильника, то все повторяющиеся будильники сработают, когда ваше устройство снова будет включено.
Если вам просто нужно, чтобы будильник срабатывал через определенный интервал (например, каждые полчаса), используйте один из типов будильника, работающих в режиме реального времени. В целом, это лучший выбор.
Если вам нужно, чтобы будильник срабатывал в определенное время суток, выберите один из типов будильника, основанных на реальном времени. Однако следует отметить, что у этого подхода могут быть некоторые недостатки. Приложение может плохо адаптироваться к другим языковым стандартам, и если пользователь изменит настройки времени на устройстве, это может привести к неожиданному поведению вашего приложения. Использование будильника, основанного на реальном времени, также плохо масштабируется, как обсуждалось выше. Мы рекомендуем использовать будильник, основанный на «прошедшем времени», если это возможно.
Вот список типов:
ELAPSED_REALTIME: Запускает ожидающее намерение на основе времени, прошедшего с момента загрузки устройства, но не пробуждает его. Прошедшее время включает в себя любое время, в течение которого устройство находилось в спящем режиме.ELAPSED_REALTIME_WAKEUP: Просыпает устройство и запускает ожидающее намерение по истечении указанного промежутка времени с момента загрузки устройства.RTC: Запускает ожидающее намерение в указанное время, но не пробуждает устройство.RTC_WAKEUP: Пробуждает устройство для запуска ожидающего намерения в указанное время.
Примеры сигналов тревоги, срабатывающих в режиме реального времени.
Вот несколько примеров использования ELAPSED_REALTIME_WAKEUP
Включите устройство, чтобы оно сработало будильник через 30 минут, а затем каждые 30 минут:
Котлин
// Hopefully your alarm will have a lower frequency than this! alarmMgr?.setInexactRepeating( AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR, AlarmManager.INTERVAL_HALF_HOUR, alarmIntent )
Java
// Hopefully your alarm will have a lower frequency than this! alarmMgr.setInexactRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + AlarmManager.INTERVAL_HALF_HOUR, AlarmManager.INTERVAL_HALF_HOUR, alarmIntent);
Активируйте устройство, чтобы оно сработало один раз (без повторов) через одну минуту:
Котлин
private var alarmMgr: AlarmManager? = null private lateinit var alarmIntent: PendingIntent ... alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent -> PendingIntent.getBroadcast(context, 0, intent, 0) } alarmMgr?.set( AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 60 * 1000, alarmIntent )
Java
private AlarmManager alarmMgr; private PendingIntent alarmIntent; ... alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE); Intent intent = new Intent(context, AlarmReceiver.class); alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0); alarmMgr.set(AlarmManager.ELAPSED_REALTIME_WAKEUP, SystemClock.elapsedRealtime() + 60 * 1000, alarmIntent);
Примеры будильников реального времени.
Вот несколько примеров использования RTC_WAKEUP .
Включите устройство, чтобы сработал будильник примерно в 14:00, и повторяйте это один раз в день в то же время:
Котлин
// Set the alarm to start at approximately 2:00 p.m. val calendar: Calendar = Calendar.getInstance().apply { timeInMillis = System.currentTimeMillis() set(Calendar.HOUR_OF_DAY, 14) } // With setInexactRepeating(), you have to use one of the AlarmManager interval // constants--in this case, AlarmManager.INTERVAL_DAY. alarmMgr?.setInexactRepeating( AlarmManager.RTC_WAKEUP, calendar.timeInMillis, AlarmManager.INTERVAL_DAY, alarmIntent )
Java
// Set the alarm to start at approximately 2:00 p.m. Calendar calendar = Calendar.getInstance(); calendar.setTimeInMillis(System.currentTimeMillis()); calendar.set(Calendar.HOUR_OF_DAY, 14); // With setInexactRepeating(), you have to use one of the AlarmManager interval // constants--in this case, AlarmManager.INTERVAL_DAY. alarmMgr.setInexactRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(), AlarmManager.INTERVAL_DAY, alarmIntent);
Включите устройство, чтобы будильник сработал ровно в 8:30 утра, а затем каждые 20 минут:
Котлин
private var alarmMgr: AlarmManager? = null private lateinit var alarmIntent: PendingIntent ... alarmMgr = context.getSystemService(Context.ALARM_SERVICE) as AlarmManager alarmIntent = Intent(context, AlarmReceiver::class.java).let { intent -> PendingIntent.getBroadcast(context, 0, intent, 0) } // Set the alarm to start at 8:30 a.m. val calendar: Calendar = Calendar.getInstance().apply { timeInMillis = System.currentTimeMillis() set(Calendar.HOUR_OF_DAY, 8) set(Calendar.MINUTE, 30) } // setRepeating() lets you specify a precise custom interval--in this case, // 20 minutes. alarmMgr?.setRepeating( AlarmManager.RTC_WAKEUP, calendar.timeInMillis, 1000 * 60 * 20, alarmIntent )
Java
private AlarmManager alarmMgr; private PendingIntent alarmIntent; ... alarmMgr = (AlarmManager)context.getSystemService(Context.ALARM_SERVICE); Intent intent = new Intent(context, AlarmReceiver.class); alarmIntent = PendingIntent.getBroadcast(context, 0, intent, 0); // Set the alarm to start at 8:30 a.m. Calendar calendar = Calendar.getInstance(); calendar.setTimeInMillis(System.currentTimeMillis()); calendar.set(Calendar.HOUR_OF_DAY, 8); calendar.set(Calendar.MINUTE, 30); // setRepeating() lets you specify a precise custom interval--in this case, // 20 minutes. alarmMgr.setRepeating(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(), 1000 * 60 * 20, alarmIntent);
Определите, насколько точным должен быть ваш сигнал тревоги.
Как уже описывалось ранее, выбор типа будильника часто является первым шагом в его создании. Ещё одним важным моментом является требуемая точность будильника. Для большинства приложений правильным выбором будет метод setInexactRepeating() . При использовании этого метода Android синхронизирует несколько неточно повторяющихся будильников и запускает их одновременно. Это снижает расход заряда батареи.
По возможности избегайте использования точных будильников. Однако для редких приложений с жесткими временными требованиями можно установить точный будильник , вызвав setRepeating() .
С помощью setInexactRepeating() нельзя задать пользовательский интервал так же, как с setRepeating() . Необходимо использовать одну из констант интервала, например INTERVAL_FIFTEEN_MINUTES , INTERVAL_DAY и так далее. Полный список см. в AlarmManager .
Отключить будильник
В зависимости от вашего приложения, вам может потребоваться добавить возможность отмены будильника. Чтобы отменить будильник, вызовите метод cancel() в Alarm Manager, передав в качестве PendingIntent , который вы больше не хотите запускать. Например:
Котлин
// If the alarm has been set, cancel it. alarmMgr?.cancel(alarmIntent)
Java
// If the alarm has been set, cancel it. if (alarmMgr!= null) { alarmMgr.cancel(alarmIntent); }
Настроить будильник при перезагрузке устройства
По умолчанию все сигналы тревоги отменяются при выключении устройства. Чтобы этого избежать, вы можете настроить приложение таким образом, чтобы оно автоматически перезапускало повторяющийся сигнал тревоги при перезагрузке устройства пользователем. Это гарантирует, что AlarmManager продолжит выполнять свою задачу без необходимости ручного перезапуска сигнала тревоги пользователем.
Вот шаги:
Установите разрешение
RECEIVE_BOOT_COMPLETEDв манифесте вашего приложения. Это позволит вашему приложению получать широковещательное сообщениеACTION_BOOT_COMPLETED, которое отправляется после завершения загрузки системы (это работает только в том случае, если приложение уже было запущено пользователем хотя бы один раз):<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"/>Реализуйте объект
BroadcastReceiverдля приема широковещательных сообщений:Котлин
class SampleBootReceiver : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { if (intent.action == "android.intent.action.BOOT_COMPLETED") { // Set the alarm here. } } }
Java
public class SampleBootReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals("android.intent.action.BOOT_COMPLETED")) { // Set the alarm here. } } }
Добавьте получателя в файл манифеста вашего приложения с фильтром намерений, который фильтрует по действию
ACTION_BOOT_COMPLETED:<receiver android:name=".SampleBootReceiver" android:enabled="false"> <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED"></action> </intent-filter> </receiver>
Обратите внимание, что в манифесте для обработчика загрузки установлено значение
android:enabled="false". Это означает, что обработчик не будет вызываться, если приложение явно его не включит. Это предотвращает ненужные вызовы обработчика загрузки. Вы можете включить обработчик (например, если пользователь устанавливает будильник) следующим образом:Котлин
val receiver = ComponentName(context, SampleBootReceiver::class.java) context.packageManager.setComponentEnabledSetting( receiver, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP )
Java
ComponentName receiver = new ComponentName(context, SampleBootReceiver.class); PackageManager pm = context.getPackageManager(); pm.setComponentEnabledSetting(receiver, PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP);
После включения таким способом приемник останется включенным, даже если пользователь перезагрузит устройство. Другими словами, программное включение приемника переопределяет настройку в манифесте, даже после перезагрузки. Приемник будет оставаться включенным до тех пор, пока ваше приложение его не отключит. Вы можете отключить приемник (например, если пользователь отменяет будильник) следующим образом:
Котлин
val receiver = ComponentName(context, SampleBootReceiver::class.java) context.packageManager.setComponentEnabledSetting( receiver, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP )
Java
ComponentName receiver = new ComponentName(context, SampleBootReceiver.class); PackageManager pm = context.getPackageManager(); pm.setComponentEnabledSetting(receiver, PackageManager.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP);
Включение будильников, когда устройство находится в режиме Doze.
Устройства под управлением Android 6.0 (уровень API 23) поддерживают режим Doze , который помогает продлить время работы батареи. В режиме Doze будильники не срабатывают. Все запланированные будильники откладываются до тех пор, пока устройство не выйдет из режима Doze. Если вам необходимо завершить работу, даже когда устройство находится в режиме ожидания, доступно несколько вариантов:
Установите точный будильник .
Используйте API WorkManager, предназначенный для выполнения фоновых задач. Вы можете указать системе, что она должна ускорить вашу работу, чтобы она завершилась как можно быстрее. Для получения дополнительной информации см. раздел «Планирование задач с помощью WorkManager».
Передовые методы
Каждый ваш выбор при разработке повторяющегося будильника может иметь последствия для того, как ваше приложение использует (или злоупотребляет) системными ресурсами. Например, представьте себе популярное приложение, которое синхронизируется с сервером. Если операция синхронизации основана на времени, и каждый экземпляр приложения синхронизируется в 23:00, нагрузка на сервер может привести к высокой задержке или даже к «отказу в обслуживании». Следуйте этим рекомендациям по использованию будильников:
Добавьте элемент случайности (джиттер) ко всем сетевым запросам, которые возникают в результате повторяющегося сигнала тревоги:
При срабатывании сигнализации выполняйте любые локальные действия. Под «локальными действиями» понимается всё, что не обращается к серверу и не требует данных с сервера.
Одновременно с этим настройте срабатывание будильника, содержащего сетевые запросы, в случайный промежуток времени.
Сведите частоту срабатывания будильника к минимуму.
Не включайте устройство без необходимости (это поведение определяется типом будильника, как описано в разделе «Выбор типа будильника »).
Не устанавливайте время срабатывания будильника с точностью, превышающей необходимую.
Используйте
setInexactRepeating()вместоsetRepeating(). При использованииsetInexactRepeating()Android синхронизирует повторяющиеся будильники из нескольких приложений и запускает их одновременно. Это уменьшает общее количество раз, когда система должна разбудить устройство, тем самым снижая расход заряда батареи. Начиная с Android 4.4 (уровень API 19), все повторяющиеся будильники являются неточными . Обратите внимание, что хотяsetInexactRepeating()является улучшением по сравнению сsetRepeating(), он все еще может перегрузить сервер, если каждый экземпляр приложения обращается к серверу примерно в одно и то же время. Поэтому для сетевых запросов добавьте некоторую случайность в ваши будильники, как обсуждалось ранее.По возможности избегайте установки будильника по времени на часах.
Повторяющиеся сигналы тревоги, срабатывающие по точно заданному времени, плохо масштабируются. По возможности используйте
ELAPSED_REALTIME. Различные типы сигналов тревоги описаны более подробно в следующем разделе.