Dans cet article, nous parlerons d'un problème avec JobIntentService, sur lequel il y a de nombreuses questions sur les ressources et les rapports correspondants dans le traqueur de bogues Google. Et aussi sur la raison pour laquelle, à en juger par tout, Google ne le considère pas comme un bug et ferme ces rapports.
Présentation
JobIntentServices ont été créés pour le travail en arrière-plan. Ils étaient largement utilisés dans Android 8 et supérieur, lorsque la possibilité d'utiliser des services en arrière-plan a disparu.
En fait, ils remplacent les services en arrière-plan et sont également sous le contrôle du planificateur de tâches (JobScheduler).
Ainsi, le système a la capacité de contrôler la progression des tâches en arrière-plan et contrôle également les wakelocks lui-même, ce qui a permis d'optimiser la consommation de batterie de l'appareil et d'éviter l'utilisation incorrecte des wakelocks par les développeurs. Ces étapes ont minimisé la situation lorsque l'appareil ne peut pas plonger en mode veille (mode Doze), ce qui affecte à nouveau l'économie de batterie.
En bref sur JobIntentService
En substance, le JobIntentService est le même IntentService sous le contrôle du planificateur de tâches (JobScheduler).
Exécution dans le thread d'arrière-plan d'AsyncTask.
Dans les versions d'Android 4.4 et inférieures, l'IntentService habituel est utilisé.
Une description détaillée se trouve dans la documentation.
Cycle de vie et pièges
Les deux types de tâches ont le même cycle de vie. Les tâches sont contrôlées par le gestionnaire et ont des états.
Bien que ces états ne soient pas accessibles de l'extérieur, dans certaines circonstances, le système lève des exceptions dans lesquelles l'application se bloque. Ces comportements sont un problème et un casse-tête pour de nombreux développeurs et n'ont malheureusement pas de solution simple. Pour commencer, nous étudions le statut et le cycle de vie des tâches, puis étudions les solutions possibles.
Séquence d'état des tâches
BINDING - délai de création de la tâche (liaison de service) 18 secondes.
DÉMARRAGE - état de lancement de la tâche, délai d'expiration 8 secondes.
EXECUTING - état d'exécution de la tâche, timeout 10 minutes.
STOPPING - état d'arrêt de la tâche (par exemple, après avoir appelé cancel ()), délai d'expiration 8 secondes.
FINISHED - l'état final de la tâche terminée, le dernier état du cycle de vie de la tâche.
Diagramme de cycle de vie des tâches simplifié
Chaque état de tâche a son propre délai d'expiration. Après un délai d'expiration, la tâche est interrompue quel que soit son état. En fait, il s'agit d'un mécanisme de temporisation et est un écueil depuis après l'expiration du délai, le système lève une exception de type java.lang.SecurityException et l'application se bloque avec le message suivant L' Caller no longer running, last stopped +1s600ms because: timed out while starting où +1s600ms est le temps écoulé depuis le délai d'expiration au moment où l'exception a été levée et la «raison» ( because: timed out while starting expiration au because: timed out while starting ) indique l'état dans lequel se trouvait la tâche lorsque le délai d'expiration a expiré.
Conclusions
Comme le montre l'expérience, ces exceptions se trouvent dans des applications assez chargées.
À l'appui de ce problème, on peut observer à la fois sur des appareils faibles et sur des appareils supérieurs. Ce problème est également indiqué par des exceptions levées avec des messages d'expiration. En conséquence, la décision de décharger l'application et d'optimiser l'utilisation de JobIntentServices, par exemple, pour éviter des situations où plusieurs JobIntentServices sont lancés en parallèle, se suggère. La deuxième solution, dans certains cas plus triviale et parfois plus compliquée que la première option, consiste à utiliser JobService.
De plus, si vous recherchez ce problème sur Google, vous pouvez tomber sur d'autres options "douteuses" pour résoudre ce problème, par exemple, vous pouvez voir les liens suivants:
Option 1
Option 2
Option 3
PS
À l'heure actuelle, Google prépare un bon remplacement pour JobService et JobIntentService - il s'agit de Worker et WorkManger du package androidx.work.
Malheureusement, ces outils ne sont pas encore prêts pour la production et comportent un certain nombre de bogues, mais déjà , comme les tests l'ont montré, ils résolvent le problème décrit ci-dessus.