Android AsyncTask pour les opérations de longue durée

Question

En citant la documentation pour AsyncTask, on trouve ici il est dit :

Les AsyncTasks doivent idéalement être utilisées pour des opérations de courte durée (quelques secondes tout au plus). Si vous devez maintenir des threads en cours d'exécution pendant de longues périodes, il est fortement recommandé d'utiliser les diverses API fournies par le paquet java.util.concurrent telles que Executor, ThreadPoolExecutor et FutureTask.

Maintenant, ma question se pose : pourquoi ? Le site doInBackground() s'exécute hors du thread de l'interface utilisateur, alors quel mal y a-t-il à avoir une opération longuement exécutée ici ?

Answer 1

C'est une très bonne question, il faut du temps en tant que programmeur Android pour bien comprendre le problème. En effet, AsyncTask a deux problèmes principaux qui sont liés :

• Ils sont peu liés au cycle de vie de l'activité
• Ils créent très facilement des fuites de mémoire.

A l'intérieur de la RoboSpice Application Motivations ( disponible sur Google Play ) nous répondons à cette question en détail. Il vous donnera une vue approfondie des AsyncTasks, des Loaders, de leurs caractéristiques et de leurs inconvénients et vous présentera également une solution alternative pour les requêtes réseau : RoboSpice. Les requêtes réseau sont une exigence commune dans Android et sont par nature des opérations de longue durée. . Voici un extrait de l'application :

Le cycle de vie des AsyncTask et des Activity

Les AsyncTasks ne suivent pas le cycle de vie des Activity instances. Si vous lancez une AsyncTask à l'intérieur d'une Activity et que vous faites pivoter le dispositif, l'Activity sera détruite et une nouvelle instance sera créée. Mais l'AsyncTask ne mourra pas. Elle continuera à vivre jusqu'à ce qu'elle soit terminée.

Et lorsqu'elle se termine, l'AsyncTask ne met pas à jour l'interface utilisateur de la nouvelle activité. En effet, elle met à jour l'ancienne instance de l'activité qui n'est plus affichée. Cela peut conduire à une Exception du type java.lang.IllegalArgumentException : View not attached to window manager si vous utilisez, par exemple, findViewById pour récupérer une vue dans l'activité.

Problème de fuite de mémoire

Il est très pratique de créer des AsyncTasks comme classes internes de vos activités. Comme l'AsyncTask devra manipuler les vues de l'Activity lorsque la tâche sera terminée ou en cours, l'utilisation d'une classe interne de l'Activity semble pratique. de l'activité lorsque la tâche est terminée ou en cours, l'utilisation d'une classe interne de l'activité semble pratique : les classes internes peuvent accéder directement à tous les champs de la classe externe. accéder directement à n'importe quel champ de la classe externe.

Néanmoins, cela signifie que la classe interne détiendra une référence invisible sur son instance de classe externe : l'activité.

A long terme, cela produit une fuite de mémoire : si l'AsyncTask dure longtemps, il maintient l'activité "vivante". alors qu'Android voudrait s'en débarrasser car elle ne peut plus être affichée. L'activité ne peut pas être ramassée et c'est un mécanisme central d'Android pour préserver les ressources sur l'écran. mécanisme central d'Android pour préserver les ressources de l'appareil.

---

C'est vraiment une très très mauvaise idée d'utiliser les AsyncTasks pour des opérations de longue durée. Néanmoins, elles sont parfaites pour les opérations de courte durée, comme la mise à jour d'une vue après 1 ou 2 secondes.

Je vous encourage à télécharger le Application RoboSpice Motivations Il explique vraiment tout cela en profondeur et fournit des exemples et des démonstrations des différentes manières d'effectuer certaines opérations en arrière-plan.

Answer 2

Pourquoi ?

Parce que AsyncTask par défaut, utilise un pool de threads que vous n'avez pas créé . N'immobilisez jamais les ressources d'un pool que vous n'avez pas créé, car vous ne savez pas quelles sont les exigences de ce pool. Et n'affectez jamais les ressources d'un pool que vous n'avez pas créé si la documentation de ce pool vous dit de ne pas le faire, comme c'est le cas ici.

En particulier, à partir d'Android 3.2, le pool de threads utilisé par AsyncTask par défaut (pour les applications avec android:targetSdkVersion réglé sur 13 ou plus) n'a que un Si vous bloquez ce fil indéfiniment, aucune de vos autres tâches ne s'exécutera.

Answer 3

Les tâches Aysnc sont des threads spécialisés qui sont toujours destinés à être utilisés avec l'interface graphique de votre application, mais tout en conservant les tâches lourdes en ressources du thread de l'interface graphique. Ainsi, lorsque des choses comme la mise à jour de listes, la modification de vos vues, etc., nécessitent des opérations de récupération ou de mise à jour, vous devez utiliser des tâches asynchrones pour que ces opérations ne soient pas effectuées par le thread de l'interface utilisateur, mais notez que ces opérations sont toujours connectées à l'interface utilisateur.

Pour les tâches plus longues, qui ne nécessitent pas de mise à jour de l'interface utilisateur, vous pouvez utiliser des services car ils peuvent vivre même sans interface utilisateur.

Ainsi, pour les tâches courtes, utilisez des tâches asynchrones car elles peuvent être tuées par le système d'exploitation après la mort de l'activité qui les génère (en général, elles ne meurent pas au milieu de l'opération mais terminent leur tâche). Et pour les tâches longues et répétitives, utilisez plutôt des services.

Pour plus d'informations, voir les fils :

AsyncTask pendant plus de quelques secondes ?

et

AsyncTask ne s'arrête pas même lorsque l'activité est détruite

Answer 4

Le problème avec AsyncTask est que si elle est définie comme une classe interne non statique de l'activité, elle aura une référence à l'activité. Dans le scénario où l'activité, le conteneur de la tâche asynchrone, se termine, mais que le travail en arrière-plan dans AsyncTask continue, l'objet activité ne sera pas ramassé car il y a une référence à lui, ce qui cause une fuite de mémoire.

La solution pour résoudre ce problème est de définir tâche asynchrone en tant que classe interne statique d'activité et d'utilisation faible référence au contexte.

Mais c'est tout de même une bonne idée de l'utiliser pour des tâches de fond simples et rapides. Pour développer une application avec un code propre, il est préférable d'utiliser la fonction RxJava pour exécuter des tâches complexes en arrière-plan et mettre à jour l'interface utilisateur avec les résultats de ces tâches.

Answer 5

Il existe plusieurs façons d'effectuer une opération intensive dans un thread séparé. Selon les scénarios, cela diffère. J'ai utilisé Handler