Préférez les versions asynchrones aux versions synchrones des opérations, si possible.
Les opérations synchrones s’exécutent immédiatement et le code attend la fin de leur exécution avant de continuer. Elles s’exécutent donc dans la phase code d’application de la boucle d’image. Si une opération synchrone est longue, elle étire la taille de la boucle d’image et l’affichage risque de se bloquer ou d’être saccadé.
Une opération asynchrone, en revanche, ne s’exécute pas nécessairement immédiatement. Votre code et d’autres lignes de code d’application du thread d’exécution actif continuent de s’exécuter. Le moteur d’exécution exécute l’opération dès que possible tout en essayant de parer aux problèmes de rendu. Dans certains cas, l’exécution se déroule en arrière-plan et ne fait pas partie de la boucle d’image. Au terme de l’opération, le moteur d’exécution distribue un événement que le code peut écouter en vue d’exécuter d’autres tâches.
Les opérations asynchrones sont planifiées et divisées pour parer aux problèmes de rendu. Elles permettent donc d’accroître la réactivité de l’application (voir
Perception et réalité en matière de performances
pour plus d’informations).
Les opérations asynchrones nécessitent néanmoins plus de temps système. Dans la pratique, leur exécution peut donc durer plus longtemps, surtout lorsqu’elles sont très courtes.
Dans le moteur d’exécution, de nombreuses opérations sont synchrones ou asynchrones de par leur nature, et il est impossible de choisir leur mode d’exécution. Adobe Air, en revanche, propose trois types d’opérations que vous pouvez exécuter de manière synchrone ou asynchrone, au choix :
-
Opérations des classes File et FileStream
Il est possible d’exécuter un grand nombre des opérations de la classe File de manière synchrone ou asynchrone. Ainsi, il existe une version asynchrone des méthodes de copie ou de suppression de fichier ou de répertoire et d’affichage du contenu d’un répertoire. Le nom de la version asynchrone est identifié par le suffixe « Async ». Pour supprimer un fichier de manière asynchrone, par exemple, appelez la méthode
File.deleteFileAsync()
et non la méthode
File.deleteFile()
.
Lorsque vous accédez à un fichier en lecture ou en écriture à l’aide d’un objet FileStream, c’est la façon dont vous ouvrez celui-ci qui détermine si les opérations de lecture ou d’écriture sont synchrones ou asynchrones. Utilisez la méthode
FileStream.openAsync()
pour les opérations asynchrones. L’écriture des données est exécutée en mode asynchrone. La lecture des données est effectuée par blocs, elles sont donc disponibles progressivement. En revanche, le mode synchrone de l’objet FileStream lit intégralement le fichier avant de poursuivre l’exécution du code.
-
Opérations de base de données SQL locale
Lorsque vous utilisez une base de données SQL locale, toutes les opérations exécutées via un objet SQLConnection sont en mode synchrone ou asynchrone. Pour spécifier leur exécution en mode asynchrone, ouvrez la connexion à la base de données à l’aide de la méthode
SQLConnection.openAsync()
plutôt que de la méthode
SQLConnection.open()
. Les opérations de base de données asynchrones s’exécutent en arrière-plan. Le moteur de base de données ne s’exécute pas dans la boucle d’image du moteur d’exécution, si bien que les opérations de base de données sont peu susceptibles de donner lieu à des problèmes de rendu.
Vous trouverez d’autres stratégies d’amélioration des performances avec la base de données SQL locale à la section
Performances de la base de données SQL
.
-
Shaders autonomes de Pixel Bender
La classe ShaderJob permet d’exécuter une image ou un ensemble de données via un shader de Pixel Bender et d’accéder aux données résultantes brutes. Lorsque vous appelez la méthode
ShaderJob.start()
, le shader s’exécute de manière asynchrone par défaut. L’exécution a lieu en arrière-plan, pas dans la boucle d’image du moteur d’exécution. Pour imposer l’exécution en mode synchrone de l’objet ShaderJob (ce qui n’est pas recommandé), transmettez la valeur
true
au premier paramètre de la méthode
start()
.
Outre ces mécanismes intégrés permettant d’utiliser le mode asynchrone, vous pouvez aussi structurer votre code de sorte à l’exécuter en mode asynchrone et non synchrone. Si vous programmez une tâche qui risque d’être longue, vous pouvez structurer le code de sorte à exécuter la tâche par blocs. Cette division permet au moteur d’exécution d’effectuer ses opérations de rendu entre les blocs d’exécution du code, réduisant ainsi l’éventualité de problèmes de rendu.
Diverses techniques de division du code sont recensées ci-après. Elles ont pour but principal de vous permettre de programmer du code n’exécutant pas toutes les tâches en une seule fois. Vous assurez le suivi du code et de ses arrêts. Grâce à un mécanisme tel qu’un objet Timer, vous vérifiez à plusieurs reprises s’il reste des tâches et vous les exécutez par blocs jusqu’à ce qu’elles soient toutes terminées.
Pour structurer du code afin qu’il divise les tâches, il est nécessaire de respecter certains modèles établis. Les articles et bibliothèques de code ci-dessous décrivent ces modèles et contiennent du code qui vous permettra de les implémenter dans vos applications :
-
Asynchronous ActionScript Execution
(Article détaillé de Trevor McCauley, s’accompagnant d’exemples d’implémentation. Disponible en anglais uniquement.)
-
Parsing & Rendering Lots of Data in Flash Player
(Article détaillé de Jesse Warden, s’accompagnant d’exemples d’implémentation de deux techniques, « patron de conception Builder » et « threads verts ». Disponible en anglais uniquement.)
-
Green Threads
(Article de Drew Cummins décrivant la technique « threads verts » et s’accompagnant d’un exemple de code source. Disponible en anglais uniquement)
-
greenthreads
(Bibliothèque de code de type open source créée par Charlie Hubbard pour l’implémentation des « threads verts » dans ActionScript. Disponible en anglais uniquement. Voir
greenthreads Quick Start
pour plus d’informations. Disponible en anglais uniquement.)
-
Threads dans ActionScript 3, à l’adresse
http://www.adobe.com/go/learn_fp_as3_threads_fr
(Article d’Alex Harui, comprenant un exemple d’implémentation de la technique de « pseudo threading ». Disponible en anglais uniquement.)