¿Por qué utilizar AsyncTaskLoader con LoaderManager, en lugar de Simple Handler?
Ejecutar tareas asíncronas fuera del hilo de interfaz de usuario y modificar la interfaz de usuario es un problema común en el desarrollo de Android, así que decidí tomar un tiempo, investigar y jugar con diferentes técnicas y encontrar lo que funciona mejor para mí.
Lo que consideré factores importantes:
- Android: varios intentservices o un intentservice con múltiples intenciones?
- Convertir flujo de entrada en mapa de bits
- ¿Cómo comprobar FileLock sin truncar el archivo?
- Solicitud de HttpClient simultánea utilizando varias AsyncTasks
- Android SDK AsyncTask doInBackground no está en ejecución (subclase)
- Debe trabajar confiablemente
- Legibilidad del código
-
Activity
oFragment
debe mantenerse limpio de la mayor cantidad de gestión de hilos como sea posible
Aquí está el resumen de mis impresiones (que pueden estar equivocadas y otras sólo son opiniones) sobre los diferentes métodos:
AsyncTask
Yo estaba usando AsyncTask
simple sin LoaderManager
cuando salté por primera vez en Android:
- Tenía problemas intermitentes, escribí mi propio
AsyncTaskManager
para gestionarlos con el ciclo de vida de la actividad. - Hay algunas limitaciones al número de tareas y se han reportado pérdidas de memoria antes.
- Mayor problema con estos fue que hicieron mi código muy complicado, y la simplificación del código derrotó el propósito de usarlos en primer lugar.
AsyncTaskLoader con LoaderManager
Esto parece ser la manera recomendada de hacer esto, así que investigado un poco:
- Después de leer acerca de estos un poco, parece que la razón principal de este método se recomienda es porque gestiona las tareas con el ciclo de vida
Fragment
, y de mi comprensión básicamente sólo reinicia las tareas si es necesario. Parece que no puede recibir los resultados de una tarea iniciada antes de reiniciar una actividad después de reiniciar la actividad. - Todos los parámetros de tarea parecen tener que ser
Parcelable
oSerialiazable
para entrar en un objetoBundle
.
Handler, Hilos, con mensajes
Este es el método en el que me establecí:
- Fácil de implementar, muy personalizable.
- Obtiene acceso al subproceso que ejecuta la tarea: establecer prioridad, establecer nombre de subproceso para depuración, configurar demonio y etc.
- Parece mucho más sensible que con el uso de AsyncTasks, basado en una prueba de ojo donde hago clic en un botón muchas veces y veo los resultados y los hilos flash;) podría comparar esto.
- Para manejar problemas de ciclo de vida, puede escribir una clase singleton que administre mensajes (persiste mientras el proceso está vivo). Los almacena cuando el controlador de una actividad dada no está configurado y, a continuación, los envía al controlador de actividad si solicita los mensajes perdidos. Lo que significa que una tarea no tiene que reiniciar con los mismos parámetros, que pueden ser críticos para las tareas que no son idempotentes.
Así que llegué a la conclusión de que el uso de Handler
, Threads
y Messages
es una solución mucho mejor, pero estoy convencido de que estoy perdiendo algo, porque casi en todas partes miraba la recomendación era utilizar el método AsyncTaskLoader
. ¿Qué me estoy perdiendo?
Gracias por el aporte.
- Android: Multithreading-Bluetooth SPP / RFCOMM-Cómo mantener activo mi BluetoothSocket y OutputStream al cambiar Actividades
- Servicio vs IntentService
- Android ejecutar hilo en el servicio cada X segundos
- Realizando operaciones de larga duración en onDestroy
- Comportamiento impredecible al acceder a Ver desde otro hilo
- Ejecutar tareas en backgound en NativeScript
- Detenga el subproceso Java que llama a la función JNI
- Programación con SurfaceView y estrategia de hilos para el desarrollo de juegos
Lo que te falta es que clases como AsyncTask
y LoaderManager
fueron escritas con Android en mente. Lo que significa, el sistema operativo está diseñado para aprovechar al máximo el hardware mínimo en comparación con una computadora de escritorio. AsyncTask
limita su grupo de subprocesos porque tiene limitaciones de hilo mucho más estrictas que en otros sistemas. Si intenta generar más de 100 hilos, se rechazarán nuevos hilos o se bloqueará el sistema. Sin duda, puede utilizar Thread
y Handler
, pero usted está en su propio en cuanto a su gestión.
Lo último que he oído, AsyncTask
soporta 10 subprocesos con una profundidad de cola de 10 tareas (puede haber aumentado en versiones posteriores). Si esto es restrictivo, siempre puede agarrar la fuente y escribir su propia. Lo he hecho antes. Lo importante que usted quiere considerar es, ¿puedo tener problemas en el camino con el desove de muchos hilos, y si es así, cómo voy a manejarlo.
Para responder a su pregunta de por qué se recomienda utilizar LoaderManager
y AsyncTaskLoader
, es sólo una conveniencia. Es una manera fácil de recargar datos y obtenerlo en las partes de su código que dependen de esos datos. No se justifica en cada situación.
Handler
, Threads
y Messages
son clases de bajo nivel. Esto le da flexibilidad – puede combinarlos como mejor le parezca para resolver su problema particular. Sin embargo, también es necesario ocuparse de muchas cosas de bajo nivel también: detener / iniciar subprocesos, enrutar al subproceso correcto, guardar / restaurar o volver a crear instancias cuando se recrean actividades, etc.
Los cargadores se encargan de la mayor parte de esto para usted y están diseñados para resolver un problema particular de carga de datos en una actividad. La mayor ventaja es que la Activity
(o FragmentActivity
) se encargará de administrar y reiniciar los cargadores cuando la actividad se vuelve a crear (lo cual es bastante difícil de hacer sin perder). También almacena en caché los datos para que no necesite hacerlo usted mismo. Dicho esto, si quieres hacer algo ligeramente diferente, el uso de Loaders puede resultar incómodo. Así que si necesita más flexibilidad, considere AsyncTask
. Si eso no encaja, vaya un nivel más bajo y use Threads
y Handler
.
- Android – instanciar un fragmento varias veces?
- Recursos $ NotFoundException en la presentación gráfica de ADT (pero la aplicación realmente funciona)