Цей клас обробника повинен стати статичним або можуть виникати витоки: IncomingHandler

Я розробляю додаток Android 2.3.3 із сервісом. Я маю це всередині цієї служби для спілкування з Основною діяльністю:

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

І ось, final Messenger mMessenger = new Messenger(new IncomingHandler());я отримую таке попередження Lint:

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

Що це означає?

Якщо IncomingHandlerклас не є статичним, він матиме посилання на ваш Serviceоб’єкт.

Handler Об'єкти для однієї нитки мають спільний об'єкт Looper, з якого вони розміщують повідомлення та з яких читають.

Оскільки повідомлення містять ціль Handler, доки в черзі повідомлень є повідомлення з цільовим обробником, обробник не може збирати сміття. Якщо обробник не статичний, ваш Serviceабо Activityне може бути сміття, навіть після того, як руйнуються.

Це може призвести до витоку пам'яті, принаймні на деякий час - доки повідомлення не залишатимуться в черзі. Це не велика проблема, якщо ви не надсилаєте повідомлення із затримкою.

Ви можете IncomingHandlerстатично стати і мати WeakReferenceсвоє обслуговування:

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

Дивіться цю публікацію Ромена Гая для подальшого ознайомлення

Як уже згадували інші, попередження Lint - це через потенційну витік пам'яті. Ви можете уникнути попередження Lint, передавши a Handler.Callbackпри конструюванні Handler(тобто ви не підклас Handlerі немає Handlerнестатичного внутрішнього класу):

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

Як я розумію, це не уникне потенційного витоку пам'яті. Messageоб'єкти містять посилання на mIncomingHandlerоб'єкт, який містить посилання на Handler.Callbackоб'єкт, який містить посилання на Serviceоб'єкт. Поки в Looperчерзі повідомлень є повідомлення, ServiceGC не буде. Однак це не буде серйозною проблемою, якщо у черзі повідомлень не буде довгих повідомлень про затримку.

Ось загальний приклад використання слабкого довідкового та статичного класу обробників для вирішення проблеми (як рекомендовано в документації на 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);
  }
}

Цей спосіб добре працював для мене, зберігає код чистим, зберігаючи, де ви обробляєте повідомлення у своєму внутрішньому класі.

Обробник, який ви хочете використовувати

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

Внутрішній клас

class IncomingHandlerCallback implements Handler.Callback{

        @Override
        public boolean handleMessage(Message message) {

            // Handle message code

            return true;
        }
}

За допомогою відповіді @ Соггера я створив загальний обробник:

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

Інтерфейс:

public interface MessageHandler {

    void handleMessage(Message msg);

}

Я використовую його наступним чином. Але я не на 100% впевнений, що це безпечно. Можливо, хтось міг би прокоментувати це:

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

    ...

}

Я не впевнений, але ви можете спробувати інціалізуючий обробник, щоб запустити в onDestroy ()

Я збентежений. Я знайшов приклад уникає статичної властивості повністю і використовує потік інтерфейсу користувача:

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

Що мені подобається у цьому рішенні - немає проблем при спробі змішати змінні класу та методу.