¿Por qué usar HandlerThread en Android?

Utilizaría HandlerThread en caso de que desee realizar tareas de fondo una a la vez y desea que esas tareas se ejecuten en el orden de ejecución.

Por ejemplo, si desea realizar varias operaciones de fondo de red una por una.

Sí, el HandlerThread tiene su propio looper y los manejadores se pueden crear y publicar, (por lo que no bloquearía el hilo principal).

Como Doc dice:

Clase práctica para iniciar un nuevo hilo que tiene un looper.
El looper puede utilizarse para crear clases de manejadores.
Tenga en cuenta que start () aún debe llamarse.

HanderThread clase HanderThread hereda de la clase Thread, que encapsula el objeto Looper, por lo que no nos importan los detalles de apertura y liberación de Looper. Como en el caso de un hilo normal, necesitamos usar Looper.prepare() y Looper.loop() para convertirlo en LooperThread .

La forma normal de utilizar HandlerThread como este:

 HandlerThread thread = new HandlerThread("A Handler Thread"); thread.start(); Handler handler = new Handler(thread.getLooper()){ @Override public void handleMessage(Message msg) { //.... } }; 

Porque HandlerThread puede crear un Looper para Handler, es un tipo de forma conveniente.

Cuando crea un nuevo Handler, está enlazado a la fila / cola de mensajes del subproceso que lo está creando – vea documentos oficiales …

HandlerThread es útil cuando se desea ejecutar muchas tareas de fondo, ya que tiene su propio looper. Normalmente, si publica un mensaje en un Handler, utiliza el looper de MainThread. Esto significa que la tarea se ejecuta en el subproceso de interfaz de usuario. Pero en el caso de HandlerThread, estas tareas se ejecutan en el subproceso de trabajo. Puede encontrar una explicación más detallada aquí

De la documentación oficial de Handler :

Handler se asocia con un solo subproceso y la cola de mensajes del subproceso. Cuando crea un nuevo Handler , está enlazado a la fila / cola de mensajes del subproceso que lo está creando. A partir de ese momento, entregará mensajes y ejecutables a esa cola de mensajes y los ejecutará a medida que salgan del mensaje cola.

Hay dos usos principales para un manejador:

1. Para programar los mensajes y ejecutables que se ejecutarán como un punto en el futuro
2. Para enqueue una acción que se realizará en un hilo diferente que el suyo propio.

Cuando se crea un proceso para su aplicación, su hilo principal está dedicado a ejecutar una cola de mensajes que se encarga de administrar los objetos de aplicación de nivel superior ( actividades, receptores de difusión , etc.) y cualquier ventana que cree. Puede crear sus propios subprocesos y comunicarse con el hilo principal de la aplicación a través de un controlador .

Esto se hace llamando al mismo post o métodos sendMessage como antes, pero desde su nuevo hilo. El Runnable o Mensaje dado se programarán en la cola de mensajes del Handler y se procesarán cuando sea apropiado.

Si no utilizo un HandlerThread (pasa su Looper al Handler), significa eso en este caso Handler use MainThread (UI Thread) 's Looper?

Si lo escribes como a continuación, utiliza el hilo principal.

 Handler mHandler = new Handler(Looper.getMainLooper(); 

Si escribe es como se HandlerThread continuación, utiliza HandlerThread

 HandlerThread handlerThread = new HandlerThread("HandlerThread"); handlerThread.start(); Handler requestHandler = new Handler(handlerThread.getLooper()); 

Si tiene alguna operación de E / S de red en la tarea Runnable , no puede utilizar el Runnable subproceso principal. En ese caso, HandlerThread es útil para publicar la tarea Runnable realiza la operación de red IO.

¿Qué resultado obtendrá si Handler utiliza Looper de MainThread? ¿Puede bloquear mainThread?

Si desea que Handler procese mensajes de forma asíncrona, configure el parámetro asíncrono como true durante la construcción.

Puede comprobar grepcode para la implementación de Handler

Implementación del constructor:

 /** * Use the {@link Looper} for the current thread * and set whether the handler should be asynchronous. * * Handlers are synchronous by default unless this constructor is used to make * one that is strictly asynchronous. * * Asynchronous messages represent interrupts or events that do not require global ordering * with respect to synchronous messages. Asynchronous messages are not subject to * the synchronization barriers introduced by {@link MessageQueue#enqueueSyncBarrier(long)}. * * @param async If true, the handler calls {@link Message#setAsynchronous(boolean)} for * each {@link Message} that is sent to it or {@link Runnable} that is posted to it. * * @hide */ public Handler(boolean async) { this(null, async); } public Handler(Looper looper, Callback callback, boolean async) { mLooper = looper; mQueue = looper.mQueue; mCallback = callback; mAsynchronous = async; }