EventBus: co to jest, zasada działania i magistrala zdarzeń Android

Co to jest EventBus?

EventBus to biblioteka magistrali zdarzeń dla Android, implementująca wzorzec Publisher-Subscriber (wydawca-subskrybent). Umożliwia przesyłanie zdarzeń między komponentami aplikacji (Activity, Fragment, Service, ViewModel) bez tworzenia jawnych zależności między nimi. W przeciwieństwie do standardowych mechanizmów Android (Intent, BroadcastReceiver), EventBus działa wewnątrz procesu i nie używa IPC. Biblioteka jest zoptymalizowana pod kątem wydajności i nie używa refleksji przy poprawnie skonfigurowanym Subscriber Index.

GreenRobot EventBus: architektura

Architektura EventBus składa się z trzech kluczowych elementów: Event (klasa POJO z danymi), Subscriber (obiekt z metodami oznaczonymi @Subscribe) i EventBus (centralny dyspozytor). Subskrybent rejestruje się przez EventBus.getDefault().register(this), wypisanie — przez unregister(this). Zdarzenia są typowane: obsługi subskrybują konkretną klasę zdarzenia i są wywoływane tylko przy post zdarzenia tej klasy lub jej podklas.

// Zdarzenie POJO
data class MessageEvent(
    val message: String,
    val timestamp: Long = System.currentTimeMillis()
)

// Subskrybent w Activity
class MainActivity : AppCompatActivity() {

    override fun onStart() {
        super.onStart()
        EventBus.getDefault().register(this)
    }

    override fun onStop() {
        EventBus.getDefault().unregister(this)
        super.onStop()
    }

    @Subscribe(threadMode = ThreadMode.MAIN)
    fun onMessageEvent(event: MessageEvent) {
        textView.text = event.message
    }
}

// Wysyłanie zdarzenia z innego komponentu
EventBus.getDefault().post(MessageEvent("Hello from Service"))

Subscriber Index dla wydajności

Domyślnie EventBus używa refleksji do wyszukiwania metod @Subscribe przy register(). Subscriber Index generuje indeks obsług na etapie kompilacji przez procesor adnotacji. Eliminuje to narzut refleksji i przyspiesza rejestrację. Aby włączyć, dodaj eventbus-annotation-processor w build.gradle. EventBus automatycznie używa indeksu, jeśli jest dostępny w classpath. Bez indeksu biblioteka nadal działa, ale z niewielkim spadkiem wydajności.

Jak działa EventBus w Android?

Przy wywołaniu EventBus.getDefault().post(event) biblioteka określa typ zdarzenia, znajduje wszystkich zarejestrowanych subskrybentów z metodami @Subscribe przyjmującymi ten typ i wywołuje je zgodnie z określonym ThreadMode. Wyszukiwanie subskrybentów odbywa się po mapie Class → CopyOnWriteArrayList, zbudowanej podczas rejestracji. Jeśli zdarzenie nie ma subskrybentów, post kończy się bez błędu — to safe-fail zachowanie.

Cykl życia rejestracji

Subskrybent powinien zarejestrować się w onStart() i wyrejestrować w onStop(). Jeśli zarejestruje się w onCreate() i wypisze w onDestroy(), Activity zniszczona bez wywołania onDestroy (z powodu finish()) może pozostać na liście subskrybentów. Wyciek subskrybenta — jeden z głównych problemów EventBus: Activity pozostające na liście subskrybentów nie zostanie zebrane przez GC, dopóki się nie wypisze. Zawsze łącz register/unregister w odpowiednich metodach lifecycle.

Priorytet obsług

Adnotacja @Subscribe obsługuje parametr priority (liczba całkowita, domyślnie 0). Obsługi z wyższym priorytetem są wywoływane wcześniej. cancelEventDelivery() umożliwia przerwanie dostarczania zdarzenia pozostałym subskrybentom. Jest to przydatne dla priorytetowych obsług (logowanie, uwierzytelnianie), które mogą anulować przetwarzanie zdarzenia przez niższe obsługi. Funkcja dostępna tylko w wątku wysyłania zdarzenia.

// Złożony przykład z priorytetem
data class NavigationEvent(val screen: String, val data: Bundle)

class NavigationInterceptor {
    @Subscribe(priority = 10, threadMode = ThreadMode.POSTING)
    fun onNavigationEvent(event: NavigationEvent) {
        if (event.screen == "restricted" && !isAuthorized) {
            EventBus.getDefault().cancelEventDelivery(event)
        }
    }
}

class AnalyticsLogger {
    @Subscribe(priority = 5)
    fun logNavigation(event: NavigationEvent) {
        analytics.logScreen(event.screen)
    }
}

// Wysyłanie zdarzenia
EventBus.getDefault().post(NavigationEvent("profile", bundle))

EventBus vs LocalBroadcastManager vs LiveData

Android oferuje kilka mechanizmów do komunikacji wewnątrzprocesowej: EventBus, LocalBroadcastManager (przestarzały) i LiveData/Flow. Każdy ma swoje zalety i wady. Wybór zależy od podejścia architektonicznego i wymagań dotyczących wydajności. Nowoczesne zalecenia Google skłaniają się ku LiveData i Flow ze względu na integrację z Lifecycle i brak wycieków.

Kiedy EventBus jest lepszy

EventBus jest przydatny w projektach z dużym dziedzictwem (legacy code) i gdzie LiveData/Flow są niedostępne (projekty Java-only). Sticky events EventBus dają elastyczność, której brakuje w LocalBroadcastManager. EventBus jest również prostszy do wysyłania zdarzeń z Service do Activity bez ViewModel — szczególnie gdy trzeba powiadomić o postępie zadania w tle. Biblioteka ma minimalny rozmiar (około 50 KB) i nie dodaje zależności.

Kiedy LiveData/Flow są lepsze

LiveData i Flow są częścią Android Jetpack i zintegrowane z Lifecycle. Automatycznie wypisują się przy zniszczeniu komponentu, eliminując wycieki pamięci. Flow obsługuje korutyny i złożone operatory transformacji. Google zaleca LiveData dla warstwy UI i Flow dla repozytoriów. EventBus pozostaje do zdarzeń cross-modułowych, gdzie nawigacja i logika biznesowa nie pasują do MVVM.

Subscribe i Post: podstawowe operacje

Subscribe — rejestracja obsługi zdarzenia przez adnotację @Subscribe. Metoda musi być public, void i przyjmować dokładnie jeden parametr — typ zdarzenia. Post — wysyłanie zdarzenia do wszystkich zapisanych obsług przez EventBus.getDefault().post(event). Metoda post nie zwraca wyniku i nie informuje, ile obsług zostało wywołanych. Dla zdarzeń z odpowiedzią użyj osobnej klasy Event z polem na wynik.

Tworzenie niestandardowych zdarzeń

Zdarzenie to dowolna klasa Java/Kotlin. Zaleca się używanie data class dla niezmiennych zdarzeń i zwykłej klasy dla zdarzeń z mutable-polami. Nazewnictwo zdarzeń powinno odzwierciedlać akcję: UserLoggedInEvent, DataLoadedEvent, NetworkErrorEvent. Unikaj jednej wspólnej klasy Event z polem String type — pozbawia to zalet typowania. Hierarchia zdarzeń (rodzicielski Event) umożliwia subskrypcję grupy pokrewnych zdarzeń.

// Hierarchia zdarzeń
open class UserEvent
data class UserLoggedIn(val userId: String) : UserEvent()
data class UserLoggedOut(val reason: String) : UserEvent()

// Subskrypcja klasy bazowej
class SessionManager {
    @Subscribe(threadMode = ThreadMode.MAIN)
    fun onUserEvent(event: UserEvent) {
        when (event) {
            is UserLoggedIn -> startSession(event.userId)
            is UserLoggedOut -> endSession(event.reason)
        }
    }
}

// Wysyłanie
EventBus.getDefault().post(UserLoggedIn("user_123"))

Rejestracja i wyrejestrowanie

Wywołanie EventBus.getDefault().register(this) skanuje klasę subskrybenta przez refleksję lub Subscriber Index i zapisuje znalezione metody @Subscribe w mapie zdarzeń. Unregister usuwa subskrybenta z mapy. Ponowna rejestracja bez wypisania — błąd (wystąpi MultipleSubscriberException). Dla Fragment rejestruj się w onStart() i wypisuj w onStop(). Dla Service — w onCreate() i onDestroy(). Dla ViewModel nie zaleca się — używaj LiveData.

Sticky Events i ThreadMode

Sticky event — zdarzenie, które jest przechowywane w EventBus po wysłaniu. Nowi subskrybenci zarejestrowani po postSticky() natychmiast otrzymują ostatnie sticky-zdarzenie odpowiedniego typu. Jest to wygodne do przekazywania stanu początkowego: przy otwarciu ekranu otrzymuje on ostatnie dane wysłane przed jego rejestracją. Usunąć sticky-zdarzenie można przez EventBus.getDefault().removeStickyEvent(Class).

ThreadMode: cztery tryby wykonania

ThreadMode określa, w którym wątku wywoływana jest obsługa. POSTING (domyślnie) — obsługa wykonuje się w tym samym wątku, w którym wywołano post. MAIN — obsługa wykonuje się w main thread przez Handler. BACKGROUND — obsługa wykonuje się w background thread; jeśli post został wywołany w main thread, EventBus umieszcza obsługę w kolejce background thread. ASYNC — każda obsługa wykonuje się w osobnym background thread z puli wątków. Do aktualizacji UI używaj MAIN.

// Sticky Event
data class LocationEvent(val lat: Double, val lng: Double)

// Wysyłanie sticky-zdarzenia z LocationService
EventBus.getDefault().postSticky(LocationEvent(55.7558, 37.6173))

// Subskrybent otrzymuje ostatnią lokalizację natychmiast po rejestracji
class MapFragment : Fragment() {
    override fun onStart() {
        super.onStart()
        EventBus.getDefault().register(this)
        // Natychmiast otrzyma LocationEvent, jeśli było postSticky
    }

    override fun onStop() {
        EventBus.getDefault().unregister(this)
        super.onStop()
    }

    @Subscribe(sticky = true, threadMode = ThreadMode.MAIN)
    fun onLocationEvent(event: LocationEvent) {
        moveMapTo(event.lat, event.lng)
    }
}

// Usuwanie sticky-zdarzenia
EventBus.getDefault().removeStickyEvent(LocationEvent::class.java)

ThreadMode.BACKGROUND vs ASYNC

BACKGROUND używa jednego background-wątku dla wszystkich obsług — wykonują się sekwencyjnie. ASYNC tworzy nowy wątek z puli dla każdej obsługi — wykonują się równolegle. BACKGROUND nadaje się do operacji wejścia-wyjścia ze współdzieloną bazą danych. ASYNC — do niezależnych długich operacji (żądania sieciowe). Oba tryby wymagają thread-safe dostępu do współdzielonych zasobów. Liczba wątków: pula ASYNC jest nieograniczona.

Typowe błędy i wydajność EventBus

Podczas używania EventBus programiści często popełniają błędy prowadzące do wycieków pamięci, nieoczekiwanych wywołań i spadku wydajności. Najbardziej krytyczne: zapomniane wypisanie w Activity, rejestracja w onCreate (a nie onStart/onStop), subskrypcja na Object (wszystkie zdarzenia), wysyłanie zdarzeń w nieskończonej pętli. Profilowanie przez Android Profiler pomaga zidentyfikować problemy.

Wycieki pamięci przez EventBus

Najczęstszy błąd — rejestracja Activity w onCreate() bez wypisania w onDestroy(). Skutek: EventBus przechowuje referencję do Activity, GC nie może jej zwolnić. Przy obrocie ekranu tworzone jest nowe Activity, poprzednie pozostaje w pamięci. Rozwiązanie: zawsze łącz register/unregister w onStart/onStop. Dla Fragment używaj tego samego schematu. Jeśli Activity jest utrzymywane przez EventBus po finish, sprawdź przez Memory Profiler.

Wydajność: Subscriber Index

Bez Subscriber Index EventBus używa refleksji do wyszukiwania metod @Subscribe przy każdym register(). Na urządzeniach z Android 6-7 refleksja działa wolno, powodując opóźnienia do 50 ms. Subscriber Index eliminuje refleksję całkowicie: metody są indeksowane na etapie kompilacji przez annotation processor. Dla projektów z 20+ subskrybentami indeks jest obowiązkowy. Sprawdź, czy kapt lub annotationProcessor jest podłączony w build.gradle.

// build.gradle (app) — podłączenie Subscriber Index
dependencies {
    implementation 'org.greenrobot:eventbus:3.3.1'
    annotationProcessor 'org.greenrobot:eventbus-annotation-processor:3.3.1'
}

// Dla Kotlin użyj kapt
plugins {
    id 'kotlin-kapt'
}

dependencies {
    implementation 'org.greenrobot:eventbus:3.3.1'
    kapt 'org.greenrobot:eventbus-annotation-processor:3.3.1'
}

// Konfiguracja indeksu (w defaultConfig)
kapt {
    arguments {
        arg('eventBusIndex', 'com.app.EventBusIndex')
    }
}

Alternatywy dla EventBus we współczesnym Android

Nowoczesne projekty na Kotlin i Jetpack Compose preferują SharedFlow i Channel z biblioteki kotlinx.coroutines. SharedFlow obsługuje replay (sticky), buffering i backpressure. Channel — zdarzenia jednorazowe (toast, nawigacja). Oba rozwiązania są zintegrowane z Lifecycle przez repeatOnLifecycle i nie wymagają ręcznego wypisywania. Dla nowych projektów zaleca się SharedFlow zamiast EventBus. Dla istniejących projektów migracja jest uzasadniona przy refaktoringu.