Si vous avez besoin d'éléments Flash distincts sur une page pour communiquer les uns avec les autres, vous finirez probablement par utiliser LocalConnection. Cela étant dit, vous devrez vous pencher sur l'utilisation de bibliothèques RSL (Runtime Shared Libraries) pour le framework Flex, sinon chacun de vos fichiers SWF devra contenir sa propre copie de la structure Flex.
Maintenant, cela étant dit, les problèmes liés à la mémoire ne découlent pas vraiment du cadre, au lieu qu'ils viennent de problèmes liés à des références d'objets et peut-être monopolisant CPU.
garbage collector de flash ne fonctionne que quand il a le temps de le faire, donc si votre application est Smasher la CPU assez constante, le GC ne peut jamais fonctionner. Si vous exécutez votre application en mode débogage avec Flex, vous pouvez forcer l'exécution du GC pour voir si c'est le cas.
GC de Flash est basé sur un concept de marquage et de balayage. Les objets qui existent mais qui n'ont pas de références sont d'abord marqués, et ensuite balayés bug le GC. Cela signifie que si vous laissez des références à des objets "morts", ils ne seront jamais libérés. Un coupable commun dans ce sont les événements et les auditeurs d'événements. Il est généralement recommandé d'utiliser toujours des clés faibles (évite de faire une référence comptabilisée par le GC) avec addEventListener.
// don't do this
foo.addEventListener(Event.CHANGE, onChange);
// do this
foo.addEventListener(Event.CHANGE, onChange, false, 0, true);
Grant Skinner a un excellent series on resource management in AS3 vous devriez vérifier aussi bien.