Должен ли я использовать AlarmManager или Handler?

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

Solutions Collecting From Web of "Должен ли я использовать AlarmManager или Handler?"

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

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

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

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

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

Но большую часть времени он НЕ РАБОТАЛ для меня. Поэтому я приобрел свои собственные блокировки в режиме onReceive() и выпустил их в конце, чтобы убедиться, что я действительно получаю CPU.

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

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

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

Хотя это согласовано, они в основном работают для API 23. Это новый выпуск.

Блок-схема для фоновой работы, аварийных сигналов и вашего приложения для Android