Подтвердить что ты не робот

В чем разница между слушателем и получателем (Android)?

Например, для получения этих событий мне нужен BroadcastReceiver:

REBOOT или SHUTDOWN

ВКЛ или ВЫКЛ ЭКРАН

состояние батареи (напряжение, напряжение, температура)

физические нажатия кнопок (камера, носитель и т.д.)

Но мне нужно, чтобы Listener получал эти события:

EventListener для событий датчиков (ускорение, магнитные поля, ориентация, близость, температура, уровень освещенности и т.д.)

LocationListener для событий местоположения (местоположение сети, GPS)

Кажется, что оба приемника и прослушиватели существуют, чтобы я мог получать события. В отличие от очевидных семантических различий, какая разница между ними? Есть ли что-то, что я могу сделать в одном, но не в другом, особенно в отношении таких вещей, как то, сколько процессора я могу взять и запустить, пока экран выключен? Почему существуют две совершенно разные конструкции для целей получения событий?

4b9b3361

Ответ 1

Есть так много различий между этими двумя, они реагируют на что-то одно из единственных сходств.

Различия:

  • BroadcastReceivers получают Intents, тогда как Listener может делать в основном что угодно, поскольку у него нет определенной цели, это просто соглашение об именах. Например, найдите "BroadcastReceiver" на веб-сайте dev, затем найдите "Слушатель"

  • BroadcastReceivers просто получают трансляцию Intent Broadcast, которая не является прямой, Listeners вызывается явно.

  • A BroadcastReceiver - это свой собственный определенный класс, поскольку он имеет определенную цель (получение намерений), тогда как Listeners может быть чем угодно - они обычно являются interface, и они предоставляются таким образом, что обратные вызовы могут быть сделаны из одного класса в другой.

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

  • События, которые получает BroadcastReceiver, обычно являются не непрерывными событиями (один снимок), тогда как Listeners, в зависимости от того, что они делают, может использоваться для постоянных обновлений (непрерывный).

  • BroadcastReceivers могут быть созданы системой, если они объявлены в манифесте, слушатели только динамически создаются (поэтому через код).

  • Использование CPU/Power зависит от реализации обоих, тем более что, как упоминалось выше, Listeners может быть чем-либо.

Есть ли что-то, что я могу сделать в одном, но не в другом, особенно в отношении таких вещей, как количество процессора, которое я могу выполнять и запускать, когда экран выключен?

BroadcastReceivers имеют 10 секунд гарантированного времени выполнения. Слушатели, поскольку они не служат определенной цели, не имеют этого предела.

Что вы определенно не можете сделать из BroadcastReceiver:

В частности, вы не можете показывать диалог или привязываться к службе из внутри BroadcastReceiver.

Скорее всего, это то, к чему я придумал.

Ответ 2

Broad Cast Receiver похож на Sigma, а Event Listener похож на интеграцию в математику, и это суммирование...

  • Sigma: используйте это, когда нам нужно суммирование в дискретных интерполях....
  • Интеграл: используйте это, когда нам нужно непрерывное суммирование...

Таким же образом, как широковещательный приемник, так и приемник событий используются для прослушивания событий. Новейший приемник Broad Cast используется для прослушивания очень важных событий, таких как BATTERY_CHANGED, BATTERY_LOW, BOOT_COMPLETED, CALL ETC и обновления Event Lister. Непрерывные изменения в событии как LOCATION CHANGED, FOCUS GAINED ETC.

Ответ 3

Оба прослушивателя и приемника действуют как обработчики триггеров, однако из-за этого их происхождение и характеристики этих триггеров отделяют их.

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

Кроме того, приложениям не требуется запускать Intents. Усилия могут выступать в качестве будильника для пробуждения приложений при срабатывании события. Это экономит аккумулятор и процессор.

Ответ 4

Основное отличие может заключаться в следующем:

Событие Listeneres имеет более непрерывную форму, то есть события, такие как связанные с датчиками или нажатиями кнопок чаще.

Но приемник носит прерывистый характер, т.е. события здесь не так непрерывны, например, Boot on/off, message etc