Android: ¿Dejar de usar Looper?
Tengo un hilo que utilizo para actualizar periódicamente los datos de mi actividad. Crear el hilo e iniciar un looper para el uso de un controlador con postDelay()
. En onDestroy () para mi actividad, llamo a removeCallbacks () en mi manejador.
¿Debo entonces llamar a handler.getLooper().quit()
? ¿O no preocuparse de él y dejar el OS tratar de él? ¿O simplemente se ejecutaría para siempre, consumiendo ciclos de CPU?
- Cómo crear un hilo Looper, a continuación, enviar un mensaje de inmediato?
- cómo leer el flujo de entrada de socket en Android
- Qué cosas se ejecutan en el hilo principal de la interfaz de usuario al abrir una aplicación para Android
- Android claro hilo webview, libre de memoria, evitar OutOfMemoryError
- Detención de un subproceso dentro de un servicio
- Es la biblioteca Java.util.concurrent mejor al hacer cualquier tipo de tarea sobre el estándar Android AsyncTask
- Acceso de dominio a través de subprocesos con rxjava y dagger2
- Buenas prácticas: AsyncTask durante el cambio de orientación
- Diferencia entre AsyncTask y Thread / Runnable
- Equivalente a javax.swing.Timer en Android
- Bloqueo de archivos a través de servicios
- Seguridad de subprocesos al realizar iteraciones a través de un ArrayList utilizando foreach
- Compartir el contexto GLES20 y texturas entre GLSurfaceViews diferentes?
Según la documentación de Android , debe llamar a quit ().
Cuando llama Looper.loop()
se inicia un bucle while. Llamar Looper.quit()
hace que el bucle termine. El recolector de elementos no puede recolectar su objeto mientras se ejecuta el bucle.
Aquí está la sección correspondiente de Looper.java:
public static final void loop() { Looper me = myLooper(); MessageQueue queue = me.mQueue; while (true) { Message msg = queue.next(); // might block //if (!me.mRun) { // break; //} if (msg != null) { if (msg.target == null) { // No target is a magic identifier for the quit message. return; } if (me.mLogging!= null) me.mLogging.println( ">>>>> Dispatching to " + msg.target + " " + msg.callback + ": " + msg.what ); msg.target.dispatchMessage(msg); if (me.mLogging!= null) me.mLogging.println( "<<<<< Finished to " + msg.target + " " + msg.callback); msg.recycle(); } } } public void quit() { Message msg = Message.obtain(); // NOTE: By enqueueing directly into the message queue, the // message is left with a null target. This is how we know it is // a quit message. mQueue.enqueueMessage(msg, 0); }
Ahora no tengo la respuesta correcta, pero a juzgar por varias documentaciones y tutoriales que he visto en Internet, ninguno de ellos llama a handler.getLooper (). Quit (). Así que supongo que no es necesario hacerlo explícitamente.
Pero realmente no hay ningún inconveniente si se añade este one-liner a su método onDestroy ()?
- ¿Dónde puedo encontrar el archivo xml de configuración predeterminado de AlertDialog?
- ¿Por qué los eventos táctiles destruyen mi framerate de Android?