Cuando una aplicación no utiliza programas de trabajo, el código de la aplicación se ejecuta en único bloque lineal de pasos de ejecución denominado
subproceso
de ejecución. El subproceso ejecuta el código escrito por un desarrollador. También ejecuta gran parte del código que forma parte del motor de ejecución, sobre todo el código que actualiza la pantalla cuando cambian las propiedades de los objetos de visualización. Aunque el código se escribe en fragmentos como métodos y clases, en tiempo de ejecución el código ejecuta una línea cada vez, como si estuviese escrito en una única extensa serie de pasos. Considere este ejemplo hipotético de los pasos ejecutados por una aplicación:
-
Fotograma de entrada: el motor de ejecución llama a cualquier controlador de eventos
enterFrame
y ejecuta su código de uno en uno
-
Evento de ratón: el usuario mueve el ratón y el motor de ejecución llama a cualquier controlador de eventos mouse a medida que se suceden los distintos eventos rollover y rollout
-
Evento de carga finalizada: una solicitud de carga de un archivo xml desde una URL devuelve los datos del archivo cargado. Se llama al controlador de eventos y se ejecutan sus pasos, leyendo primero el contenido xml y creando después un conjunto de objetos a partir de los datos xml.
-
Evento de ratón: el ratón se vuelve a desplazar, por lo que el motor de ejecución llama a los controladores de eventos mouse correspondientes
-
Procesamiento: no se esperan más eventos, por lo que el motor de ejecución actualiza la pantalla en función de los cambios realizados en los objetos de visualización
-
Fotograma de entrada: el ciclo vuelve a comenzar
Tal y como se describe en el ejemplo, los pasos hipotéticos 1-5 se ejecutan secuencialmente dentro de un único bloque de tiempo denominado fotograma. Dado que se ejecutan uno después del otro en un único subproceso, el motor de ejecución no puede detener un paso del proceso para ejecutar otro. A una velocidad de 30 fotogramas por segundo, el motor de ejecución dispone de menos de 1/30 de segundo para ejecutar todas las operaciones. En muchos casos, este tiempo basta para ejecutar el código y el motor de ejecución simplemente espera durante el tiempo restante. No obstante, supongamos que los datos xml cargados en el paso 3 son muy grandes y están muy anidados en la estructura xml. A medida que el código recorre una y otra vez el xml y crea objetos, puede tardar más de 1/30 de segundo en completar la operación. En este caso, los últimos pasos (respuesta del ratón y rediseño de la pantalla) no logran realizarse en el momento necesario. Esto hace que la pantalla se bloquee o que se produzcan fallos de visualización, ya que la pantalla no se rediseña lo suficientemente rápido como respuesta al desplazamiento del ratón del usuario.
Si todo el código se ejecuta en el mismo subproceso, solo hay una forma de evitar posibles retrasos y bloqueos de visualización: evitar operaciones de ejecución larga, como recorrer indefinidamente un conjunto extenso de datos. Los programas de trabajo de ActionScript ofrecen otra solución. Con un programa de trabajo, es posible ejecutar código de ejecución larga en un programa de trabajo independiente. Cada programa de trabajo se ejecuta en un subproceso distinto, con lo que el programa de trabajo en segundo plano es quien realiza la operación de ejecución larga en su propio subproceso. Esto libera el subproceso de ejecución del programa de trabajo principal y permite que redibuje la pantalla en cada fotograma sin interferir ni bloquear el resto del trabajo.
La capacidad de ejecutar múltiples operaciones de código al mismo tiempo de este modo se denomina
simultaneidad
. Cuando el programa de trabajo en segundo plano finaliza su trabajo, o en puntos de “progreso” durante el proceso, puede enviar notificaciones y datos al programa de trabajo principal. De este modo, se puede escribir código complejo o que consuma mucho tiempo, pero evitar la mala experiencia de usuario de ver cómo se bloquea la pantalla.
Los programas de trabajo son útiles porque reducen la posibilidad de pérdida de velocidad de datos debido a que otro código esté bloqueando el subproceso de procesamiento principal. No obstante, los programas de trabajo requieren memoria adicional del sistema y mayor uso de CPU, y esto puede afectar significativamente al rendimiento general de la aplicación. Dado que cada programa de trabajo utiliza su propia instancia de la máquina virtual del motor de ejecución, incluso la sobrecarga de un programa de trabajo trivial puede ser muy grande. Cuando utilice programas de trabajo, pruebe el código en todas las plataformas de destino para garantizar que no exigen demasiados recursos de uso del sistema. Adobe recomienda no utilizar más de uno o dos programas de trabajo en segundo plano en un escenario típico.
