Должен ли я использовать AlarmManager или обработчик?

Я пишу приложение, которое постоянно опрашивает датчики устройства и время от времени должно записывать некоторую статистику в файл. Это может быть так же быстро, как раз в секунду или так же медленно, как раз в минуту. Должен ли я использовать Handler's postDelayed() метод или просто запланируйте его с помощью AlarmManager?

4 ответов


Я бы сказал, что это зависит от интервала опроса. Я думаю, что это довольно низко в вашем случае (около нескольких секунд), поэтому вы должны пойти обработчиком или с помощью класса Timer.

AlarmManger - это гораздо более высокий уровень обслуживания, и он включает в себя большие накладные расходы для обработки этого варианта использования. Когда срабатывает сигнал тревоги, вам нужно обработать его с помощью BroadcastReceivers. Это означает, что каждый раз, когда вы обрабатываете один из этих сигналов тревоги, вам нужно зарегистрировать слушателей для датчиков, которые вас интересуют, что очень неэффективно имхо.


Это должно помочь вам различать Handler и AlarmManager. [источник]

хотя, по общему мнению, они в основном работают для API 23. Это новый релиз.

A flowchart for background work, alarms, and your Android app


решите свой дизайн на основе следующих ключевых моментов:

AlarmManager: Преимущество с AlarmManager это работает, даже если устройство находится в глубоком спящем режиме (CPU выключен). Когда срабатывает сигнализация, она попадает в BroadcastReceiver и onReceive, он получает блокировку пробуждения (если вы использовали WAKEUP типы тревог, такие как RTC_WAKEUP или ELAPSED_TIME_WAKEUP). После окончания onReceive() он освобождает замок проснуться.

но в большинстве случаев это не сработало для меня. Так Что Я ... приобрел свои собственные замки wake в onReceive() и выпустил их в конце, чтобы убедиться, что я действительно получаю CPU.

причина, по которой это не сработало, заключается в том, что, когда несколько приложений одновременно используют ресурс (например, блокировки пробуждения, которые предотвращают приостановку системы), платформа распределяет потребление ЦП по этим приложениям, хотя и не обязательно одинаково. Поэтому, если это критично, всегда лучше приобретать замки пробуждения и делать вещи.

таймеры и обработчики: Handler и таймеры не работают в режиме глубокого сна, что означает, что задача/runnable не будет работать по расписанию, когда устройство спит. Они не учитывают время сна, что означает, что задержка выполнения задачи будет рассчитываться только в активном режиме. Таким образом, фактическая задержка будет задержка + время, проведенное в глубоком сне.


если приложение должно работать в режиме ожидания нажмите AlarmManager. Если нет, то Handler.
AlarmManager разбудит процессор, поэтому он будет разряжать батарею больше, в то время как Handler не будет работать в режиме ожидания.