Aufgaben verketten

Mit WorkManager können Sie eine Arbeitskette erstellen und in die Warteschlange stellen, die mehrere abhängige Aufgaben angibt und festlegt, in welcher Reihenfolge sie ausgeführt werden sollen. Diese Funktion ist besonders nützlich, wenn Sie mehrere Aufgaben in einer bestimmten Reihenfolge ausführen möchten.

Um eine Arbeitskette zu erstellen, können Sie WorkManager.beginWith(OneTimeWorkRequest) oder WorkManager.beginWith(List<OneTimeWorkRequest>) , die jeweils eine Instanz von WorkContinuation

Mit einem WorkContinuation können dann abhängige OneTimeWorkRequest-Instanzen mit then(OneTimeWorkRequest) oder then(List<OneTimeWorkRequest>) hinzugefügt werden.

Jede Aufrufung von WorkContinuation.then(...) gibt eine neue Instanz von WorkContinuation zurück. Wenn Sie eine List von OneTimeWorkRequest Instanzen hinzufügen, können diese Anfragen möglicherweise parallel ausgeführt werden.

Schließlich können Sie die Methode WorkContinuation.enqueue() verwenden, um Ihre WorkContinuation-Kette zu enqueue().

Sehen wir uns ein Beispiel an. In diesem Beispiel sind drei verschiedene Worker-Jobs für die Ausführung konfiguriert (potenziell parallel). Die Ergebnisse dieser Worker werden dann zusammengeführt und an einen Worker-Job für das Caching übergeben. Die Ausgabe dieses Jobs wird schließlich an einen Upload-Worker übergeben, der die Ergebnisse auf einen Remote-Server hochlädt.

Kotlin

WorkManager.getInstance(myContext)
   // Candidates to run in parallel
   .beginWith(listOf(plantName1, plantName2, plantName3))
   // Dependent work (only runs after all previous work in chain)
   .then(cache)
   .then(upload)
   // Call enqueue to kick things off
   .enqueue()

Java

WorkManager.getInstance(myContext)
   // Candidates to run in parallel
   .beginWith(Arrays.asList(plantName1, plantName2, plantName3))
   // Dependent work (only runs after all previous work in chain)
   .then(cache)
   .then(upload)
   // Call enqueue to kick things off
   .enqueue();

Eingabe-Fusionen

Wenn Sie OneTimeWorkRequest-Instanzen verketten, wird die Ausgabe der übergeordneten Arbeitsanfragen als Eingabe an die untergeordneten übergeben. Im obigen Beispiel würden also die Ausgaben von plantName1, plantName2 und plantName3 als Eingaben an die cache-Anfrage übergeben.

Um Eingaben aus mehreren übergeordneten Arbeitsanfragen zu verwalten, verwendet WorkManager InputMerger.

WorkManager bietet zwei verschiedene Arten von InputMerger:

  • OverwritingInputMerger versucht, der Ausgabe alle Schlüssel aus allen Eingaben hinzuzufügen. Bei Konflikten werden die zuvor festgelegten Schlüssel überschrieben.

  • ArrayCreatingInputMerger versucht, die Eingaben zusammenzuführen und bei Bedarf Arrays zu erstellen.

Wenn Sie einen spezifischeren Anwendungsfall haben, können Sie Ihren eigenen erstellen, indem Sie abgeleitete Klassen InputMerger

Eingabe überschreiben

OverwritingInputMerger ist die Standardmethode für die Zusammenführung. Wenn Schlüssel vorhanden sind, Konflikte in der Zusammenführung, dann überschreibt der letzte Wert für einen Schlüssel alle vorherigen Versionen in den resultierenden Ausgabedaten.

Wenn z. B. die Pflanzeneingaben jeweils einen Schlüssel haben, der mit dem Variablennamen ("plantName1", "plantName2" und "plantName3") enthält, ist der Daten, die an den cache-Worker übergeben werden, haben drei Schlüssel/Wert-Paare.

Diagramm mit drei Jobs, die unterschiedliche Ausgaben an den nächsten Job in der Kette übergeben. Da die drei Ausgaben alle unterschiedliche Schlüssel haben, erhält der nächste Job drei Schlüssel/Wert-Paare.

Wenn es einen Konflikt gibt, gewinnt der letzte Worker, der den Vorgang abgeschlossen hat, und ihr Wert wird an cache übergeben.

Diagramm mit drei Jobs, die die Ausgabe an den nächsten Job in der Kette weitergeben. In diesem Fall erzeugen zwei dieser Jobs Ausgaben mit demselben Schlüssel. Der nächste Job erhält dann zwei Schlüssel/Wert-Paare, wobei eine der in Konflikt stehenden Ausgaben verworfen wird.

Da Ihre Arbeitsanfragen parallel ausgeführt werden, gibt es keine Garantien für in der sie ausgeführt werden. Im Beispiel oben könnte plantName1 einen Wert von "tulip" oder "elm", je nachdem, welcher Wert geschrieben wird zuletzt. Wenn die Möglichkeit eines Schlüsselkonflikts besteht und Sie die gesamte Ausgabe beibehalten müssen bei einer Zusammenführung, dann ist ArrayCreatingInputMerger möglicherweise die bessere Option.

ArrayErstellenEingabezusammenführung

Da wir in unserem Beispiel die Ausgabe aller Worker mit dem Attribut „Name der Anlage“ beibehalten möchten, sollten wir eine ArrayCreatingInputMerger verwenden.

Kotlin

val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilder<PlantWorker>()
   .setInputMerger(ArrayCreatingInputMerger::class)
   .setConstraints(constraints)
   .build()

Java

OneTimeWorkRequest cache = new OneTimeWorkRequest.Builder(PlantWorker.class)
       .setInputMerger(ArrayCreatingInputMerger.class)
       .setConstraints(constraints)
       .build();

Bei ArrayCreatingInputMerger wird jeder Schlüssel mit einem Array verknüpft. Wenn jeder Schlüssel eindeutig ist, ist das Ergebnis eine Reihe von Arrays mit nur einem Element.

Diagramm mit drei Jobs, die verschiedene Ausgaben an den nächsten Job in der Kette übergeben. Im nächsten Job werden drei Arrays übergeben, eines für jeden der Ausgabeschlüssel. Jedes Array hat ein einzelnes Mitglied.

Bei Schlüsselkollisionen werden die entsprechenden Werte in einem Array zusammengefasst.

Diagramm mit drei Jobs, die Ausgaben an den nächsten Job in der Kette übergeben. In diesem Fall erzeugen zwei dieser Jobs Ausgaben mit demselben Schlüssel. Im nächsten Job werden zwei Arrays übergeben, eines für jeden Schlüssel. Eines dieser Arrays hat zwei Mitglieder, da es zwei Ausgaben mit diesem Schlüssel gab.

Verknüpfung und Arbeitsstatus

Ketten von OneTimeWorkRequest werden nacheinander ausgeführt, solange ihre Arbeit erfolgreich abgeschlossen wurde (d. h. es wird ein Result.success() zurückgegeben). Arbeit Anfragen können fehlschlagen oder während der Ausführung abgebrochen werden. Dies hat nachgelagerte Auswirkungen auf abhängigen Arbeitsanfragen.

Wenn die erste OneTimeWorkRequest in einer Kette von Arbeitsanfragen in die Warteschlange gestellt wird, werden alle nachfolgenden Arbeitsanfragen blockiert, bis die Arbeit dieser ersten Arbeitsanfrage abgeschlossen ist.

Diagramm mit einer Jobkette Der erste Job wird in die Warteschlange gestellt. werden alle aufeinanderfolgenden Jobs blockiert, bis der erste abgeschlossen ist.

Sobald Sie in die Warteschlange gestellt und alle Arbeitsbeschränkungen erfüllt wurden, ist die erste Arbeitsanfrage aktiv ist. Wenn die Arbeit im Stammverzeichnis OneTimeWorkRequest oder List<OneTimeWorkRequest> erfolgreich abgeschlossen wurde (d. h., es wird eine Result.success() zurückgegeben), werden die nächsten abhängigen Arbeitsanfragen in die Warteschlange gestellt.

Diagramm mit einer Kette von Jobs. Der erste Job war erfolgreich und seine beiden unmittelbaren Nachfolger wurden in die Warteschlange gestellt. Die verbleibenden Jobs werden blockiert, bis die vorherigen Jobs abgeschlossen sind.

Solange jede Arbeitsanfrage erfolgreich abgeschlossen wird, wird dieses Muster auf die restliche Arbeitsanfragekette angewendet, bis alle Aufgaben in der Kette abgeschlossen sind. Das ist zwar der einfachste und oft bevorzugte Fall, aber auch Fehlerstatus müssen genauso behandelt werden.

Wenn während der Verarbeitung Ihrer Arbeitsanfrage ein Fehler auftritt, können Sie Folgendes tun: wiederholen Sie die Anfrage gemäß einer Backoff-Richtlinie, definieren. Wenn Sie eine Anfrage wiederholen, die Teil einer Kette ist, bedeutet das, dass nur diese Anfrage mit den bereitgestellten Eingabedaten wiederholt werden. Parallel ausgeführte Aufgaben sind davon nicht betroffen.

Diagramm mit einer Jobkette Einer der Jobs ist fehlgeschlagen, es wurde jedoch eine Backoff-Richtlinie definiert. Dieser Job wird nach Ablauf der entsprechenden Zeit noch einmal ausgeführt. Die Jobs in der Kette, die nach diesem Job kommen, werden blockiert, bis er erfolgreich ausgeführt wurde.

Weitere Informationen zum Definieren benutzerdefinierter Wiederholungsstrategien finden Sie unter Wiederholungs- und Backoff-Richtlinie.

Wenn diese Wiederholungsrichtlinie nicht definiert oder erschöpft ist oder Sie anderweitig einen Status erreichen, in dem OneTimeWorkRequest Result.failure() zurückgibt, werden diese Arbeitsanfrage und alle abhängigen Arbeitsanfragen als FAILED. markiert.

Diagramm mit einer Kette von Jobs. Ein Job ist fehlgeschlagen und kann nicht wiederholt werden. Daher schlagen auch alle nachfolgenden Jobs in der Kette fehl.

Dasselbe gilt, wenn eine OneTimeWorkRequest storniert wird. Alle abhängigen Arbeitsanfragen sind ebenfalls mit CANCELLED gekennzeichnet und ihre Arbeit wird nicht ausgeführt.

Diagramm mit einer Kette von Jobs. Ein Job wurde abgebrochen. Daher werden auch alle nachfolgenden Jobs in der Kette abgebrochen.

Wenn Sie einer Kette, die fehlgeschlagen ist oder bei der Arbeitsanfragen abgebrochen wurden, weitere Arbeitsanfragen anhängen, wird auch die neu angehängte Arbeitsanfrage mit FAILED bzw. CANCELLED gekennzeichnet. Wenn Sie die Arbeit verlängern möchten, einer vorhandenen Kette, siehe APPEND_OR_REPLACE in VorhandeneWorkPolicy.

Beim Erstellen von Ketten von Arbeitsanfragen sollten abhängige Arbeitsanfragen Wiederholungsrichtlinien sorgen, um sicherzustellen, dass Aufgaben immer zügig abgeschlossen werden. Fehlgeschlagene Arbeitsanfragen können zu unvollständigen Ketten und/oder unerwarteten Status führen.

Weitere Informationen finden Sie unter Aufgaben abbrechen und anhalten.