Handlers et fuites de mémoire dans Android

Question

Veuillez consulter le code ci-dessous :

public class MyGridFragment extends Fragment{

    Handler myhandler = new Handler() {
        @Override
        public void handleMessage(Message message) {
            switch (message.what) {
                case 2:   
                    ArrayList<HashMap<String,String>> theurls = (ArrayList<HashMap<String,String>>) message.obj;
                    urls.addAll(theurls);
                    theimageAdapter.notifyDataSetChanged();
                    dismissBusyDialog();
                    break;
            }
        }
    }
}

Lorsque j'utilise un gestionnaire comme celui-ci, j'obtiens un avertissement "le gestionnaire doit être statique, sinon il est sujet à des fuites de mémoire". Quelqu'un peut-il me dire quelle est la meilleure façon de procéder ?

Answer 1

J'ai récemment mis à jour quelque chose de similaire dans mon propre code. J'ai simplement fait de la classe anonyme Handler une classe interne protégée et l'avertissement de Lint a disparu. Voyez si quelque chose comme le code ci-dessous fonctionnera pour vous :

public class MyGridFragment extends Fragment{

    static class MyInnerHandler extends Handler{
        WeakReference<MyGridFragment> mFrag;

        MyInnerHandler(MyGridFragment aFragment) {
            mFrag = new WeakReference<MyGridFragment>(aFragment);
        }

        @Override
        public void handleMessage(Message message) {
            MyGridFragment theFrag = mFrag.get();
            switch (message.what) {
            case 2:
                ArrayList<HashMap<String,String>> theurls = (ArrayList<HashMap<String,String>>) message.obj;
                theFrag.urls.addAll(theurls);
                theFrag.theimageAdapter.notifyDataSetChanged();
                theFrag.dismissBusyDialog();
                break;
            }//end switch
        }
    }
    MyInnerHandler myHandler = new MyInnerHandler(this);
}

Vous devrez peut-être changer l'endroit où j'ai mis "theFrag." car je ne pouvais que deviner ce à quoi ils faisaient référence.

Answer 2

Voici un petit cours assez utile que j'ai fait et que vous pouvez utiliser. Malheureusement, elle est encore assez verbeuse car vous ne pouvez pas avoir de classes internes statiques anonymes.

import java.lang.ref.WeakReference;
import android.os.Handler;
import android.os.Message;

/** A handler which keeps a weak reference to a fragment. According to
 * Android's lint, references to Handlers can be kept around for a long
 * time - longer than Fragments for example. So we should use handlers
 * that don't have strong references to the things they are handling for.
 * 
 * You can use this class to more or less forget about that requirement.
 * Unfortunately you can have anonymous static inner classes, so it is a
 * little more verbose.
 * 
 * Example use:
 * 
 *  private static class MsgHandler extends WeakReferenceHandler<MyFragment>
 *  {
 *      public MsgHandler(MyFragment fragment) { super(fragment); }
 * 
 *      @Override
 *      public void handleMessage(MyFragment fragment, Message msg)
 *      {
 *          fragment.doStuff(msg.arg1);
 *      }
 *  }
 * 
 *  // ...
 *  MsgHandler handler = new MsgHandler(this);
 */
public abstract class WeakReferenceHandler<T> extends Handler
{
    private WeakReference<T> mReference;

    public WeakReferenceHandler(T reference)
    {
        mReference = new WeakReference<T>(reference);
    }

    @Override
    public void handleMessage(Message msg)
    {
        if (mReference.get() == null)
            return;
        handleMessage(mReference.get(), msg);
    }

    protected abstract void handleMessage(T reference, Message msg);
}

Answer 3

Par le Modifications de l'ADT 20 il semble que vous devriez le rendre statique.

Nouveaux contrôles de peluches :

Vérifiez que les classes Fragment sont instanciables. Si vous faites accidentellement un fragment non statique, ou oubliez d'avoir un constructeur par défaut, vous pouvez rencontrer des erreurs d'exécution lorsque le système tente de réinstancier votre fragment après la configuration. erreurs d'exécution lorsque le système tente de réinstancier votre fragment après un changement de configuration.

Recherchez les fuites du manipulateur : Cette vérification permet de s'assurer qu'une classe interne de gestionnaire ne contient pas une référence implicite à sa classe externe.

Answer 4

Si vous lisez les docs sur AccountManager ou PendingIntent, vous verrez que certaines méthodes prennent Handler comme un des arguments.

Par exemple :

• onFinished - L'objet à rappeler lorsque l'envoi est terminé, ou null pour aucun callback.
• handler - Handler identifiant le thread sur lequel le callback doit se produire . S'il est nul, le rappel se fera à partir du pool de threads du processus.

Imaginez la situation. Une activité appelle PendingIntent.send(...) et met la sous-classe interne non statique de Handler. Et puis l'activité est détruite. Mais la classe interne vit.

La classe interne a toujours un lien avec l'activité détruite, elle ne peut pas être collectée à la poubelle.

Si vous ne prévoyez pas d'envoyer votre gestionnaire à de telles méthodes, vous n'avez pas à vous inquiéter.

Answer 5

Je rencontre le même problème et je trouve que c'est l'un de ces sujets avec beaucoup de questions et peu de réponses. Ma solution est simple et j'espère qu'elle pourra aider quelqu'un :

/* BEFORE */
private Handler mHandler= new Handler() {
        @Override public void handleMessage(Message msg) {
        this.doSomething();
    };
};

Nous pouvons créer une sous-classe de Handler statique qui exécute simplement un Runnable. L'instance réelle du gestionnaire saura quoi faire par le biais du Runnable qui aura accès aux variables d'instance.

/* AFTER */
static class RunnableHandler extends Handler {
    private Runnable mRunnable;
    public RunnableHandler(Runnable runnable) { 
        mRunnable = runnable;
    }
    @Override public void handleMessage(Message msg) {
        mRunnable.run();
    };
}
private RunnableHandler mHandler = new RunnableHandler(new Runnable() {
    @Override public void run() {
        this.doSomething();
    } });

L'avertissement a disparu alors que la fonctionnalité est la même.