Diferencias entre SwingWorker de Java y Android AsyncTask
android-asynctask (1)
Estaba comparando las diferencias entre Swing''s SwingWorker y las clases AsyncTask de Android. Mientras que Android tiene un subproceso principal de subprocesos / UI y luego genera un subproceso en segundo plano (utilizando AsyncTask ), SwingWorker tiene tres hilos implicados:
- Hilo actual
- Hilo de trabajo
- Hilo de envío de evento.
Y luego también encontré la declaración (en documentos) -
A menudo, el hilo actual es el hilo de envío del evento.
¿Ahora, que significa esto?
¿Significa que Swing también tiene solo 1 hilo : el hilo principal e incluso los eventos se reciben en el mismo hilo O ¿es diferente para diferentes implementaciones de JVM?
Esto solo es válido para Swing, que comparte algunas similitudes con la programación de la interfaz de usuario de Android, pero de hecho no es lo mismo.
Un poco de contexto
El EDT (Event Dispatch Thread) es el hilo de Swing dedicado a manejar eventos de UI (entrada de mouse y teclado, eventos en controles, renderización de la UI, etc.). Este es un modelo de bucle de eventos, similar a lo que se hace en Android.
El hecho de que los detectores de eventos en Swing se ejecuten en el EDT es la causa raíz para congelar las UI en aplicaciones Swing: los desarrolladores que malinterpretan el modelo de subprocesos a menudo ponen código de larga ejecución en los oyentes, lo que bloquea el EDT y por lo tanto la GUI.
SwingWorker se introdujo para guiar mejor a los desarrolladores en la separación de las actualizaciones de UI del código de fondo de larga ejecución. Genera un hilo de fondo dedicado para el proceso de E / S (o tarea de larga ejecución) en doInBackground y ejecuta actualizaciones de UI en métodos de process y done . Si bien estos 3 métodos garantizan en qué hilo se ejecutarán, todos los demás métodos se ejecutan en el hilo actual.
¿Qué se entiende por la oración que citó
El motivo por el que SwingWorker existe es para iniciar correctamente un proceso de larga ejecución desde la GUI, sin bloquear la GUI.
A menudo, será en reacción a la entrada de un usuario (por ejemplo, haciendo clic en un botón). Dado que las reacciones a la entrada del usuario (implementadas como Oyentes) siempre se ejecutan en el EDT mediante el marco Swing, a menos que execute u get de otro hilo explícitamente, se ejecutará en el EDT.
Por cierto, execute es "disparar y olvidar" y es el típico caso de uso (llámalo de un oyente). get los bloques de la otra mano, y no es adecuado para ser llamado por un oyente (¡eso vencería el propósito de SwingWorker, llámalo por tus propios hilos si es necesario)!