Les gestionnaires et les fuites de mémoire dans Android

Regardez 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 le gestionnaire comme cela, je reçois un avertissement "gestionnaire doit être statique, sinon elle est sujette à des fuites de mémoire." Quelqu'un peut-il me dire quelle est la meilleure façon de le faire?

  • Je ne suis pas convaincu que vous êtes en utilisant le virage correctement. Jetez un oeil à ce guide: vogella.com/articles/AndroidPerformance/article.html. Ses pas déclaré comme statique dans l'exemple de code là. :/
  • Eh bien, même en l'utilisant comme ça me donne la même erreur. Ce n'est jamais utilisé pour arriver plus tôt jusqu'j'ai mis à jour mon android sdk de la nuit dernière. Déclarant simplement un gestionnaire comme une variable de classe apparaît cette charpie avertissement maintenant
  • Eh bien que diriez-vous simplement déclarer votre gestionnaire de statique?
  • Eh bien, je me réfère à la non-statiques, des objets à l'intérieur du gestionnaire
  • Découvrez ce blog pour une analyse plus approfondie
InformationsquelleAutor Rasmus | 2012-07-01
  1. 100

    J'ai récemment mis à jour quelque chose de similaire dans mon propre code. Je viens de faire l'anonyme de la classe de Gestionnaire d'un protégé de l'intérieur de la classe et de la Charpie avertissement s'en alla. Voir si quelque chose comme le code ci-dessous va travailler 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 pouvez avoir à changer où j'ai mis "theFrag." comme je ne pouvais que deviner ce que ceux qui sont référencés.

    • Cela semble être exactement ce que je veux . Je ne l'ai pas testé mais il semble y avoir aucune raison pourquoi il l'habitude de travailler.. Merci!
    • Ne devrait-il pas être un chèque après mFrag.get() pour vérifier si theFrag != null, car il peut rester des déchets collectés.
    • Dépend de votre cas d'utilisation. Mon code personnel fait l'intérieure de la classe statique définitions privé dans la plupart des cas parce que la classe anonyme définition n'est pas censé être utilisé ailleurs (même par les descendants). Lorsque restreint à la classe qu'il est défini dans les, chaque fois que le parent Fragment est détruit, notre homme intérieur de la classe de référence doit être détruit avant le Fragment devient NULLE. Nous utilisons WeakReference donc l'intérieur de notre classe n'interfère pas avec quand Fragment obtient des ordures collectées. Si vous faites votre intérieure publique de la classe, ou n'êtes pas sûr, veuillez vérifier pour voir si theFrag!=null avant de l'utiliser.
    • Cette réponse absolument m'a sauvé! Je vous remercie pour l'affichage de cette!
    • Est-il un avantage de cette approche plutôt que de faire le Gestionnaire statique?
    • oui, cette méthode expose les fonctions et visibles, les membres de la classe parent, qui peut ensuite être modifié en handleMessage() sans être déclarée statique. À l'aide de WeakReference permet au système de travail autour de la possibilité de Gestionnaire de fuites tout en évitant l'augmentation de la mémoire de l'empreinte que faire potentiellement tout à fait un peu de champs statiques imposerait
    • Mais le message est titulaire sur le Gestionnaire, c'est être envoyé. De cette façon, le fragment peut être détruit, mais le gestionnaire existe toujours en attente pour les messages, mais le WeakReference serait déjà null. Je pense que nous devrions vérifier le résultat de WeakRefernce.get() n'est pas nulle.

    InformationsquelleAutor Uncle Code Monkey
  2. 11

    Ici est un peu petite classe utile j'ai fait que vous pouvez utiliser. C'est malheureusement encore assez détaillé parce que vous ne pouvez pas avoir anonymes statique à l'intérieur des classes.

    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);
}
    • Si je n'ai pas besoin de remplacer handleMessage, il suffit d'utiliser un gestionnaire de post Exécutable, puis-je utiliser le nouveau Handler()
    • si (mReference.get() == null) return; handleMessage(mReference.get(), msg); est une mauvaise approche, car entre la valeur null vérifier et handleMessage la référence peut être encore gc ed provoquant l'exception de pointeur null, donc c'est une meilleure approche pour stocker la valeur de retour de la première en référence T = mReference.get() ; puis vérifier la valeur null et passer la variable locale à la méthode handleMessage.
    • Bon point terminal de Kerem. N'hésitez pas à modifier le code si vous le souhaitez!
    InformationsquelleAutor Timmmm
  3. 5

    Par la ADT 20 Changements, il semble que vous devriez en faire de l'électricité statique.

    Nouvelles Peluches Vérifie:

    Assurez-vous que le Fragment de classes sont instantiatable. Si vous avez accidentellement faire un
    fragment innerclass non-statique, ou d'oublier d'avoir un constructeur par défaut, vous pouvez frapper d'exécution
    les erreurs lorsque le système tente de retrouver votre fragment après un changement de configuration.

    Recherchez gestionnaire de fuites: Ce contrôle permet de s'assurer qu'un gestionnaire interne de la classe ne sont pas titulaires d'une
    référence implicite à l'extérieur de la classe.

    • alors, comment pensez-vous que je doit gérer la ci-dessus. avez-vous besoin de voir plus de code.. Si donc s'il vous plaît laissez-moi savoir
    • Si vous ne pouvez pas faire le Gestionnaire statique, la meilleure chose est peut-être pour le déplacer vers le parent de l'Activité et de passer une référence au Fragment.
    • Merci pour vos réponses Geobits...mais en le déplaçant à l'Activité parent encore l'habitude de faire la mise en garde d'aller.Bien que dans mon cas, l'intérieur de la classe l'habitude de vivre plus longtemps que celui de l'extérieur mais de se débarrasser de l'avertissement était quelque chose que j'étais plus inquiète.
    InformationsquelleAutor Geobits
  4. 4

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

    Par exemple:

    • onFinished - L'objet de retour d'appel lorsque l'envoi a terminé, ou null pas de rappel.
    • gestionnaire - Gestionnaire d'identifier le thread sur lequel la fonction de rappel doit arriver. Si la valeur est null, la fonction de rappel qui va arriver à partir du pool de threads du processus.

    Imaginer la situation. Certains d'Activité des appels PendingIntent.envoyer(...) et de mettre la non-statique intérieure sous-classe de Gestionnaire. Et puis l'activité est détruite. Mais à l'intérieur de la classe des vies.

    Intérieur de la classe elle détient toujours un lien vers détruit activité, il ne peut pas être récupérées.

    Si vous n'avez pas l'intention d'envoyer à votre gestionnaire de telles méthodes, vous n'avez rien à craindre.

    • Grâce QuickNick ... eh Bien, je ne suis d'accord avec vous quand vous dites "Si vous n'avez pas l'intention d'envoyer à votre gestionnaire de telles méthodes, vous n'avez rien à craindre." mais j'ai besoin de se débarrasser de cet avertissement
    InformationsquelleAutor QuickNick
  5. 0

    Je rencontre le même problème et je trouve que c'est un de ces sujets avec beaucoup de questions et peu de answeres. Ma solution est simple et j'espère que cela peut aider quelqu'un:

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

    Nous pouvons créer un Gestionnaire statique sous-classe qui fonctionne simplement un Exécutable. Le gestionnaire réel exemple de savoir quoi faire par le biais de l'exécutable qui auront accès à des 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 est allé tandis que la fonctionnalité est la même.

    • Merci pour la réponse Urkidi mais pour une raison que je trouve cela plus d'un hack. Je ne suis pas un expert en quelque sorte et peut être très mal
    • J'aime cette façon si j'aimerais quelqu'un avec un peu plus de connaissances laissez-moi savoir si c'est juste un hack autour.
    • Ce masque la charpie avertissement, mais ne permet pas de résoudre le problème sous-jacent. L'exécutable aurez une mention "ce", les et depuis le RunnableHandler maintient une référence vers l'exécutable que vous avez la même erreur, avec juste un plus tortueux de la chaîne.
    InformationsquelleAutor blurkidi
  6. 0

    Une solution simple pour ce cas, peut-être:

    Handler handler=new Handler(new Handler.Callback() {
    @Override
    public boolean handleMessage(Message message) {
        //do your stuff here
        return false;
    } });
    InformationsquelleAutor StartCoding