Android: Quittant le Looper?

J'ai un fil que j'utilise pour mettre à jour périodiquement les données dans mon Activité. J'ai créer le fil et commencer un looper à l'aide d'un gestionnaire avec postDelay(). Dans onDestroy() pour mon activité, j'appelle removeCallbacks() sur mon gestionnaire.

Dois-je puis appeler handler.getLooper().quit()? Ou vous inquiétez pas et laissez le système d'exploitation traiter avec elle? Ou serait-ce tout simplement courir pour toujours, consommation de cycles de PROCESSEUR?

OriginalL'auteur stormin986 | 2010-05-08

  1. 17

    Selon la Android Documentation vous devriez appeler quit().

    Lorsque vous appelez Looper.loop() une boucle while est commencé. L'appel de Looper.quit() provoque l'arrêt de la boucle. Le garbage collector ne peut pas recueillir votre objet lors de l'exécution de la boucle.

    Voici la section pertinente de Looper.java:

    public static final void loop() {
    Looper me = myLooper();
    MessageQueue queue = me.mQueue;
    while (true) {
        Message msg = queue.next(); //might block
        //if (!me.mRun) {
        //   break;
        //}
        if (msg != null) {
            if (msg.target == null) {
                //No target is a magic identifier for the quit message.
                return;
            }
            if (me.mLogging!= null) me.mLogging.println(
                    ">>>>> Dispatching to " + msg.target + " "
                    + msg.callback + ": " + msg.what
                    );
            msg.target.dispatchMessage(msg);
            if (me.mLogging!= null) me.mLogging.println(
                    "<<<<< Finished to    " + msg.target + " "
                    + msg.callback);
            msg.recycle();
        }
    }
}

public void quit() {
    Message msg = Message.obtain();
    //NOTE: By enqueueing directly into the message queue, the
    //message is left with a null target.  This is how we know it is
    //a quit message.
    mQueue.enqueueMessage(msg, 0);
}
    Je peux confirmer que cela fonctionne.

    OriginalL'auteur Jonathan

  2. 0

    Je n'ai pas maintenant la réponse correcte, mais à en juger par plusieurs documentations et tutoriels que j'ai vu sur Internet, aucun d'entre eux gestionnaire d'appel.getLooper().quit(). Donc, je suppose que ce n'est pas nécessaire de le faire explicitement.

    Mais il n'y a vraiment aucun inconvénient si vous venez d'ajouter ce one-liner à votre onDestroy() la méthode?

    Aucun inconvénient, au-delà de quelques cycles de processeur. Mais j'aime comprendre les nuances de la façon dont le système est à l'œuvre derrière les coulisses.

    OriginalL'auteur

  3. 0

    Ajoutant à la ci-dessus réponse par Jonathan, veuillez choisir judicieusement entre quitter() et quitSafely() comme quit() résilier sans traitement plus de messages dans la file d'attente de messages où que quitSafely() s'arrête dès que tous les autres messages dans la file d'attente de messages qui sont déjà dû être livrées ont été traitées

    OriginalL'auteur kAmol