Ta klasa Handler powinna być statyczna, w przeciwnym razie mogą wystąpić wycieki: IncomingHandler

Tworzę aplikację na Androida 2.3.3 z usługą. Mam to wewnątrz tej usługi, aby komunikować się z główną działalnością:

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());
    [ ... ]
}

I tutaj final Messenger mMessenger = new Messenger(new IncomingHandler());pojawia się następujące ostrzeżenie Lint:

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

Co to znaczy?

Jeśli IncomingHandlerklasa nie jest statyczna, będzie miała odniesienie do twojego Serviceobiektu.

Handler wszystkie obiekty tego samego wątku współużytkują wspólny obiekt Looper, do którego wysyłają wiadomości i czytają.

Ponieważ wiadomości zawierają cel Handler, dopóki w kolejce komunikatów znajdują się komunikaty z funkcją obsługi, nie można wyrzucać pamięci. Jeżeli przewodnik nie jest statyczna, swoje Servicelub Activitynie mogą być zbierane śmieci, nawet po zniszczeniu.

Może to prowadzić do wycieków pamięci, przynajmniej przez jakiś czas - o ile wiadomości pozostają w kolejce. Nie stanowi to większego problemu, chyba że opublikujesz wiadomości z dużym opóźnieniem.

Możesz zrobić IncomingHandlerstatyczne i mieć WeakReferencedo swojej usługi:

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);
         }
    }
}

Zobacz ten post Romain Guy w celu uzyskania dalszych odniesień

Jak wspomnieli inni, ostrzeżenie Lint jest spowodowane potencjalnym wyciekiem pamięci. Możesz uniknąć ostrzeżenia Lint, przekazując a Handler.Callbackpodczas konstruowania Handler(tzn. Nie podklasujesz Handleri nie ma Handlerniestatycznej klasy wewnętrznej):

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

Jak rozumiem, nie pozwoli to uniknąć potencjalnego wycieku pamięci. Messageobiekty zawierają odniesienie do mIncomingHandlerobiektu, który zawiera odniesienie do Handler.Callbackobiektu, który zawiera odniesienie do Serviceobiektu. Dopóki w Looperkolejce komunikatów znajdują się komunikaty, Servicenie będzie to GC. Nie będzie to jednak poważny problem, chyba że w kolejce wiadomości znajdują się długie wiadomości opóźniające.

Oto ogólny przykład użycia słabej klasy referencyjnej i statycznej klasy procedury obsługi do rozwiązania problemu (zgodnie z zaleceniami w dokumentacji Lint):

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);
  }
}

Ten sposób działał dla mnie dobrze, utrzymuje kod w czystości, utrzymując miejsce, w którym obsługujesz komunikat w jego własnej klasie wewnętrznej.

Przewodnik, którego chcesz użyć

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

Klasa wewnętrzna

class IncomingHandlerCallback implements Handler.Callback{

        @Override
        public boolean handleMessage(Message message) {

            // Handle message code

            return true;
        }
}

Za pomocą odpowiedzi @ Sogger stworzyłem ogólny program obsługi:

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);
        }
    }
}

Interfejs:

public interface MessageHandler {

    void handleMessage(Message msg);

}

Używam tego w następujący sposób. Ale nie jestem w 100% pewien, czy to jest szczelne. Może ktoś mógłby to skomentować:

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;
        }
    }

    ...

}

Nie jestem pewien, ale możesz spróbować zainicjalizować moduł obsługi, aby null w onDestroy ()

Jestem zmieszany. Przykład, który znalazłem, całkowicie unika właściwości statycznej i wykorzystuje wątek interfejsu użytkownika:

    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();
                }
            }
        };
    }

W tym rozwiązaniu podoba mi się to, że nie ma problemu z mieszaniem zmiennych klas i metod.