Android: RunOnUiThread vs AsyncTask

Creo que Google sugiere a los desarrolladores usar AsyncTask. Sin embargo, me gustaría saber cómo es diferente de usar ‘new Thread’ y luego llamar ‘RunOnUiThread’ en rendimiento y eficiencia de la memoria.

Ejemplo para usar RunOnUithread:

// some code #1 Thread t = new Thread("Thread1") { @Override public void run() { // some code #2 runOnUiThread(new Runnable() { public void run() { // some code #3 (that needs to be ran in UI thread) } }); } }; t.start(); 

vs.

AsyncTask:

 onPreExecute() { // some code #1 } doInBackground() { // some code #2 } onPostExecute() { // some code #3 } 

¿Cuáles son las ventajas / desventajas?

Editar:

No estoy buscando respuestas como “más fácil ver el código”, “conveniente para desarrolladores”, etc. En realidad estoy buscando difusiones técnicas detrás de la escena.

Por ejemplo, la respuesta de Paul Nikonowicz a continuación habría sido la respuesta que quería ver. (Pero AsyncTask se comporta de la misma manera)

Cuando usas un new Thread , realmente estás creando un nuevo hilo cada vez que lo ejecutas. AsyncTask embargo, AsyncTask utiliza un conjunto estático de un máximo de 128 subprocesos y reutilizará un subproceso antiguo siempre que exista. Por lo tanto, ejecutar AsyncTask 10 veces en serie solo creará un hilo que ejecute la tarea 10 veces en lugar de 10 hilos.

Esa es una de las diferencias entre muchas.

Es una conveniencia, esencialmente. El marco AsyncTask ocupa de la administración del conjunto de Thread y proporciona una interfaz simple y comprensible. Es bien sabido, por aquellos que saben cómo usar AsyncTask , que la actividad de IU puede continuar en onPreExecute() , onPostExecute() y onProgressUpdate() , y que todo el “trabajo pesado” se realiza en doInBackground() donde no puedes tocar la IU.

Hace que sea más fácil para un desarrollador tener una simple tarea en segundo plano que pueda publicar actualizaciones en el hilo de la interfaz de usuario y devolver los resultados cuando haya terminado. No es magia, es solo una conveniencia.

De acuerdo con esto , AsyncTask es más fácil de usar, pero tiene algunas limitaciones como las siguientes:

  • El tamaño del grupo principal y la cola de trabajo son fijos: 5 pools / 10 elementos
    • está codificado y no se puede cambiar
  • La prioridad del subproceso se fija en baja
  • El manejo de excepciones no es tan compatible como con Thread

También habrá otra diferencia que no he descubierto. Puedes encontrar e inspeccionar el código fuente completo de AsyncTask ya que Android es de código abierto 🙂

¡Diviértete con la encoding en Android!

La principal desventaja es que usar su propio hilo mantendrá viva su actividad cuando se llame al final. Android le dará tiempo a su actividad para que finalicen todos sus hilos. Esto tiene el efecto de crear una pérdida de actividad que eventualmente hará que su aplicación se ejecute muy lentamente hasta que su aplicación sea forzada a salir del usuario o del sistema operativo.

Puede verificar esto mirando su proceso en ADB. Incluso cuando la actividad finalice, igual la verás colgando de recursos.

Por lo tanto, si usa su propio hilo, asegúrese de administrarlo. O solo usa las api de Android. la decisión es tuya.

Estos son HUGELY diferentes.

  • Primero, TODA la interacción del usuario se realiza en el hilo principal y en todos los gráficos.
  • Second AsyncTask está diseñado para breves impulsos de actividad dedicada, como descargar un archivo o cargar algunos datos.
  • En tercer lugar, porque todas las interacciones de UI e usuario se realizan en el hilo principal, si comienzas a empujar cosas hacia este hilo, el dispositivo parecerá retrasarse y será menos sensible a los comandos del usuario.

La única razón por la que desea ejecutar algo en el hilo de la interfaz de usuario es interactuar con widgets. Aparte de eso, si desea hacer un procesamiento largo, use una AsyncTask .

Editar:

Puede descargar sus datos en un hilo separado, y no tengo problemas con eso. El problema surge cuando quieres actualizar la UI. Solo, es imposible modificar la UI desde un hilo secundario. En su lugar, deberá crear un controlador vinculado al subproceso de interfaz de usuario o crear un nuevo subproceso que esté destinado a ejecutarse en el subproceso de la interfaz de usuario (como en su ejemplo). Esto no solo es tedioso, sino una pérdida trágica de recursos. AsyncTask se ocupa de esto de manera simple y eficiente.

Para abordar su último punto, tiene razón. AsyncTask tiene acceso al hilo principal en pre / postExecute. Sin embargo, el procesamiento (la fuente principal del desfase UI) que la tarea está realizando no lo es. Con la tarea, la interfaz de usuario solo se verá afectada en función de lo que está dibujando, en lugar de tener que esperar a que la tarea finalice su trabajo y cualquier dibujo que desee.