Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

package remoting;
public class EchoService
{
    public String echo(String text) {
        return "Server says: I received '" + text + "' from you";
    }
}

<destination id="echoServiceDestination" channels="my-amf">
    <properties>
        <source>remoting.EchoService</source>
    </properties>
</destination>

Flex Modules – Décharger (Unload) correctement ses modules

Le principal intérêt des modules Flex est de découper votre application en plusieurs SWF pouvant être chargés et déchargés à la volée. Le fait de décharger (unload) permet de libérer la mémoire prise par le module une fois qu'il n'est plus utilisé. Cependant, même en faisant un unload() du module, il ne sera pas forcement libéré de la mémoire par le Garbage Collector. En effet, si des références vers ce module existent toujours, le module ne sera pas libéré. Parfois ces références sont évidentes mais parfois elles sont plus difficiles à trouver, surtout quand elles se trouvent au fin fond du framework Flex.

La Flex Team a publié un article pour récapituler les principales cause connues qui font qu'un module n'est pas libéré de la mémoire. Voici le détail.

Chargement de modules dans différents "applicationDomain"

Le fait de charger des modules depuis différents "applicationDomain" peut obliger Flex à référencer des classes dans ses Managers. Ces références peuvent causer la persistence du module en mémoire. Essayez de charger les modules avec l'applicationDomain par défaut (en utilisant les paramètres par défaut de la méthode load().

Fuites mémoire

Les "Memory leaks" peuvent créer des références vers votre module qui vont empêcher le Garbage Collector de libérer le Module Flex de la mémoire. Voici les causes principales:

Styles

Cela se produit même sans tag mx:Style dans votre MXML. Si votre module utilise un composant qui n'est pas utilisé par l'application principale, le module va enregistrer le style par défaut pour ce composant dans le StyleManager et coincer la première instance de votre module. Vous pouvez utiliser l'option du compilateur -compiler.keep-generated-actionscript pour voir quels styles le module et l'application principale utilisent. Vous pouvez aussi utiliser l'option -compiler.keep-all-type-selectors dans l'application principale pour forcer l'application principale à enregistrer les styles par défaut de chaque composant dans le fichier defaults.css. Les CSS chargés à l'exécution (StyleManager.loadStyleDeclarations) ne sont pas concernés par ce problème car ils sont chargés de manière différente.

Resources

Si votre module utilise des composants qui utilisent de ResourceBundles non-utilisés par l'application principale, ces Resource Bundles vont être enregistrés dans le ResourceManager et coincer la première instance du module. Vous pouvez utiliser l'option du compilateur -compiler.keep-generated-actionscript pour voir quels Resource Bundles le module et l'application mère utilisent. Vous pouvez forcer l'application principale à avoir ces Resource Bundles additionnels en ajoutant les metadata du Resource Bundle dans l'application principale.

Par exemple, vous ajouter le Resource Bundle "controls", vous devez ajouter à votre application:[ResourceBundle("controls")]. Si vous chargez vos Resource Bundles comme des modules, assurez-vous que les Resource Module ont bien fini leur chargement avant de charger le module Flex qui utilise le Resource Bundle.

ExternalInterface.addCallback

Les modules ne devraient pas utilier la méthode ExternalInterface.addCallback(). Cela enregistre la méthode dans le navigateur et il n'y a, à ce jour, aucun moyen de la supprimer. Il est recommandé de laisser l'application principale enregistrer une méthode qui va appeler une référence de fonction. Il suffit ensuite de remplacer cette référence par la méthode du module. Quand le module est déchargé, il suffit de mettre cette référence à null.

Timers et autres mécanismes de Timing

L'utilisation de Timer, setTimeout() et setInterval() peuvent causer des fuites mémoire. Les Timer doivent être arrêtés et avoir leurs listeners supprimés. setTimeout et setInterval doivent faire quant à elles appel à clearTimeout() et clearInterval() pour pouvoir être GCed correctement.

Listeners sur évènements depuis des objets à l'extérieur du module

Utilisez des références faibles (weak references) ou assurez vous d'avoir bien supprimé les event listener. Rappelez-vous que lorsque vous appelez A.addEventListener("foo", B.someMethod), "A" a une référence vers B, et pas l'inverse.

Focus

Si un des objets du module a le focus, le FocusManager aura toujours une référence vers le module. Il est conseillé de bouger le focus vers un autre objet à l'extérieur du module avant de le décharger.

RemoteObject

Si un module amène une nouvelle classe qui va faire partie d'une requête serveur, cette classe va être enregistrée par Flash Player et amener une référence vers le module. Liez les Data Classes à l'application principale lorsque c'est possible.

Images chargées

Si un module charge une image, cette image doit être déchargée sinon Flash Player va garder des buffers autour de cette image.

Autres éléments à connaitre

Une fois qu'ils n'y a plus de référence vers les objets d'un module, Flash Player peut encore garder un module en mémoire pendant un moment si certains des objets d'un module on eu le focus. Essayez de taper du texte ou de cliquez dans l'application pour éventuellement libérer des références vers le module.

Les versions Debug d'un module peuvent empêcher le module d'être libéré de la mémoire. Les version de debug contiennent des informations de debug qui peuvent être enregistrées par le debugger. Assurez-vous de tester avec des versions realease des modules et une application lue par un Flash Player classique.