Handler vs AsyncTask vs Thread
Je suis un peu confus au sujet des différences entre Handlers, AsyncTask et Threads dans Android. J'ai lu pas mal de blogs et de questions ici dans StackOverflow.
Handler sont des threads d'arrière-plan qui vous permettent de communiquer avec l'interface utilisateur. La mise à jour d'une barre de progression, par exemple, devrait être effectuée via Handler. En utilisant les gestionnaires, vous avez l'avantage de MessagingQueues, donc si vous souhaitez planifier des messages, mettre à jour plusieurs éléments de l'interface utilisateur ou effectuer des tâches répétitives.
AsyncTask sont similaires, en fait, ils utilisent Handler, mais ne s'exécutent pas dans le thread d'interface utilisateur. Ils sont donc utiles pour extraire des données, par exemple pour extraire des services Web. Plus tard, vous pouvez interagir avec l'interface utilisateur.
Thread ne peut toutefois pas interagir avec l'interface utilisateur, fournit plus de threads "de base" et vous manquez toutes les abstractions de AsyncTask.
Cependant, je voudrais avoir une connexion prise en service. Cela devrait-il être exécuté dans un gestionnaire ou un thread, ou même dans un AsyncTask? L'interaction de l'interface utilisateur n'est pas nécessaire du tout. Cela fait-il une différence en termes de performances que j'utilise?
Pendant ce temps, la documentation a été grandement améliorée.
Comme le explique le tutoriel sur traitement en arrière-plan Android avec Handlers, AsyncTask et Loaders sur le site Vogella:
La classe Handler peut être utilisée pour s'inscrire dans un thread et fournit un canal simple pour envoyer des données à ce thread.
La classe AsyncTask encapsule la création d'un processus en arrière-plan et la synchronisation avec le thread principal. Il prend également en charge le suivi de la progression des tâches en cours.
Et un Thread est fondamentalement l'élément principal du multithreading qu'un développeur peut utiliser avec l'inconvénient suivant:
Si vous utilisez les threads Java, vous devez gérer les exigences suivantes dans votre propre code:
- Synchronisation avec le fil principal si vous publiez des résultats en retour sur l'interface utilisateur
- Pas de défaut pour annuler le fil
- Pas de pool de threads par défaut
- Pas de valeur par défaut pour gérer les changements de configuration dans Android
Et en ce qui concerne la AsyncTask, comme l'indique le référence du développeur Android :
AsyncTaskpermet d'utiliser correctement et facilement le fil de l'interface utilisateur. Cette classe permet d'effectuer des opérations en arrière-plan et de publier des résultats sur le thread d'interface utilisateur sans avoir à manipuler des threads et/ou des gestionnaires.
AsyncTaskest conçu pour être une classe d'assistance autour deThreadetHandleret ne constitue pas un framework de threading générique. AsyncTasks devrait idéalement être utilisé pour des opérations courtes (quelques secondes au maximum). Si vous devez maintenir les threads en cours d'exécution pendant de longues périodes, il est vivement recommandé d'utiliser les différentes API fournies par le package Java.util.concurrent, telles que Executor, ThreadPoolExecutor et FutureTask.
Mise à jour de mai 2015: J'ai trouvé une excellente série de conférences couvrant ce sujet. .
Voici la recherche sur Google: conférence de Douglas Schmidt Android accès simultané et synchronisation
Ceci est la vidéo de la première conférence sur YouTube
Tout cela fait partie de la CS 282 (2013): Programmation système pour Android de la université de Vanderbilt . Voici le Playlist YouTube
Douglas Schmidt semble être un excellent conférencier
Important: Si vous envisagez d'utiliser AsyncTask pour résoudre vos problèmes de threading, vous devez d'abord vérifier ReactiveX/RxAndroid pour un modèle de programmation éventuellement plus approprié. Une très bonne ressource pour obtenir une vue d'ensemble est Learning RxJava 2 pour Android par exemple .
Si nous regardons le code source, nous verrons que AsyncTask et Handler est purement écrit en Java. (Il y a cependant quelques exceptions. Mais ce n'est pas un point important)
Donc, il n'y a pas de magie dans AsyncTask ou Handler. Ces classes nous facilitent la vie en tant que développeur.
Par exemple: Si le programme A appelle la méthode A (), la méthode A() pourrait s’exécuter dans un autre thread avec le programme A. Nous pouvons facilement vérifier en utilisant le code suivant:
Thread t = Thread.currentThread();
int id = t.getId();
Pourquoi devrions-nous utiliser un nouveau fil pour certaines tâches? Vous pouvez google pour cela. De nombreuses raisons, par exemple: lever des charges lourdes, des travaux de longue haleine.
Alors, quelles sont les différences entre Thread, AsyncTask et Handler?
AsyncTask et Handler sont écrits en Java (ils utilisent en interne un Thread), donc tout ce que nous pouvons faire avec Handler ou AsyncTask , on peut aussi utiliser un Thread.
Qu'est-ce que Handler et AsyncTask peuvent vraiment aider?
La raison la plus évidente est la communication entre le thread appelant et le thread de travail. (Fil de l'appelant: Un fil qui appelle le Fil de travail pour effectuer certaines tâches. Un fil de l'appelant ne doit pas nécessairement être le fil de l'interface utilisateur). Bien sûr, nous pouvons communiquer entre deux threads d'une autre manière, mais la sécurité des threads présente de nombreux inconvénients (et dangers).
C'est pourquoi nous devrions utiliser Handler et AsyncTask. Ces classes font la plupart du travail pour nous, nous avons seulement besoin de savoir quelles méthodes remplacer.
La différence entre Handler et AsyncTask est la suivante: Utilisez AsyncTask lorsque Le fil de l'appelant est un Fil d’interface utilisateur . Voici ce que Android document dit:
AsyncTask permet d'utiliser correctement et facilement le thread d'interface utilisateur. Cette classe permet d'effectuer des opérations en arrière-plan et de publier des résultats sur le thread d'interface utilisateur sans avoir à manipuler des threads et/ou des gestionnaires.
Je veux souligner deux points:
1) Utilisation facile du fil d'interface utilisateur (à utiliser lorsque le fil appelant est un fil d'interface utilisateur).
2) Pas besoin de manipuler les gestionnaires. (signifie: vous pouvez utiliser Handler au lieu de AsyncTask, mais AsyncTask est une option plus facile).
Il y a beaucoup de choses dans ce post que je n'ai pas encore dites, par exemple: qu'est-ce que UI Thread, ou pourquoi c'est plus facile. Vous devez connaître certaines méthodes derrière chaque classe et l'utiliser, vous comprendrez parfaitement pourquoi.
@: en lisant le document Android, vous verrez:
Le gestionnaire vous permet d’envoyer et de traiter les objets Message et Runnable associés au MessageQueue d’un thread.
Cette description peut sembler étrange au début. Nous devons seulement comprendre que chaque fil a chaque file de messages (comme une liste de tâches) et qu'il prendra chaque message jusqu'à ce que la file soit vide (comme si nous finissions notre travail et allons au lit). Ainsi, lorsque Handler communique, il ne fait que donner un message au thread appelant et il attendra d'être traité.
Compliqué? Rappelez-vous simplement que Handler peut communiquer avec le thread appelant en toute sécurité.
Après avoir regardé en profondeur, c'est simple.
AsyncTask:
C'est un moyen simple d'utiliser un fil sans rien connaître du modèle de fil Java . AsyncTask donne différents rappels relatifs au thread de travail et au thread principal.
Utilisez pour les petites opérations d’attente comme suit:
- Récupération de certaines données de services Web et affichage par dessus la mise en page.
- Requête base de données.
- Lorsque vous réalisez que l'opération en cours ne sera jamais, jamais imbriquée.
Handler:
Lorsque nous installons une application sur Android, un thread est créé pour cette application, appelé MAIN UI Thread. Toutes les activités se déroulent dans ce fil. Selon la règle de modèle de thread unique Android, nous ne pouvons pas accéder directement aux éléments de l'interface utilisateur (bitmap, textview, etc.) pour un autre thread défini dans cette activité.
Un gestionnaire vous permet de communiquer avec le thread d'interface utilisateur à partir d'un autre thread d'arrière-plan. Ceci est utile dans Android, car Android n'autorise pas les autres threads à communiquer directement avec le thread d'interface utilisateur. Le gestionnaire peut envoyer et traiter les objets Message et Runnable associés au MessageQueue d’un thread. Chaque instance de gestionnaire est associée à un seul thread et à la file de messages de ce thread. Lorsqu'un nouveau gestionnaire est créé, il est lié au thread/à la file d'attente de messages du thread qui le crée.
C'est la meilleure solution pour:
- Il vous permet de faire la file d'attente des messages.
- Planification des messages.
Thread:
Il est maintenant temps de parler de fil.
Le fil est le parent de AsyncTask et Handler. Ils utilisent tous les deux en interne thread, ce qui signifie , vous pouvez également créer votre propre modèle de thread comme AsyncTask et Handler, mais cela nécessite une bonne connaissance de Implémentation multi-threading de Java .
Un AsyncTask est utilisé pour effectuer des calculs en arrière-plan et publier le résultat dans le thread d'interface utilisateur (avec des mises à jour de progression facultatives). Puisque vous n'êtes pas concerné par l'interface utilisateur, une Handler ou Thread semble plus appropriée.
Vous pouvez créer un arrière-plan Thread et transmettre des messages à votre thread principal à l'aide de la méthode Handler's post.
Android prend en charge les threads Java standard . Vous pouvez utiliser les threads standard et les outils du package “Java.util.concurrent” pour placer des actions en arrière-plan. La seule limitation est que vous ne pouvez pas mettre à jour directement l'interface utilisateur à partir du processus en arrière-plan.
Si vous devez mettre à jour l'interface utilisateur à partir d'une tâche en arrière-plan, vous devez utiliser certaines classes spécifiques à Android. Vous pouvez utiliser la classe "Android.os.Handler" pour ceci ou la classe "AsyncTask"
La classe “Handler” peut mettre à jour l'interface utilisateur. Un handle fournit des méthodes pour recevoir des messages et pour les runnables. Pour utiliser un gestionnaire, vous devez le sous-classer et remplacer handleMessage() pour traiter les messages. Pour traiter Runable, vous pouvez utiliser la méthode post(); Vous n'avez besoin que d'une seule instance d'un gestionnaire dans votre activité.
Votre thread peut poster des messages via la méthode sendMessage(Message msg) ou sendEmptyMessage.
Si vous avez un Activity qui doit télécharger du contenu ou effectuer des opérations pouvant être effectuées en arrière-plan, AsyncTask vous permet de gérer une interface utilisateur réactive et de publier la progression de ces opérations pour l'utilisateur.
Pour plus d'informations, vous pouvez consulter ces liens.
http://mobisys.in/blog/2012/01/Android-threads-handlers-and-asynctask-tutorial/
http://www.slideshare.net/HoangNgoBuu/Android-thread-handler-and -asynctask
Thread:
Vous pouvez utiliser new Thread pour les tâches d'arrière-plan de longue durée sans incidence sur le thread d'interface utilisateur. À partir de Java Thread, vous ne pouvez pas mettre à jour le thread de l'interface utilisateur.
Puisque la normale Thread n’est pas très utile pour l’architecture Android, des classes d’aide pour les threads ont été introduites.
Vous pouvez trouver des réponses à vos questions dans la page de documentation de performances du thread .
Un Handler vous permet d'envoyer et de traiter les objets Message et Runnable associés au MessageQueue d'un thread. Chaque instance Handler est associée à un seul thread et à la file de messages de ce thread.
Il y a deux utilisations principales pour un Handler:
Pour programmer des messages et des runnables à exécuter ultérieurement.
Pour mettre en file d'attente une action à effectuer sur un autre thread que le vôtre.
AsyncTask permet d'utiliser correctement et facilement le fil de l'interface utilisateur. Cette classe vous permet d'effectuer des opérations en arrière-plan et de publier des résultats sur le thread d'interface utilisateur sans avoir à manipuler les threads et/ou les gestionnaires.
Inconvénients:
Par défaut, une application transfère tous les objets
AsyncTaskqu'elle crée dans un seul thread. Par conséquent, ils s'exécutent en mode série et, comme pour le thread principal, un paquet de travail particulièrement long peut bloquer la file d'attente. Pour cette raison, utilisez AsyncTask pour gérer des éléments de travail dont la durée est inférieure à 5 ms .Les objets
AsyncTasksont également les auteurs les plus courants des problèmes de référence implicite. Les objetsAsyncTaskprésentent également des risques liés aux références explicites.
Vous aurez peut-être besoin d'une approche plus traditionnelle pour exécuter un bloc de travail sur un thread plus long (contrairement à AsyncTask, qui devrait être utilisé pour une charge de travail de 5 ms), ainsi que d'une certaine capacité à gérer ce flux de travail manuellement. Un thread de gestionnaire est effectivement un thread de longue durée qui récupère le travail d'une file d'attente et l'utilise.
Cette classe gère la création d'un groupe de threads, définit leurs priorités et gère la répartition du travail entre ces threads. Lorsque la charge de travail augmente ou diminue, la classe augmente ou détruit davantage de threads pour s'adapter à la charge de travail.
Si la charge de travail est de plus en plus simple et que HandlerThread ne suffit pas, vous pouvez choisir ThreadPoolExecutor
Cependant, je souhaiterais qu'une connexion socket s'exécute dans un service. Est-ce que cela devrait être exécuté dans un gestionnaire ou un thread, ou même une AsyncTask? L'interaction de l'interface utilisateur n'est pas nécessaire du tout. Cela fait-il une différence en termes de performances que j'utilise?
L'interaction de l'interface utilisateur n'étant pas obligatoire, vous ne pouvez pas choisir AsyncTask. Les threads normaux ne sont pas très utiles et donc HandlerThread est la meilleure option. Comme vous devez maintenir la connexion socket, Handler sur le thread principal n'est pas du tout utile. Créez un HandlerThread et obtenez un Handler du boucleur de HandlerThread.
HandlerThread handlerThread = new HandlerThread("SocketOperation");
handlerThread.start();
Handler requestHandler = new Handler(handlerThread.getLooper());
requestHandler.post(myRunnable); // where myRunnable is your Runnable object.
Si vous souhaitez communiquer avec le thread d'interface utilisateur, vous pouvez utiliser un autre gestionnaire pour traiter la réponse.
final Handler responseHandler = new Handler(Looper.getMainLooper()) {
@Override
public void handleMessage(Message msg) {
//txtView.setText((String) msg.obj);
Toast.makeText(MainActivity.this,
"Foreground task is completed:"+(String)msg.obj,
Toast.LENGTH_LONG)
.show();
}
};
dans votre Runnable, vous pouvez ajouter
responseHandler.sendMessage(msg);
Plus de détails sur la mise en œuvre peuvent être trouvés ici:
A mon avis, les threads ne sont pas le moyen le plus efficace de créer des connexions socket, mais ils offrent le plus de fonctionnalités en termes d'exécution de threads. Je dis cela parce que, par expérience, l'exécution de threads sur une longue période fait que les périphériques sont très chauds et utilisent beaucoup de ressources. Même un simple while(true) chauffera un téléphone en quelques minutes. Si vous dites que l'interaction de l'interface utilisateur n'est pas importante, peut-être une AsyncTask est-elle bonne, car elles sont conçues pour des processus à long terme. Ceci est juste mon avis à ce sujet.
UPDATE
S'il vous plaît ne pas tenir compte de ma réponse ci-dessus! J'ai répondu à cette question en 2011 alors que j'étais beaucoup moins expérimenté dans Android que je ne le suis maintenant. Ma réponse ci-dessus est trompeuse et est considérée comme fausse. Je le laisse là parce que beaucoup de gens l'ont commenté ci-dessous, me corrigeant et j'ai appris ma leçon.
Il y a de bien meilleures autres réponses sur ce fil, mais je vais au moins me donner une réponse plus appropriée. Il n'y a rien de mal à utiliser un fichier Java Thread normal; Cependant, vous devez vraiment faire attention à la façon dont vous l'implémentez, car le faire mal peut demander beaucoup de ressources au processeur (le symptôme le plus notable peut être le réchauffement de votre appareil). AsyncTasks sont assez idéaux pour la plupart des tâches que vous souhaitez exécuter en arrière-plan (les exemples courants sont les E/S de disque, les appels réseau et les appels de base de données). Cependant, AsyncTasks ne doit pas être utilisé pour des processus particulièrement longs qui peuvent avoir besoin de continuer une fois que l'utilisateur a fermé votre application ou mis son appareil en veille. Je dirais que dans la plupart des cas, tout ce qui n'appartient pas au fil de l'interface utilisateur peut être pris en charge dans un AsyncTask.
AsyncTask est conçu pour effectuer des opérations en arrière-plan ne nécessitant que quelques secondes (déconseillé pour les mégaoctets de téléchargement de fichiers à partir du serveur ou les tâches de calcul intensives telles que les opérations fichier IO). Si vous devez exécuter une opération de longue durée, il vous est vivement conseillé d'utiliser les threads natifs Java. Java vous donne diverses classes liées aux threads pour faire ce dont vous avez besoin. Utilisez Handler pour mettre à jour le thread de l'interface utilisateur.
public class RequestHandler {
public String sendPostRequest(String requestURL,
HashMap<String, String> postDataParams) {
URL url;
StringBuilder sb = new StringBuilder();
try {
url = new URL(requestURL);
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setReadTimeout(15000);
conn.setConnectTimeout(15000);
conn.setRequestMethod("POST");
conn.setDoInput(true);
conn.setDoOutput(true);
OutputStream os = conn.getOutputStream();
BufferedWriter writer = new BufferedWriter(
new OutputStreamWriter(os, "UTF-8"));
writer.write(getPostDataString(postDataParams));
writer.flush();
writer.close();
os.close();
int responseCode = conn.getResponseCode();
if (responseCode == HttpsURLConnection.HTTP_OK) {
BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream()));
sb = new StringBuilder();
String response;
while ((response = br.readLine()) != null){
sb.append(response);
}
}
} catch (Exception e) {
e.printStackTrace();
}
return sb.toString();
}
private String getPostDataString(HashMap<String, String> params) throws UnsupportedEncodingException {
StringBuilder result = new StringBuilder();
boolean first = true;
for (Map.Entry<String, String> entry : params.entrySet()) {
if (first)
first = false;
else
result.append("&");
result.append(URLEncoder.encode(entry.getKey(), "UTF-8"));
result.append("=");
result.append(URLEncoder.encode(entry.getValue(), "UTF-8"));
}
return result.toString();
}
}
Laissez-moi essayer de répondre à la question ici avec un exemple :) - MyImageSearch [Veuillez faire référence à l'image ici de l'écran d'activité principale - contenant un texte de saisie/un bouton de recherche/une vue en grille]
Description de MyImageSearch - Une fois que l'utilisateur a saisi les détails dans le champ de saisie et cliquez sur le bouton de recherche, nous allons rechercher des images sur Internet via les services Web fournis par flickr (il vous suffit de vous y enregistrer pour obtenir un jeton clé/secret) - pour la recherche, nous envoyons une requête HTTP et des données GET JSON en réponse contenant les URL des images individuelles que nous utiliserons ensuite pour charger la vue en grille.
My Implementation - Dans l'activité principale, je vais définir une classe interne qui étend l'AsyncTask pour envoyer la requête HTTP à la méthode doInBackGround, récupérer la réponse JSON et mettre à jour mon répertoire local. ArrayList de FlickrItems que je vais utiliser pour mettre à jour mon GridView via FlickrAdapter (étend l'adaptateur de base) et appeler le adapter.notifyDataSetChanged () dans onPostExecute () d'AsyncTask pour recharger l'affichage en grille. Notez qu'ici la requête HTTP est un appel bloquant pour lequel je l'ai fait via AsyncTask. Et, je peux mettre en cache les éléments dans l'adaptateur pour augmenter les performances ou les stocker sur une carte SD. La grille que je vais gonfler dans FlickrAdapter contient dans mon implémentation une barre de progression et une vue d'image. Vous trouverez ci-dessous le code de mainActivity que j'ai utilisé.
Réponse à la question maintenant - Donc, une fois que nous avons les données JSON pour récupérer des images individuelles, nous pouvons implémenter la logique consistant à obtenir les images en arrière-plan via des gestionnaires, des threads ou des tâches asynchrones. Nous devons noter ici que, puisque mes images une fois téléchargées doivent être affichées sur le fil de l'interface utilisateur/principal, nous ne pouvons pas simplement utiliser les fils tels qu'ils sont car ils n'ont pas accès au contexte. Dans FlickrAdapter, les choix auxquels je pouvais penser:
- Choix 1: Créez un LooperThread [étend le fil] - et continuez à télécharger des images séquentiellement dans un fil en gardant ce fil ouvert [looper.loop ()]
- Choix 2: Utilisez un pool de threads et postez le fichier exécutable via myHandler qui contient une référence à mon ImageView, mais comme les vues en mode Grille sont recyclées, le problème peut se produire lorsque l'image à l'index 4 est affichée à l'index 9 prendre plus de temps]
- Choix 3 [J'ai utilisé cela]: Utilisez un pool de threads et envoyez un message à myHandler, qui contient des données relatives à l'index d'ImageView et à ImageView lui-même. ImageView uniquement si currentIndex correspond à l'index de l'image que nous avons essayé de télécharger
- Choix 4: Utilisez AsyncTask pour télécharger les images en arrière-plan, mais ici, je n'aurai pas accès au nombre de threads que je veux dans le pool de threads. Cela varie selon les versions Android, mais dans Choix 3. Je peux prendre une décision consciente de la taille du pool de threads en fonction de la configuration de périphérique utilisée.
Voici le code source:
public class MainActivity extends ActionBarActivity {
GridView imageGridView;
ArrayList<FlickrItem> items = new ArrayList<FlickrItem>();
FlickrAdapter adapter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
imageGridView = (GridView) findViewById(R.id.gridView1);
adapter = new FlickrAdapter(this, items);
imageGridView.setAdapter(adapter);
}
// To avoid a memory leak on configuration change making it a inner class
class FlickrDownloader extends AsyncTask<Void, Void, Void> {
@Override
protected Void doInBackground(Void... params) {
FlickrGetter getter = new FlickrGetter();
ArrayList<FlickrItem> newItems = getter.fetchItems();
// clear the existing array
items.clear();
// add the new items to the array
items.addAll(newItems);
// is this correct ? - Wrong rebuilding the list view and should not be done in background
//adapter.notifyDataSetChanged();
return null;
}
@Override
protected void onPostExecute(Void result) {
super.onPostExecute(result);
adapter.notifyDataSetChanged();
}
}
public void search(View view) {
// get the flickr data
FlickrDownloader downloader = new FlickrDownloader();
downloader.execute();
}
@Override
public boolean onCreateOptionsMenu(Menu menu) {
// Inflate the menu; this adds items to the action bar if it is present.
getMenuInflater().inflate(R.menu.main, menu);
return true;
}
@Override
public boolean onOptionsItemSelected(MenuItem item) {
// Handle action bar item clicks here. The action bar will
// automatically handle clicks on the Home/Up button, so long
// as you specify a parent activity in AndroidManifest.xml.
int id = item.getItemId();
if (id == R.id.action_settings) {
return true;
}
return super.onOptionsItemSelected(item);
}
}
J'espère que ma réponse, si longue que cela puisse être, aidera à comprendre certains des détails les plus fins.
Cela dépend lequel choisir est basé sur l'exigence
Handler est principalement utilisé pour passer d'un autre thread à un thread principal, Handler est attaché à un boucleur sur lequel il affiche sa tâche exécutable en file d'attente. Donc, si vous êtes déjà dans un autre thread et que vous passez au thread principal, vous avez besoin d'un handle plutôt que d'une tâche async ou d'un autre thread
Si le gestionnaire créé dans un thread autre que le thread principal qui n'est pas un boucleur ne générera pas d'erreur car le gestionnaire est créé dans le thread, ce thread doit être transformé en lopper.
AsyncTask est utilisé pour exécuter du code pendant quelques secondes qui s'exécutent sur le thread d'arrière-plan et donnent son résultat au thread principal ** * Limitations AsyncTask 1. La tâche asynchrone n'est pas attachée au cycle de vie d'activité et qu'il continue à fonctionner même si son activité est détruite alors que le chargeur n'a pas cette limitation 2. Toutes les tâches asynchrones partagent le même thread d'arrière-plan pour l'exécution, ce qui a également une incidence sur les performances de l'application.
Thread est également utilisé dans l'application pour le travail en arrière-plan, mais il n'a pas de rappel sur le thread principal. Si l'exigence convient à certains threads au lieu d'un thread et qu'il faut donner la tâche à plusieurs reprises, alors l'exécuteur de pool de threads est la meilleure option.Eg Exigence de chargement d'image à partir de plusieurs URL, comme glide.
Fil de discussion
Lorsque vous démarrez une application, un processus est créé pour exécuter le code. Pour utiliser efficacement les ressources informatiques, des threads peuvent être démarrés dans le processus afin que plusieurs tâches puissent être exécutées simultanément. Les threads vous permettent donc de créer des applications efficaces en utilisant efficacement les processeurs, sans temps d'inactivité.
Sous Android, tous les composants s'exécutent sur un seul thread appelé principal. Android tâches de la file d'attente du système et les exécuter une par une sur le thread principal. Lorsque des tâches longues sont exécutées, l'application ne répond plus.
Pour éviter cela, vous pouvez créer des threads de travail et exécuter des tâches en arrière-plan ou de longue durée.
Gestionnaire
Puisque Android utilise un modèle à un seul thread, les composants de l'interface utilisateur sont créés non thread-safe, ce qui signifie que seul le thread qu'il a créé doit y accéder, ce qui signifie que le composant d'interface utilisateur doit être mis à jour uniquement sur le thread principal. En tant que composant d'interface utilisateur exécuté sur le thread principal, les tâches qui s'exécutent sur des threads de travail ne peuvent pas modifier les composants d'interface utilisateur. C'est là que Handler entre en image. Le gestionnaire à l'aide de Looper peut se connecter à un nouveau thread ou à un thread existant et exécuter le code qu'il contient sur le thread connecté.
Handler rend possible la communication entre threads. À l'aide de Handler, le thread d'arrière-plan peut lui envoyer des résultats et le gestionnaire connecté au thread principal peut mettre à jour les composants d'interface utilisateur sur le thread principal.
AsyncTask
AsyncTask fourni par Android utilise à la fois le fil et le gestionnaire pour faciliter l'exécution de tâches simples en arrière-plan et la mise à jour des résultats d'un fil à l'autre.
S'il vous plaît voir threads Android, gestionnaire, asynctask et les pools de threads pour des exemples.
Handler - est un support de communication entre les threads. Dans Android, il est principalement utilisé pour communiquer avec le fil principal en créant et en envoyant des messages via un gestionnaire.
AsyncTask - est utilisé pour exécuter des applications de longue durée dans un thread d'arrière-plan. Avec nAsyncTask vous pouvez effectuer l’opération dans un thread en arrière-plan et obtenir le résultat dans le thread principal de l’application.
Thread - est un processus léger, permettant d'obtenir une utilisation simultanée et simultanée maximale du processeur. Dans Android, vous pouvez utiliser un fil pour effectuer des activités qui ne touchent pas l'interface utilisateur de l'application.