Pour comprendre comment améliorer les performances d’une application, il est essentiel de comprendre comment le moteur d’exécution de la plate-forme Flash exécute le code. Le moteur d’exécution fonctionne en boucle, certaines actions se produisant sur chaque « image ». On entend ici par image un simple bloc de temps déterminé par la cadence définie pour l’application. Le temps alloué à chaque image correspond directement à la cadence. Si vous spécifiez une cadence de 30 images par seconde, par exemple, le moteur d’exécution s’efforce de faire durer chaque image un trentième de seconde.
Vous définissez la cadence initiale de l’application au moment où vous créez celle-ci. Pour ce faire, vous pouvez utiliser les paramètres correspondants d’Adobe® Flash® Builder™ ou Flash Professional. Libre à vous également de définir la cadence initiale dans le code. Pour définir la cadence d’une application basée uniquement sur ActionScript, appliquez la balise de métadonnées
[SWF(frameRate="24")]
à la classe du document racine. En MXML, définissez l’attribut
frameRate
dans la balise Application ou WindowedApplication.
Chaque boucle d’image comprend deux phases, divisées en trois parties : les événements, l’événement
enterFrame
et le rendu.
La première phase comporte deux parties (les événements et l’événement
enterFrame
), qui entraînent potentiellement toutes deux l’appel de votre code. Dans la première partie de la première phase, des événements du moteur d’exécution arrivent et sont distribués. Ces événements peuvent représenter la fin ou la progression d’opérations asynchrones telles qu’une réponse à un chargement de données sur un réseau. Ils peuvent également être la conséquence d’une entrée de l’utilisateur. Au fur et à mesure de la distribution des événements, le moteur d’exécution exécute le code dans des écouteurs que vous avez enregistrés. En l’absence d’événements, le moteur d’exécution attend, sans agir, la fin de cette phase d’exécution. Il n’accélère jamais la cadence par manque d’activité. Si des événements se produisent dans d’autres parties du cycle d’exécution, le moteur d’exécution les place en file d’attente et les distribue sur l’image suivante.
La deuxième partie de la première phase correspond à l’événement
enterFrame
. Cet événement se distingue des autres en ce qu’il est toujours distribué une fois par image.
Une fois tous les événements distribués, la phase de rendu de la boucle d’image commence. A ce stade, le moteur d’exécution calcule l’état de tous les éléments visibles à l’écran et les dessine. Le processus peut alors recommencer, à l’instar d’un coureur qui fait des circuits dans un stade.
Remarque :
dans le cas des événements comprenant la propriété
updateAfterEvent
, il est possible d’imposer un rendu immédiat plutôt que d’attendre la phase de rendu. Evitez toutefois d’utiliser
updateAfterEvent
si elle entraîne fréquemment des problèmes de performances.
Il est plus facile d’imaginer que la durée des deux phases de la boucle d’image est identique. Dans ce cas, une moitié de chaque boucle est dévolue à l’exécution des gestionnaires d’événements et du code d’application, tandis que la seconde moitié est consacrée au rendu. La réalité est néanmoins souvent toute autre. Il arrive que le code d’application utilise plus de la moitié du temps disponible dans l’image, étirant ainsi le créneau qui lui est alloué et réduisant celui du rendu. Dans d’autres cas, notamment lorsque le contenu visuel est complexe (filtres et modes de fondu, par exemple), c’est le rendu qui exige plus de la moitié du temps. La durée des phases étant variable, on dit souvent de la boucle d’image qu’elle est « élastique ».
Si les opérations combinées de la boucle d’image (exécution du code et rendu) durent trop longtemps, le moteur d’exécution ne peut pas assurer une cadence uniforme. L’image s’étend au-delà du temps qui lui est alloué, retardant ainsi le déclenchement de l’image suivante. Si, par exemple, une boucle d’image dépasse un trentième de seconde, le moteur d’exécution ne peut pas mettre l’écran à jour à 30 images par seconde. Le ralentissement de la cadence se traduit par une détérioration de l’expérience de l’utilisateur. Au mieux, l’animation est saccadée ; au pire, l’application se bloque et la fenêtre est vide.
Pour plus de détails sur l’exécution du code par le moteur d’exécution de la plate-forme Flash et le modèle de rendu, voir les ressources suivantes :
