EventBus vs Callbacks, который следует использовать, когда?

У меня много действий, которые поднимают фоновые задачи; Деятельность будет проходить через выполнение обратного вызова слушателя, так что фоновые задачи могут вызвать событие в Деяниях. Действия, в свою очередь, могут показать что-то в пользовательском интерфейсе, чтобы указать, что фоновый актив прошел или не прошел.

В качестве альтернативы я мог бы использовать EventBus, в котором я получаю активность для регистрации себя в качестве слушателя/подписчика. У меня могут быть фоновые задачи, которые вызывают событие на EventBus, и прослушивание активности может обрабатывать его.

Каковы преимущества одного над другим? Когда вы будете использовать один над другим? (Чистота кода? Производительность? Предостережения?)

Последующие действия - я в конечном итоге использовал EventBus. Код, безусловно, намного чище, и повсюду повсюду висят звонки. IDE (IntelliJ) считает, что методы onEvent не используются, поэтому я создал аннотацию

@Target({ElementType.METHOD})
public @interface EventBusHook {}

и поместил его поверх моих методов onEvent. Затем Alt + нажал на него и попросил IntelliJ не рассматривать его как неиспользованный.

@EventBusHook
public void onEvent(MyEventType myEventType){

Ответы

Ответ 1

Преимущества использования EventBus:

  • Ваш код будет выглядеть намного более чистым.
  • Ваш код станет более модульным, что позволит вам легко создать тестовый пример для вашего кода.
  • Избегайте утечек памяти из ссылок на плохие объекты, которые блокируют объект и не позволяют сборщику мусора очистить его.
  • Возможно, у нескольких приемников есть время, что это похоже на вещание
  • Упростите несколько интерфейсов в один, EventBus
  • В классе интерфейса вам необходимо переопределить каждый метод в унаследованном классе. С EventBus вы можете слушать только событие, которое вы действительно хотите.

Но плохая часть - это может быть немного больше головной боли с объявлением функции, так как IDE не может помочь вам с автозаполнением.

Мое предложение: если вы обнаружите, что вам нужно создать пользовательский прослушиватель, то, пожалуйста, рассмотрите EventBus, это может быть лучшим выбором для большинства (если не всех) ваших требований/случаев.

В любом случае, это все ваш выбор после всех =)

Ответ 2

Я не согласен с ответом @nnuneoi.

Шина событий имеет только одно преимущество: она позволяет общаться между компонентами, которые "не знают" о существовании друг друга.

И есть несколько недостатков:

  • Компоненты становятся слабо связанными за счет зависимости как от шины событий, так и от конкретного типа события
  • Связь, описанная в № 1 выше, не является сильной.
  • Связь, описанная в № 1 выше, не очевидна.
  • Шина событий вводит служебные данные по производительности при простых обратных вызовах
  • Если шина событий содержит сильную ссылку на подписчиков (как это имеет место, например, GreenRobot EventBus), то незарегистрированные подписчики будут вызывать утечки памяти

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

Шина событий должна использоваться только тогда, когда прямое соединение нежелательно или сложно реализовать. Например:

  • Отправка событий от Service до Activity
  • Обмен событиями между независимыми Fragments
  • Широкие события приложений (например, вход/выход пользователей)

Если коммуникационные компоненты уже "осведомлены" о существовании друг друга, им не нужно общаться через шину событий.

Ответ 3

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

Механизм Event-Bus прав, если у вас действительно есть отношения между издателем и подписчиком. Событие должно быть полностью независимым от получателя.

Таким образом, абонент, который отбрасывает событие по любой причине ответственности ( "Я не несу ответственность за событие, даже если я зарегистрирован" ), является сильным индикатором того, что использование Event-Bus неверно. Затем вам следует рассмотреть возможность использования выделенных слушателей.

Ответ 4

Я бы пошел с EventBus из-за слабой связи и чистого кода. Кроме того, тот факт, что использование EventBus, такого как Greenrobot, автоматически делает весь шаблон для меня и позволяет мне зарегистрироваться & Отмена регистрации наблюдателей прямо из методов Activity Lifecycle (onStart и onDestroy | onStop) - это здорово. Реализация обратных вызовов и все еще управление контролем Управление жизненным циклом операций для этих обратных вызовов является ненужной головной болью и включает в себя множество ненужных шаблонов.

Кроме того, очевидно, что все сборщики мусора считают, что слабая ссылка - это здорово. Шина -Event дает вашим наблюдателям и компонентам именно это. Это основа шаблона наблюдателя.