Consommation mémoire des applications flex imbriquées avec RSL à l'aide de SWFLoader?

Question

ces jours je lis beaucoup en ce qui concerne RSLs. Un inconvénient est que les RSL doivent être chargées en mémoire mais peuvent économiser un temps de chargement important.

Maintenant, ce qui se passe dans le scénario suivant:

J'ai un superFramework.swf et un subapp.swf. subapp.swf est affiché et chargé à la demande dans superframework.swf en utilisant le SWFLoader. Cependant, les deux fichiers SWF ont des dépendances avec common.swc, qui sera compilé en tant que RSL.

Ainsi, les dependcies ressemblent à ceci:

superframework.swf   ---RSL---> common.swc 
    ---SWFLoader-->subapp.swf ---RSL---> common.swc 

Maintenant, mes questions:

• Est-ce le subapp.swf chargé dans un espace mémoire séparé?
• Si oui: Cela signifie-t-il que le fichier RSL common.swc est chargé deux fois en mémoire?
• Si non: Qu'en est-il des singletons comme un ModelLocator dans common.swc. La même instance est-elle disponible pour subapp.swf et superframework.swf en même temps?

Answer 1

Les RSL ne sont pas de véritables bibliothèques dynamiques. Ils sont plus comme statique reliant la bibliothèque entière à l'exécution.

• Est-ce le subapp.swf chargé dans un espace mémoire séparé?

Oui, en quelque sorte. Tous les fichiers SWF s'exécutent dans Flash Player. Ils ont leurs propres petits bacs à sable pour des raisons de sécurité.

• Si oui: Est-ce que cela signifie que le RSL common.swc est chargé en mémoire deux fois?

Oui, chaque application se charge d'appeler une copie d'un RSL donné.

• Si non: Qu'en est-singletons comme un ModelLocator dans le common.swc. La même instance est-elle disponible pour subapp.swf et superframework.swf en même temps?

Non, ils auront des instances différentes.

Les RSL aident à réduire la taille des distribuables. Mais ce n'est pas nécessairement un avantage toujours. Je vous suggère de passer par la page this avant de faire un saut.