Lorsqu’une application n’utilise pas des programmes de travail, son code s’exécute dans un bloc d’exécution linéaire unique appelé
thread
d’exécution. Ce thread exécute le code écrit par un développeur. Il exécute également une grande partie du code appartenant au moteur d’exécution, plus particulièrement le code qui met à jour l’écran lorsque les propriétés des objets d’affichage changent. Bien que le code soit écrit par blocs en tant que méthodes et classes, il s’exécute ligne par ligne au moment de l’exécution même s’il a été écrit dans une longue série d’étapes. Supposons qu’une application exécute les étapes suivantes :
-
Image d’entrée : le moteur d’exécution appelle des gestionnaires d’événement
enterFrame
et exécute tour à tour leur code.
-
Evénement de souris : l’utilisateur déplace la souris, et le moteur d’exécution appelle les gestionnaires d’événements de souris à mesure que se produisent les événements de survol et de déroulement.
-
Evénement de fin de chargement : une demande de chargement d’un fichier xml provenant d’une URL est renvoyée avec les données du fichier chargé. Le gestionnaire d’événement est appelé et exécute ses étapes en lisant le contenu xml et en créant un ensemble d’objets à partir des données xml.
-
Evénement de souris : la souris s’est à nouveau déplacée ; le moteur d’exécution appelle donc les gestionnaires d’événements de souris pertinents.
-
Rendu : plus aucun événement n’est en attente ; le moteur d’exécution met donc à jour l’écran en fonction des modifications qu’ont subi les objets d’affichage.
-
Image d’entrée : le cycle recommence.
Comme le montre cet exemple, les étapes 1 à 5 s’exécutent en séquence au sein d’un bloc temporel unique appelé image. Etant donné qu’elles s’exécutent en séquence dans un thread unique, le moteur d’exécution ne peut pas interrompre une étape du processus pour en exécuter une autre. A une cadence de 30 images par seconde, le moteur d’exécution dispose de moins d’un trentième de seconde pour exécuter l’ensemble de ces opérations. En règle générale, ce délai est suffisant pour exécuter le code et le moteur d’exécution n’a plus qu’à attendre pendant le temps restant. Supposez néanmoins que les données xml qui se chargent à l’étape 3 représentent une très grande structure xml profondément imbriquée. Etant donné que le code s’exécute en boucle sur les données xml et crée des objets, il est tout à fait possible que cette opération prenne plus d’un trentième de seconde. Dans ce cas, les dernières étapes (répondre à la souris et actualiser l’écran) ne sont pas exécutées au moment où elles le devraient. Résultat : l’écran se bloque, car il n’est pas actualisé assez vite en réponse à l’utilisateur qui déplace la souris.
Si l’ensemble du code s’exécute dans le même thread, il n’existe qu’un seul moyen d’éviter les blocages occasionnels : éviter les opérations longues telles que l’exécution en boucle sur un jeu de données volumineux. Les programmes de travail d’ActionScript proposent une solution alternative. Un programme de travail peut vous permettre d’exécuter du code à exécution longue dans un programme de travail indépendant. Comme chaque programme de travail est exécuté dans un thread différent, le programme de travail en arrière-plan lance l’opération longue dans son propre thread. Cela évite ainsi au thread d’exécution du programme de travail principal d’actualiser l’écran à chaque image et d’être bloqué par un autre processus.
La possibilité d’exécuter plusieurs opérations de code en même temps de cette manière est appelée
simultanéité
. Lorsque le programme de travail en arrière-plan finit son travail, ou à certaines étapes-clés du processus, vous pouvez envoyer au programme de travail principal des notifications et des données. De cette manière, vous pouvez écrire du code qui exécute des opérations longues ou complexes tout en évitant le blocage de l’écran.
Les programmes de travail sont utiles, car ils diminuent le risque d’une baisse de la cadence, qui peut se produire si le thread de rendu principal est bloqué par l’exécution d’un autre code. Les programmes de travail augmentent toutefois l’utilisation de la mémoire système et du processeur, ce qui peut avoir une incidence considérable sur les performances globales de l’application. Etant donné que chaque programme de travail utilise sa propre occurrence de la machine virtuelle du moteur d’exécution, le traitement d’un programme de travail, aussi simple soit-il, peut consommer de nombreuses ressources. Lorsque vous utilisez des programmes de travail, testez votre code sur toutes vos plates-formes cibles afin de vous assurer que les ressources requises ne sont pas trop importantes. Adobe vous recommande de ne pas utiliser plus de deux programmes de travail dans un scénario type.
