Android Threading: Esta clase de Handler debe ser estática o pueden producirse fugas
Estoy usando un objeto handler para continuar el trabajo de interfaz de usuario después de haber terminado una tarea que consume mucho tiempo en un subproceso separado. Tenía un problema de la advertencia anterior de Lint y el siguiente fue mi enfoque.
[Tipo de objeto de controlador de ejemplo 1] ->
- Cómo realizar una búsqueda binaria de un archivo de texto
- LibGDX ScrollPane que muestra la pantalla negra
- Desapertar una cadena
- Convertir la matriz de bytes de 4 bits en escala de grises a Bitmap Android
- Ya administra un GoogleApiClient con id 0 En FRAGMENT
Handler responseHandler = new Handler() { @Override public void handleMessage(Message msg) { super.handleMessage(msg); Toast.makeText(MainActivity.this, "Finished the long running task in seperate thread...", Toast.LENGTH_LONG).show(); } };
[Tipo de objeto de controlador de ejemplo 2] ->
Handler responseHandler = new Handler(new Handler.Callback() { @Override public boolean handleMessage(Message msg) { Toast.makeText(MainActivity.this, "Finished long running task in a seperate thread...", Toast.LENGTH_LONG).show(); return false; // RETURN VALUE ???? } });
En el hilo separado (que no sea UI) cuando se realiza la tarea que lleva mucho tiempo, ejecuta la siguiente línea para devolver el control al subproceso UI (básicamente al manipulador obj).
responseHandler.sendEmptyMessage(0);
El programa funciona muy bien con ambos tipos de objetos de manejador, pero con el primer tipo estoy recibiendo una advertencia de Lint diciendo que esta clase de manejador debe ser estática o pueden producirse fugas .
Por lo tanto, empecé a usar el segundo tipo de objeto manejador para evitar la advertencia Lint, pero el problema que tengo es, no estoy seguro acerca del significado de valor de retorno (true / false) en la 2 ª manera y también funciona con cualquiera. Busqué esto en google por tanto, pero no obtuve una respuesta exacta explicó este valor de retorno.
Sí, vi que esta pregunta había pedido en muchos lugares en stackoverflow principalmente reacrding la advertencia Lint, pero mi pregunta es principalmente sobre el tipo de retorno en la 2 ª manera y para conseguir que confirme si está bien la manera de resolver el problema con el 2 º tipo Del manejador Obj.
Preguntas ->
1). ¿Alguien sabe qué exactamente este valor de retorno significa (verdadero / falso)?
2). ¿Es la cosa correcta que he hecho para deshacerse de la advertencia pelusa?
Gracias…
- Ejecutar bucle cada segundo java
- Carácter turco en SQLite mientras utiliza la expresión LIKE
- Android AnalogClock: configuración de programación por programación
- Manipule los bytes alfa de Java / color de Android int
- Recyclerview addOnItemTouchListener obtiene la vista previa que se hace clic en la fila
- Android Calendar obtiene el día de la semana actual como string
- Adición de carpetas de java al proyecto de estudio de Android
- ¿Qué biblioteca de tareas prioritarias de Android (Asynk Task, Multithreading) recomendaría para Android?
Cada manejador está vinculado al Looper de un subproceso, cada Message se coloca en una estructura de datos, una cola de mensajes.
Message tiene una variable de target que apunta a un Handler , una variable de callback que apunta a un Runnable .
Por lo tanto, si está utilizando una clase anónima para crear un objeto Handler (como en el primer ejemplo), entonces sepa que las clases internas anónimas / no estáticas contienen una referencia a objetos externos (Actividad?). Por lo tanto, el mensaje publicado en la cola, puede ser la celebración de referencias al Handler como objetivo, y el Handler a su vez la celebración de una referencia a la clase externa, como la Activity .
Ahora, un mensaje puede permanecer en la cola de mensajes durante largos intervalos de tiempo, siempre y cuando el subproceso esté en ejecución. Mientras tanto, la actividad puede haber sido despedida. Pero no será recogida basura debido a la oscura referencia indirecta de la misma, que tiene el mensaje. Tenga en cuenta que el Looper y la cola de mensajes permanecen siempre que el subproceso esté en ejecución.
En el segundo ejemplo, no está creando una clase Handler anónima. Está utilizando el constructor del controlador y pasándolo un objeto de Callback anónimo. Esto podría detener a Lint de quejarse, pero dudo que este sea un buen enfoque. Simplemente evite las clases internas, evite pasar las referencias de Actividad o contexto al Handler.
Actualizar:
El remitenteMensaje dispatchMessage() del manejador recibe los mensajes debido a ser procesados, donde comprueba si se ha proporcionado una devolución de llamada, entonces si se proporciona devolución de llamada, no llama a handleMessage() , si handleMessage() devuelve true:
public void dispatchMessage(Message msg) { if (msg.callback != null) { handleCallback(msg); } else { if (mCallback != null) { if (mCallback.handleMessage(msg)) { return; } } handleMessage(msg); //--won't be called if you return true. } }
Encontré información importante acerca de la pérdida de memoria por clase interna como manejador y quiero compartir contigo:
Cómo escapar de un contexto: Handlers & Inner Classes Y creo que el método anulado de clase Handler no devolverá nada como se puede comprobar: handleMessage ()
Ha reemplazado la clase Java Handler no Handler Android, puede ver handleMessage () de la clase Java Handler está teniendo declaración de retorno y puede comprobar la razón también para la instrucción return aquí: boolean handleMessage (contexto C)
- Marco de transición de Android Backport?
- Android cómo utilizar el adaptador para listView sin extender listaActividad