WorkManager — was ist das, API und Aufgabenplanung

Wie funktioniert WorkManager?

Die Architektur von WorkManager baut auf drei Basisklassen auf: Worker, WorkRequest und WorkManager. Worker enthält die Aufgabenlogik, WorkRequest beschreibt die Ausführungsparameter und WorkManager verwaltet die Warteschlange und Planung. Die Bibliothek verwendet eine interne Room-Datenbank, um den Status aller Aufgaben zu speichern.

Worker und WorkRequest

Worker ist eine abstrakte Klasse mit einer einzigen Methode doWork, die in einem Hintergrundthread aufgerufen wird. Die Methode gibt ListenableWorker.Result zurück — SUCCESS, FAILURE oder RETRY. WorkRequest verbindet den Worker mit Parametern: Timeout, Tag, Anfangsverzögerung und Einschränkungen.

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : Worker(context, params) {

    override fun doWork(): Result {
        return try {
            val api = RetrofitClient.api
            val response = api.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Planung über WorkManager

WorkManager plant Aufgaben einheitlich, unabhängig von der Android-Version. Beim Aufruf von enqueue speichert die Bibliothek die Aufgabe in Room, bewertet die aktuellen Bedingungen und wählt den optimalen Ausführungszeitpunkt. Unter der Haube kann JobScheduler, AlarmManager oder ein eigener Planer verwendet werden — der Entwickler muss sich darüber keine Gedanken machen.

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setInitialDelay(15, TimeUnit.MINUTES)
    .addTag("sync")
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

Arten von WorkRequest

WorkManager unterstützt zwei Arten von Ausführungsanfragen: einmalige und periodische. Die Wahl des Typs hängt vom Szenario ab: Die Aufgabe soll einmal ausgeführt werden oder in einem bestimmten Intervall wiederholt werden.

OneTimeWorkRequest

OneTimeWorkRequest ist für Aufgaben konzipiert, die einmal ausgeführt werden sollen. Dies kann das Senden eines Protokolls, die Datensynchronisation nach der Autorisierung oder das Herunterladen der Konfiguration beim ersten Start sein. Die Verzögerung wird über setInitialDelay und die Einschränkungen über setConstraints festgelegt.

PeriodicWorkRequest

PeriodicWorkRequest eignet sich für wiederkehrende Aufgaben mit einem Mindestintervall von 15 Minuten. Die Bibliothek garantiert, dass das Intervall zwischen den Ausführungen nicht kürzer als angegeben ist, kann aber aufgrund von Geräteeinschränkungen länger sein. Für Aufgaben mit einer Häufigkeit von weniger als 15 Minuten verwenden Sie Handler oder Timer im Foreground Service.

Einschränkungen und Aufgabenketten einrichten

Einschränkungen in WorkManager ermöglichen es, Bedingungen festzulegen, unter denen eine Aufgabe gestartet werden kann: Netzwerkverbindung (NetworkType), Akkustand (batteryNotLow), Speicherzustand (StorageNotLow) und Ruhemodus (DeviceIdle). Die Aufgabe wird erst gestartet, wenn alle Einschränkungen erfüllt sind.

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresCharging(true)
    .setRequiresBatteryNotLow(true)
    .build()

val request = OneTimeWorkRequestBuilder<ImageUploadWorker>()
    .setConstraints(constraints)
    .build()

Ketten ermöglichen die Organisation der sequenziellen oder parallelen Ausführung von Aufgaben. beginWith startet eine Kette, then fügt den nächsten Worker hinzu, der nach erfolgreichem Abschluss des vorherigen ausgeführt wird. Für die parallele Ausführung verwenden Sie workManager.enqueue(listOf(request1, request2)).

WorkManager.getInstance(context)
    .beginWith(compressWorker)
    .then(uploadWorker)
    .then(cleanupWorker)
    .enqueue()
    // compress -> upload -> cleanup sequenziell

Migration von JobScheduler zu WorkManager

JobScheduler wurde in Android 5 (API 21) als Systemdienst zur Planung von Hintergrundaufgaben eingeführt. WorkManager kam als Ersatz und bietet eine plattformübergreifende API mit automatischer Migration und zusätzlichen Funktionen: Ketten, Ausführungsgarantie, Tags, Zustandsüberwachung via LiveData.

Bei der Migration von JobScheduler zu WorkManager müssen Sie JobService in Worker umwandeln, JobInfo durch WorkRequest und Context.getSystemService durch die WorkManager-API ersetzen. WorkManager behandelt Kompatibilitätsprobleme automatisch und verarbeitet den Doze Mode korrekter als eine manuelle JobScheduler-Implementierung. Migrationsschritte: 1) Worker-Klasse erstellen, 2) WorkRequest mit denselben Bedingungen erstellen, 3) JobService und JobInfo aus Code und Manifest entfernen.

UniqueWork für eindeutige Aufgaben

WorkManager unterstützt das Konzept eindeutiger Aufgaben über ExistingWorkPolicy. Wenn eine Aufgabe mit dem angegebenen Namen bereits vorhanden ist, bestimmt die Richtlinie das Verhalten: KEEP (keine neue erstellen), REPLACE (vorhandene ersetzen), APPEND (am Ende der Kette hinzufügen) und APPEND_OR_REPLACE. UniqueWorkRequest ist praktisch für Aufgaben, die nicht dupliziert werden sollen: Datenbanksynchronisation, Konfigurationsdownload, Analyse-Batch-Versand.

WorkManager.getInstance(context)
    .enqueueUniqueWork(
        "sync_data",
        ExistingWorkPolicy.KEEP,
        syncRequest
    )

Fortschritts- und Zwischenergebnisverwaltung

CoroutineWorker unterstützt den setProgress-Mechanismus, mit dem Zwischenergebnisse der Ausführung übergeben werden können. Dies ist nützlich für langlaufende Operationen: großer Dateidownload, Batch-Bildverarbeitung, Datenbankmigration. Die UI kann Updates über getWorkInfosByTagLiveData abonnieren und den Fortschritt in Echtzeit anzeigen. Die Methode ForegroundInfo ist ebenfalls verfügbar, um einen Worker als Foreground Service mit einer Benachrichtigung auszuführen, wenn die Aufgabe für den Benutzer sichtbar sein soll.

class ProgressWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val total = 100
        for (i in 1..total) {
            setProgress(
                workDataOf("progress" to i)
            )
        }
        return Result.success()
    }
}

InputData und OutputData zur Datenübertragung

WorkManager unterstützt die Datenübertragung zwischen Workern über InputData und OutputData. InputData wird während der WorkRequest-Erstellung über Data.Builder erstellt und über inputData an den Worker übergeben. Nach der Ausführung erstellt der Worker OutputData über workDataOf oder Data.Builder und gibt es zusammen mit Result.success(outputData) zurück. Der nächste Worker in der Kette erhält das outputData des vorherigen als sein inputData. Daten werden im Schlüssel-Wert-Format mit Unterstützung für Basistypen gespeichert: String, Int, Long, Boolean, Double. Die maximale Datengröße beträgt 10 KB.

In der Praxis verwenden viele Projekte WorkManager als einzigen Planer für Hintergrundaufgaben. Google empfiehlt, alle vorhandenen JobService zu WorkManager zu migrieren, insbesondere in Apps, die Android 4.4 (API 19) und niedriger unterstützen, wo JobScheduler nicht verfügbar ist und WorkManager einen Fallback-Mechanismus über AlarmManager und BroadcastReceiver verwendet. Zum Testen stellt WorkManager TestListenableWorkerBuilder und TestWorkerBuilder zur Verfügung, mit denen Worker in JUnit-Tests ohne echten Planer getestet werden können.