Vous pouvez mieux comprendre ce qu'est Looper dans le contexte du framework GUI. Looper est fait pour faire 2 choses.
1) Looper transforme un thread normal , qui se termine lorsque sa méthode run () revient, en quelque chose exécuté en continu jusqu'à ce que l'application Android soit en cours d'exécution , ce qui est nécessaire dans le cadre de l'interface graphique (techniquement, il se termine toujours lorsque la méthode run () revient. Mais permettez-moi de clarifier ce que je veux dire ci-dessous).
2) Looper fournit une file d'attente où les travaux à effectuer sont mis en file d'attente, ce qui est également nécessaire dans le cadre de l'interface graphique.
Comme vous le savez peut-être, lorsqu'une application est lancée, le système crée un thread d'exécution pour l'application, appelé «principal», et les applications Android s'exécutent normalement entièrement sur un seul thread par défaut le «thread principal». Mais le fil principal n'est pas un fil spécial secret . C'est juste un thread normal similaire aux threads que vous créez avec du new Thread()code, ce qui signifie qu'il se termine lorsque sa méthode run () revient! Pensez à l'exemple ci-dessous.
public class HelloRunnable implements Runnable {
public void run() {
System.out.println("Hello from a thread!");
}
public static void main(String args[]) {
(new Thread(new HelloRunnable())).start();
}
}
Maintenant, appliquons ce principe simple aux applications Android. Que se passerait-il si une application Android s'exécute sur un thread normal? Un thread appelé "principal" ou "UI" ou quoi que ce soit qui démarre votre application, et dessine toute l'interface utilisateur. Ainsi, le premier écran s'affiche pour les utilisateurs. Et maintenant? Le fil principal se termine? Non, ça ne devrait pas. Cela devrait attendre que les utilisateurs fassent quelque chose, non? Mais comment pouvons-nous atteindre ce comportement? Eh bien, nous pouvons essayer avec Object.wait()ouThread.sleep(). Par exemple, le thread principal termine son travail initial pour afficher le premier écran et se met en veille. Il se réveille, ce qui signifie interrompu, lorsqu'un nouveau travail à faire est récupéré. Jusqu'ici tout va bien, mais pour le moment, nous avons besoin d'une structure de données de type file d'attente pour contenir plusieurs travaux. Pensez à un cas où un utilisateur touche l'écran en série et qu'une tâche prend plus de temps à se terminer. Donc, nous devons avoir une structure de données pour conserver les tâches à effectuer selon le principe du premier entré, premier sorti. En outre, vous pouvez imaginer que l'implémentation de threads toujours en cours d'exécution et de processus de travail à l'arrivée à l'aide d'une interruption n'est pas facile et conduit à un code complexe et souvent impossible à maintenir. Nous préférons créer un nouveau mécanisme à cet effet, et c'est ce que Looper est tout au sujet . Le document officiel de la classe Looperdit, "Les threads par défaut n'ont pas de boucle de message qui leur est associée", et Looper est une classe "utilisée pour exécuter une boucle de message pour un thread". Vous pouvez maintenant comprendre ce que cela signifie.
Pour rendre les choses plus claires, vérifions le code où le thread principal est transformé. Tout se passe dans la classe ActivityThread . Dans sa méthode main (), vous pouvez trouver ci-dessous le code, qui transforme un thread principal normal en quelque chose dont nous avons besoin.
public final class ActivityThread {
...
public static void main(String[] args) {
...
Looper.prepareMainLooper();
Looper.loop();
...
}
}
et Looper.loop()boucle de méthode à l'infini et retirer un message et traiter un à la fois:
public static void loop() {
...
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
...
msg.target.dispatchMessage(msg);
...
}
}
Donc, fondamentalement, Looper est une classe conçue pour résoudre un problème qui se produit dans le cadre de l'interface graphique. Mais ce genre de besoins peut également se produire dans d'autres situations. En fait, c'est un modèle assez célèbre pour l'application multi-threads, et vous pouvez en apprendre plus à ce sujet dans " Programmation simultanée en Java " par Doug Lea (en particulier, le chapitre 4.1.4 "Worker Threads" serait utile). En outre, vous pouvez imaginer que ce type de mécanisme n'est pas unique dans le cadre Android, mais tous les cadres GUI peuvent avoir besoin de quelque chose de similaire. Vous pouvez trouver presque le même mécanisme dans le framework Java Swing.
