Android : RunOnUiThread vs AsyncTask

Question

Je crois que Google suggère aux développeurs d'utiliser AsyncTask. Cependant, j'aimerais savoir en quoi cela diffère de l'utilisation de 'new Thread' et de l'appel à 'RunOnUiThread' en termes de performances et d'efficacité mémoire.

Exemple d'utilisation de RunOnUithread :

    // some code #1
    Thread t = new Thread("Thread1") {
        @Override
        public void run() {
            // some code #2
            runOnUiThread(new Runnable() {
                public void run() {
                    // some code #3 (that needs to be ran in UI thread)

                }
            });

        }
    };
    t.start();

vs.

AsyncTask :

onPreExecute() {
   // some code #1
}

doInBackground() {
   // some code #2
}

onPostExecute() {
   // some code #3
}

Quels sont les avantages / inconvénients ?

Edit :

Je ne cherche pas des réponses telles que "plus facile de voir le code", "pratique pour les développeurs", etc. Je cherche plutôt les différences techniques qui se cachent derrière la scène.

Par exemple, la réponse de Paul Nikonowicz ci-dessous aurait été la réponse que je voulais voir. (Mais AsyncTask se comporte de la même manière)

Answer 1

Lorsque vous utilisez new Thread vous créez vraiment un nouveau fil de discussion à chaque fois que vous l'exécutez. AsyncTask utilise cependant un pool statique de 128 threads maximum et réutilisera un ancien thread dès qu'il existe. Ainsi, l'exécution d'AsyncTask 10 fois en série ne créera qu'un seul thread qui exécute la tâche 10 fois au lieu de 10 threads.

C'est l'une des différences parmi tant d'autres.

Answer 2

C'est une commodité, essentiellement. Le site AsyncTask traite de la gestion de la Thread et fournit une interface simple et compréhensible. Il est bien connu -- par ceux qui savent comment utiliser AsyncTask -- que l'activité de l'assurance-chômage peut continuer dans onPreExecute() , onPostExecute() y onProgressUpdate() et que tout le "gros du travail" est fait dans les bureaux de la Commission européenne. doInBackground() où vous ne pouvez pas toucher l'interface utilisateur.

Il permet à un développeur de disposer d'une tâche d'arrière-plan simple qui peut facilement envoyer des mises à jour au fil d'exécution de l'interface utilisateur et renvoyer les résultats lorsqu'elle est terminée. Ce n'est pas de la magie, c'est juste une commodité.

Answer 3

Selon ce , AsyncTask est plus facile à utiliser, mais présente certaines limitations comme les suivantes :

• La taille du pool de base et de la file d'attente de travail est fixe : 5 pools / 10 éléments
  • c'est codé en dur et ne peut être modifié
• La priorité du fil est fixée à faible
• La gestion des exceptions n'est pas aussi bien supportée qu'avec Thread

Il y aura aussi une autre différence que je n'ai pas encore trouvée. Vous pouvez trouver et inspecter code source complet de AsyncTask puisque Android est un logiciel libre :-)

Passez un bon moment avec le codage dans Android !

Answer 4

Le principal inconvénient est que l'utilisation de votre propre Thread maintiendra votre activité en vie lorsque finish sera appelé. Android donnera à votre activité le temps que tous vos threads se terminent. Cela a pour effet de créer une fuite d'activité qui finira par rendre votre application très très lente jusqu'à ce qu'elle soit quittée de force par l'utilisateur ou le système d'exploitation.

Vous pouvez le vérifier en regardant votre processus dans ADB. Même lorsque l'activité est terminée, vous verrez qu'elle reste en suspens et qu'elle consomme des ressources.

Donc, si vous utilisez votre propre fil, assurez-vous de le gérer. Ou alors, utilisez simplement l'API Android.

Answer 5

Ils sont HAUTEMENT différents.

• Tout d'abord, TOUTES les interactions avec l'utilisateur sont effectuées sur le thread principal, ainsi que tous les travaux graphiques.
• Deuxièmement AsyncTask est conçu pour de courtes périodes d'activité dédiée, comme le téléchargement d'un fichier ou le chargement de données.
• Troisièmement, étant donné que l'interface utilisateur et les interactions avec l'utilisateur sont effectuées dans le fil d'exécution principal, si vous commencez à pousser des choses vers ce fil d'exécution, l'appareil semblera traîner et sera moins réactif aux commandes de l'utilisateur.

La seule raison pour laquelle vous voulez exécuter quelque chose dans le thread UI est pour interagir avec les widgets. En dehors de cela, si vous souhaitez effectuer un traitement long, utilisez un thread de type AsyncTask .

Edit :

Vous pouvez télécharger vos données dans un fil séparé, et je n'ai aucun problème avec cela. Le problème vient quand vous voulez mettre à jour l'interface utilisateur. Seul, il est impossible de modifier l'interface utilisateur à partir d'un thread enfant. Au lieu de cela, vous devrez créer soit un gestionnaire lié au thread de l'interface utilisateur, soit créer un nouveau thread destiné à s'exécuter dans le thread de l'interface utilisateur (comme dans votre exemple). Ce n'est pas seulement fastidieux, mais c'est aussi un gaspillage tragique de ressources. Le site AsyncTask s'en charge de manière simple et efficace.

Pour répondre à votre dernier point, vous avez raison. Le site AsyncTask a accès au thread principal en pré/post-exécution. Cependant, le traitement (la source principale du décalage de l'interface utilisateur) que la tâche est en train d'effectuer ne l'est pas. Avec la tâche, l'interface utilisateur ne sera affectée que par ce que vous dessinez, au lieu de devoir attendre que la tâche termine son travail et le dessin qu'elle veut faire.