Diese Handler-Klasse sollte statisch sein oder es könnten Lecks auftreten: IncomingHandler

Ich entwickle eine Android 2.3.3-Anwendung mit einem Dienst. Ich habe dies in diesem Dienst, um mit der Hauptaktivität zu kommunizieren:

public class UDPListenerService extends Service
{
    private static final String TAG = "UDPListenerService";
    //private ThreadGroup myThreads = new ThreadGroup("UDPListenerServiceWorker");
    private UDPListenerThread myThread;
    /**
     * Handler to communicate from WorkerThread to service.
     */
    private Handler mServiceHandler;

    // Used to receive messages from the Activity
    final Messenger inMessenger = new Messenger(new IncomingHandler());
    // Use to send message to the Activity
    private Messenger outMessenger;

    class IncomingHandler extends Handler
    {
        @Override
        public void handleMessage(Message msg)
        {
        }
    }

    /**
     * Target we publish for clients to send messages to Incoming Handler.
     */
    final Messenger mMessenger = new Messenger(new IncomingHandler());
    [ ... ]
}

Und hier, final Messenger mMessenger = new Messenger(new IncomingHandler());erhalte ich die folgende Lint-Warnung:

This Handler class should be static or leaks might occur: IncomingHandler

Was heißt das?

Wenn IncomingHandler Klasse ist nicht statisch, sie wird einen Verweis auf Ihre haben Service Objekt.

Handler Objekte für denselben Thread teilen sich alle ein gemeinsames Looper-Objekt, an das sie Nachrichten senden und von dem sie lesen.

Als Nachrichten Ziel enthalten Handler, solange Nachrichten mit Zielhandler in der Nachrichtenwarteschlange vorhanden sind, kann der Handler nicht von der Garbage Collection erfasst werden. Wenn der Handler nicht statisch ist, ist Ihr Service oder Activity kann nicht müllgesammelt werden, selbst nachdem es zerstört wurde.

Dies kann zumindest für einige Zeit zu Speicherlecks führen – solange die Nachrichten in der Warteschlange bleiben. Dies ist kein großes Problem, es sei denn, Sie posten lange verspätete Nachrichten.

Du kannst das schaffen IncomingHandler statisch und haben a WeakReference zu Ihren Diensten:

static class IncomingHandler extends Handler {
    private final WeakReference<UDPListenerService> mService; 

    IncomingHandler(UDPListenerService service) {
        mService = new WeakReference<UDPListenerService>(service);
    }
    @Override
    public void handleMessage(Message msg)
    {
         UDPListenerService service = mService.get();
         if (service != null) {
              service.handleMessage(msg);
         }
    }
}

Sieh dir das an Post von Romain Guy für weitere Referenzen

Wie andere bereits erwähnt haben, ist die Lint-Warnung auf das potenzielle Speicherleck zurückzuführen. Sie können die Lint-Warnung vermeiden, indem Sie a übergeben Handler.Callback beim konstruieren Handler (dh Sie machen keine Unterklassen Handler und es gibt keine Handler nichtstatische innere Klasse):

Handler mIncomingHandler = new Handler(new Handler.Callback() {
    @Override
    public boolean handleMessage(Message msg) {
        // todo
        return true;
    }
});

So wie ich es verstehe, wird dies das potenzielle Speicherleck nicht vermeiden. Message Objekte enthalten einen Verweis auf die mIncomingHandler Objekt, das eine Referenz enthält Handler.Callback Objekt, das einen Verweis auf die enthält Service Objekt. Solange es Nachrichten in der gibt Looper Nachrichtenwarteschlange, die Service wird nicht GC sein. Dies ist jedoch kein ernsthaftes Problem, es sei denn, Sie haben Nachrichten mit langer Verzögerung in der Nachrichtenwarteschlange.

Hier ist ein allgemeines Beispiel für die Verwendung einer schwachen Referenz und einer statischen Handler-Klasse, um das Problem zu lösen (wie in der Lint-Dokumentation empfohlen):

public class MyClass{

  //static inner class doesn't hold an implicit reference to the outer class
  private static class MyHandler extends Handler {
    //Using a weak reference means you won't prevent garbage collection
    private final WeakReference<MyClass> myClassWeakReference; 

    public MyHandler(MyClass myClassInstance) {
      myClassWeakReference = new WeakReference<MyClass>(myClassInstance);
    }

    @Override
    public void handleMessage(Message msg) {
      MyClass myClass = myClassWeakReference.get();
      if (myClass != null) {
        ...do work here...
      }
    }
  }

  /**
   * An example getter to provide it to some external class
   * or just use 'new MyHandler(this)' if you are using it internally.
   * If you only use it internally you might even want it as final member:
   * private final MyHandler mHandler = new MyHandler(this);
   */
  public Handler getHandler() {
    return new MyHandler(this);
  }
}

Dieser Weg hat für mich gut funktioniert, hält den Code sauber, indem er behält, wo Sie die Nachricht in seiner eigenen inneren Klasse behandeln.

Der Handler, den Sie verwenden möchten

Handler mIncomingHandler = new Handler(new IncomingHandlerCallback());

Die innere Klasse

class IncomingHandlerCallback implements Handler.Callback{

        @Override
        public boolean handleMessage(Message message) {

            // Handle message code

            return true;
        }
}

Mit Hilfe der Antwort von @Sogger habe ich einen generischen Handler erstellt:

public class MainThreadHandler<T extends MessageHandler> extends Handler {

    private final WeakReference<T> mInstance;

    public MainThreadHandler(T clazz) {
        // Remove the following line to use the current thread.
        super(Looper.getMainLooper());
        mInstance = new WeakReference<>(clazz);
    }

    @Override
    public void handleMessage(Message msg) {
        T clazz = mInstance.get();
        if (clazz != null) {
            clazz.handleMessage(msg);
        }
    }
}

Die Schnittstelle:

public interface MessageHandler {

    void handleMessage(Message msg);

}

Ich benutze es wie folgt. Aber ich bin mir nicht 100% sicher, ob das auslaufsicher ist. Vielleicht kann sich jemand dazu äußern:

public class MyClass implements MessageHandler {

    private static final int DO_IT_MSG = 123;

    private MainThreadHandler<MyClass> mHandler = new MainThreadHandler<>(this);

    private void start() {
        // Do it in 5 seconds.
        mHandler.sendEmptyMessageDelayed(DO_IT_MSG, 5 * 1000);
    }

    @Override
    public void handleMessage(Message msg) {
        switch (msg.what) {
            case DO_IT_MSG:
                doIt();
                break;
        }
    }

    ...

}

Ich bin mir nicht sicher, aber Sie können versuchen, den Handler in onDestroy () auf null zu initialisieren

Ich bin verwirrt. Das Beispiel, das ich gefunden habe, vermeidet die statische Eigenschaft vollständig und verwendet den UI-Thread:

    public class example extends Activity {
        final int HANDLE_FIX_SCREEN = 1000;
        public Handler DBthreadHandler = new Handler(Looper.getMainLooper()){
            @Override
            public void handleMessage(Message msg) {
                int imsg;
                imsg = msg.what;
                if (imsg == HANDLE_FIX_SCREEN) {
                    doSomething();
                }
            }
        };
    }

Was ich an dieser Lösung mag, ist, dass es kein Problem gibt, Klassen- und Methodenvariablen zu mischen.