Broadcast Receiver: mi ez, a Broadcast típusai és a működési elv

Mi az a Broadcast Receiver?

A Broadcast Receiver egy Android komponens, amelyet az operációs rendszer vagy más alkalmazások által terjesztett Intent üzenetek fogadására és feldolgozására terveztek. Az Activity-től és Service-től eltérően a Broadcast Receiver nem rendelkezik felhasználói felülettel — a feladata egy rövid feladat végrehajtása az esemény bekövetkeztekor.

A Broadcast Receiver az Intent mechanizmuson keresztül működik. A rendszer vagy alkalmazás Intent-et küld a sendBroadcast vagy sendOrderedBroadcast segítségével, az operációs rendszer pedig kézbesíti azt a regisztrált vevőknek. Minden vevő az onReceive metódusban kapja meg az Intent-et, amely a fő szálon fut.

Az Android Compatibility Definition Document szerint a Broadcast Receiver-nek 10 másodpercen belül be kell fejeznie az onReceive-ot — ellenkező esetben a rendszer lefagyottnak tekinti és befejezi a folyamatot. Hosszú háttérfeladatokhoz használja a JobScheduler-t vagy WorkManager-t, amelyeket a vevőből indít.

Broadcast típusok Androidban

Az Android két fő Broadcast típust támogat: Normal Broadcast és Ordered Broadcast. A különbség a kézbesítési sorrendben és a feldolgozási lánc megszakításának lehetőségében van. Emellett a Broadcast-ok rendszer (OS által generált) és felhasználói (alkalmazás által létrehozott) kategóriákra oszlanak.

Normal Broadcast

A Normal Broadcast aszinkron módon és garantált sorrend nélkül kerül kézbesítésre az összes regisztrált vevőnek. A rendszer párhuzamosan dolgozhatja fel az ilyen Broadcast-okat — minden vevő a saját szálában kapja meg az Intent-et. Az abortBroadcast hívásának a Normal Broadcast-ben nincs hatása: a más vevőknek történő kézbesítés nem szakítható meg.

Ordered Broadcast

Az Ordered Broadcast szekvenciálisan kerül kézbesítésre — minden vevőnek a android:priority attribútum csökkenő sorrendjében (0-tól 999-ig). Feldolgozás után a vevő továbbíthatja az eredményt a következőnek a setResultExtras segítségével, vagy megszakíthatja a láncot az abortBroadcast hívással. Ez olyan forgatókönyvekben használatos, ahol a feldolgozás sorrendje fontos — például SMS-vevők.

Rendszer Broadcast-ok

Az Android számos rendszer Broadcast-ot generál: ACTION_BOOT_COMPLETED (eszköz bootolása), ACTION_BATTERY_LOW, ACTION_POWER_CONNECTED, CONNECTIVITY_ACTION, ACTION_PACKAGE_ADDED és mások. Minden Intent további adatokat tartalmaz az Extras-ban — akkumulátor szint, kapcsolat típusa, csomag neve.

Sticky Broadcast — egy elavult típus, amely az utolsó elküldött értéket tárolta. Helyette használjon LiveData-t, StateFlow-t vagy megosztott SharedPreferences-t az utolsó állapot tárolásához.

Broadcast Receiver regisztrálása

A Broadcast Receiver kétféleképpen regisztrálható: statikusan az AndroidManifest.xml-en keresztül vagy dinamikusan a kódban a registerReceiver segítségével. A választás a forgatókönyvtől függ: a statikus regisztráció akkor is működik, ha az alkalmazás nincs elindítva, a dinamikus — csak amíg a regisztráló komponens aktív.

Statikus regisztráció

A statikus regisztráció a manifestben a <receiver> taggal történik az <application>-en belül. Minden vevőhöz meg kell adni a kezelő osztályt és az Intent szűrőt azokkal a műveletekkel, amelyeket el kell fognia. A rendszer betölti az ilyen vevőket a Broadcast bekövetkeztekor, még akkor is, ha az alkalmazás nincs elindítva.

<!-- Static Broadcast Receiver registration in manifest -->
<receiver android:name=".BootReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

Dinamikus regisztráció

A dinamikus regisztráció a registerReceiver metódussal történik az Activity, Service vagy Fragment kódjában. A vevő csak addig él, amíg az őt regisztráló komponens él. Feltétlenül hívja meg az unregisterReceiver-t az onPause vagy onDestroy metódusban — ellenkező esetben memóriaszivárgás lép fel, és a rendszer befejezheti a folyamatot.

Prioritás és feldolgozási sorrend

Az Ordered Broadcast esetében a kézbesítési sorrendet a android:priority attribútum határozza meg. A magasabb prioritású vevő korábban kapja meg az Intent-et. Ha a feldolgozás után meghívja az abortBroadcast-t, az alacsonyabb prioritású vevők nem kapják meg az Intent-et. Statikus vevők esetében a prioritást a manifest Intent szűrőjében kell beállítani.

Adatok továbbítása a vevők között

Az Ordered Broadcast vevői továbbíthatnak adatokat a lánc következő tagjának a setResultExtras vagy setResultData segítségével. Ez lehetővé teszi a csővezetékes feldolgozást: az első vevő kibővíti az Intent-et további adatokkal, a második felhasználja azokat, a harmadik befejezi a láncot. A getResultExtras metódus beolvassa az előző vevő által továbbított adatokat.

A Normal Broadcast esetében a sorrend nem garantált, így minden vevő az eredeti Intent-et kapja meg változtatás nélkül. Ha szeretné, hogy a vevők befolyásolják egymást, használja a sendOrderedBroadcast-ot a sendBroadcast helyett.

Korlátozások Android 8 és újabb rendszerekben

Az Android 8 (API 26, Oreo) jelentős korlátozásokat vezetett be a háttér Broadcast-okra vonatkozóan. A legtöbb implicit Broadcast — amelyek nem egy adott alkalmazáshoz címződnek — már nem működik statikus regisztrációval. A rendszer blokkolja a manifestben regisztrált vevőket olyan műveletekhez, mint a CONNECTIVITY_ACTION vagy ACTION_BATTERY_LOW.

Mi változott

A Google meghatározta azon Broadcast-ok listáját, amelyek továbbra is működnek statikus regisztrációval: BOOT_COMPLETED, TIME_TICK, Alarm, INSTANCE? (csomagváltozások) — összesen körülbelül tíz kivétel. Az összes többi implicit Broadcast most dinamikus regisztrációt igényel a Context.registerReceiver segítségével, amely csak akkor működik, ha az alkalmazás az előtérben van.

Alternatívák a Broadcast Receiver helyett

A korábban Broadcast Receiver segítségével megoldott háttérfeladatokhoz az Android a WorkManager-t (késleltetett feladatok végrehajtási garanciával), a JobScheduler-t (periodikus feladatok az eszköz állapotának figyelembevételével) és a NotificationListenerService-t (értesítések figyelése) ajánlja. Ezek a komponensek az Android 8 korlátozásai nélkül működnek, és energiafogyasztás szempontjából optimalizáltak.

Broadcast Receiver példa Kotlinban

Tekintsük át egy Broadcast Receiver létrehozását a hálózati kapcsolat követésére. A vevő megkapja a CONNECTIVITY_ACTION Broadcast-ot és naplózza a kapcsolat típusát. Android 8+ esetén dinamikusan regisztráljuk, mivel ez egy implicit Broadcast, amely ki van zárva a statikus regisztrációból.

// Broadcast Receiver hálózati állapot követéséhez
class NetworkReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
        val network = cm.activeNetwork
        val caps = cm.getNetworkCapabilities(network)

        val connectionType = when {
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) == true -> "WiFi"
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) == true -> "Cellular"
            else -> "Disconnected"
        }

        Log.d("NetworkReceiver", "Kapcsolat típusa: $connectionType")
    }
}

// Dinamikus regisztráció Activity-ben
class MainActivity : AppCompatActivity() {

    private val networkReceiver = NetworkReceiver()

    override fun onStart() {
        super.onStart()
        val filter = IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION)
        registerReceiver(networkReceiver, filter)
    }

    override fun onStop() {
        super.onStop()
        unregisterReceiver(networkReceiver)
    }
}

Feltétlenül szüntesse meg a vevő regisztrációját az onStop-ban — ha az Activity háttérbe kerül, de a vevő regisztrálva marad, a rendszer nem tudja felszabadítani az erőforrásokat. Service esetén használja az onDestroy-t. Fragmentekben regisztrálja a vevőt az onStart-ban és szüntesse meg az onStop-ban, követve a fragment életciklusát.