Asynctask vs Thread vs Services vs Loader
Je suis légèrement confus quant aux différences entre Asynctask, Thread, Service, Loader dans Android.
Je sais comment ça marche. Mais je ne comprends toujours pas quoi et quand dois-je utiliser.
Je travaille avec Android pendant 3 ans, et j'utilise généralement toujours AsyncTask pour toutes les tâches en arrière-plan (et parfois Thread). Mais beaucoup de gens disent que "Asynctask est obsolète", et ne Je ne recommande pas de les utiliser. Ils recommandent également d'utiliser robospice ou Volley.
Alors, AsyncTask est-il vraiment si mauvais et dois-je utiliser le framework pour les tâches de mise en réseau? Et que dois-je utiliser pour la tâche en arrière-plan (et non en réseau)?
Les AysncTasks ne sont pas "obsolètes" autant qu'ils sont incomplets . Entre autres choses, les tâches asynchrones ne dérangent pas si leur activité parent est en cours d'exécution ou non. Pour la même raison pour laquelle vous incluez des vérifications pour vérifier que le contexte est nul ou non. De plus, à moins que vous n'utilisiez votre propre Thread Pool Executor, ces tâches s'exécutent en série.
Volley essaie de combler ces lacunes, principalement en ce qui concerne la synchronisation avec le thread principal et le pool de threads. Il se comporte de manière optimale si vous souhaitez effectuer des tâches nécessitant des requêtes réseau moyennes; comme une liste de métadonnées et des images (imaginez les demandes d'application youtube et les demandes d'application facebook pour les publications).
Les avantages de Volley sont généralement les suivants
- Il tient le thread de travail informé de l'activité (thread principal)
- Une hiérarchisation des ressources plus facile, vous pouvez donner la priorité à vos demandes de téléchargement. Un scénario typique impliquerait que vous donniez la priorité au texte sur l'image.
- Gestion efficace du cache de requêtes et de la mémoire.
- Extensible
- Il vous offre une option pour rejeter votre demande au cas où votre activité serait arrêtée ou redémarrée.
- Modèles plus simples pour la récupération de données par opposition aux AsyncTasks.
Volley s'en sort mal quand il s'agit de demandes de streaming/vidéo comme mentionné sur Google I/O.
Je ne connais pas exactement le robospice. Ps: Si vous avez du temps libre, voyez https://www.youtube.com/watch?v=yhv8l9F44qo
Voici une lecture supplémentaire si vous souhaitez aller dans d'autres bibliothèques avec des repères pour les mêmes. Comparaison de Android: OkHTTP, Retrofit et Volley
Threads: Identique à Java threads, utilisez-le pour effectuer des opérations lourdes mais vous devez le gérer vous-même et cela peut également provoquer des problèmes de synchronisation et vous ne pouvez pas mettre à jour l'interface utilisateur à partir de ce l'exécuter sur le thread d'interface utilisateur.
AsyncTask: Une excellente bibliothèque de threads disponible dans Android pour effectuer une tâche en arrière-plan. Elle est gérée par le système d'exploitation Android lui-même, vous pouvez mettre à jour l'interface utilisateur à partir de celui-ci. Il s'exécute en parallèle ou en série selon la version d'Android. Il peut être parfois compliqué de l'utiliser comme dans les cas de changements d'orientation et maintenant pour faire des appels réseau, vous pouvez utiliser volley qui est mieux que AsyncTask. AsyncTasks font ne vous souciez pas de l'activité parentale en cours d'exécution ou non et il peut être assez fastidieux d'annuler parfois. Je vous suggère donc si vous utilisez AsyncTask pour mieux utiliser les appels d'API de repos RETROFIT ou VOLLEY et si vous choisissez RETROFIT entre les deux, je vous recommande de jeter un œil à PICASSO une autre bibliothèque impressionnante de square pour le chargement d'images.
Service: pour effectuer des tâches d'arrière-plan à long terme, vous devez utiliser les services. Vous pouvez limiter les services à votre activité si vous en avez besoin. Vous pouvez définir qu'ils s'exécutent dans le même thread ou un thread différent et vous devez le déclarer dans le manifeste ou vous pouvez utiliser IntentService - une variante de service qui s'exécute dans son propre thread, mais soyez prudent avant de l'utiliser, ne l'utilisez pas pour des tâches de longue durée. C'est un opérateur unique. Si vous allez utiliser le service, évaluez le cas où celui qui correspond le mieux à vos besoins est un service normal ou IntentService
Chargeurs: c'est la même chose que AsyncTask à bien des égards, il est conseillé d'utiliser des chargeurs avec les fragments et cela résout le problème d'orientation des asynctasks.
Si vous êtes déjà passé à kotlin, je vous suggère de jeter un œil à Coroutines . Ils sont très légers et assez efficaces pour le filetage et vous offrent beaucoup de contrôle sur le cycle de vie. J'espère que cela a aidé.
Peu importe quelle abstraction vous utilisez, cela se résume à un Thread. Ainsi, chacune des classes asynchrones/parallèles d'Android utilise Thread/Executor en arrière-plan et a exactement les mêmes problèmes potentiels, comme le verrouillage, que les threads.
La différence entre alors réside dans son utilisation. AsyncTask par exemple, définit un rappel de complétion pratique - onPostExecute(). Un CountDownTimer vous permet de contrôler l'heure, etc.
Vous pouvez bien sûr utiliser un Thread simple, mais dans ce cas, vous devez investir plus de temps pour détecter vous-même les éventuels problèmes.
Donc, Android vous fournit quelques bons outils pour les bons emplois.
Mais beaucoup de gens disent que "Asynctask est obsolète" et ne recommandent pas de les utiliser.
Je n'ai rencontré personne disant cela. Mais c'est le travail de l'équipe Android Android de décider quand une partie du framework est obsolète ou obsolète. CursorLoaders use AsyncTaskLoader qui utilise AsyncTask . AsyncTasks sont une abstraction qui empêche le développeur d'avoir à implémenter une logique d'état Thread désagréable. Cela signifie que toutes ces classes utilisent tour à tour Threads en arrière-plan.
Alors, Asynctask est-il vraiment si mauvais et dois-je utiliser le framework pour les tâches de mise en réseau? Et que dois-je utiliser pour la tâche en arrière-plan (et non en réseau)?
Il s'agit de savoir quand et comment utiliser vos outils. Vous mentionnez CursorLoader. Dans ce cas particulier, lorsque vous lisez les documents et jouez un peu avec, vous vous rendez compte qu'il s'intègre volontairement avec ContentProviders. Maintenant, ContentProviders abstrait les données sous-jacentes; vous pouvez interroger une base de données SQLite locale ou un serveur distant.
En général, AsyncTasks sert à récupérer des informations concises "pas trop grandes" (lorsqu'il est utilisé pour parler avec des serveurs). Les gens pourraient dire que AsyncTasks sont obsolètes car il existe de meilleures façons (plus efficaces) d'interagir avec les serveurs (voir Retrofit ).
Je pense que AsyncTask est meilleur que Thread car il fournit un rappel sur le thread principal. Loader est meilleur que AsyncTask car il gère également les changements de configuration pour vous.
AsyncTask permet une utilisation correcte et facile du thread d'interface utilisateur. Cette classe vous permet d'effectuer des opérations d'arrière-plan et de publier des résultats sur le thread d'interface utilisateur sans avoir à manipuler des threads et/ou des gestionnaires.
AsyncTask est conçu pour être une classe d'assistance autour de Thread et Handler et ne constitue pas un framework de thread générique. AsyncTasks devrait idéalement être utilisé pour des opérations courtes ( quelques secondes tout au plus.)
Si vous devez maintenir les threads en cours d'exécution pendant de longues périodes, il est fortement recommandé d'utiliser les différentes API fournies par le Java.util.concurrent package tel que Executor, ThreadPoolExecutor et FutureTask.
Le déplacement de nombreuses ou longues tâches du thread principal, afin qu'elles n'interfèrent pas avec le rendu fluide et la réactivité rapide aux entrées des utilisateurs, est la principale raison pour laquelle vous adoptez le threading dans votre application.
Utilisez-le pour séparer le calcul de longue durée du thread principal (thread d'interface utilisateur)
Service :
Un service est un composant d'application qui peut effectuer des opérations de longue durée en arrière-plan et il ne fournit pas d'interface utilisateur.
Un service peut gérer les transactions réseau, lire de la musique, effectuer des E/S sur les fichiers ou interagir avec un fournisseur de contenu, tout de l'arrière-plan.
IntentService est une classe de base pour les services qui gèrent les demandes asynchrones (exprimées en intentions) à la demande.
Toutes les demandes sont traitées sur un seul thread de travail - elles peuvent prendre aussi longtemps que nécessaire (et ne bloqueront pas la boucle principale de l'application), mais une seule demande sera traitée à une fois.
Chargeur :
L'API du chargeur vous permet de charger des données à partir d'un fournisseur de contenu ou d'une autre source de données pour les afficher dans une activité ou un fragment.
Les chargeurs résolvent ces problèmes et incluent d'autres avantages. Par exemple:
Les chargeurs s'exécutent sur des threads séparés pour éviter une interface utilisateur saccadée ou qui ne répond pas.
Les chargeurs simplifient la gestion des threads en fournissant des méthodes de rappel lorsque des événements se produisent.
- Les chargeurs persistent et mettent en cache les résultats lors des modifications de configuration pour éviter les requêtes en double.
- Les chargeurs peuvent implémenter un observateur pour surveiller les changements dans la source de données sous-jacente
Alors, Asynctask est-il vraiment si mauvais et dois-je utiliser le framework pour les tâches de mise en réseau? Et que dois-je utiliser pour la tâche en arrière-plan (et non en réseau)?
Utilisez AsyncTask pour gérer les éléments de travail d'une durée inférieure à 5 ms. Vous pouvez utiliser Thread ou Service ou IntentService pour la tâche en arrière-plan.