Flex Modules – Optimiser vos modules avec load-externs
La taille des modules varie selon les composants et les classes utilisées par le module. Par défaut, un module inclus tout le code des classes du framework Flex utilisées, ce qui peut rendre le module bien plus lourd.
Pour réduire la taille des modules, vous pouvez ordonner au module d'externaliser les classes qui sont inclues dans l'application. Cela inclut les classes personnalisées et les classes du framework. Le module va donc seulement inclure les classes dont il a besoin, alors que le code du framework et les autres dépendances seront inclues dans l'application.
Pour externaliser les classes du framework, on va générer un rapport de liaison (linker report) depuis l'application qui va gérer les modules. Vous pourrez ensuite utiliser ce "linker report" comme paramètre pour l'option "-load-externs" du compilateur.
Créer et utiliser un linker report en ligne de commande (mxmlc)
- Générer le linker report (fichier XML) et le compiler dans l'application:
mxmlc -link-report=report.xml MyApplication.mxml
Le répertoire par défaut du rapport XML est le même répertoire que celui du compilateur (dans ce cas, dans le répertoire "bin"
- Compilez ensuite le module en passant le linker report dans l'option load-externs:
mxmlc -load-externs=report.xml MyModule.mxml
Si vous utilisez Flex Builder pour compiler des modules, vous pouvez utiliser cette technique si vous avec un projet séparé pour chaque module. Dans ce cas, pour l'application principale, vous pouvez ajouter l'option link-report au champ "Additional Compiler Arguments" dans les propriétés de votre projet Flex. Vous pouvez ensuite utiliser l'option load-externs dans le même champ pour chaque projet contenant un module.
Créer et utiliser un linker report dans Flex Builder
- Sélectionnez le projet principal dans la vue Flex Navigator
- Click droit > Properties > Flex Compiler
- Dans le champ "Additional Compiler Arguments", indiquez le répertoire de sortie de votre linker report comme ceci:
-locale en_US -link-report=c:/temp/externs/report.xml
Le répertoire par défaut du link-report est le répertoire principal de Flex Builder lui même. Sous Windows, c'est par exemple: c:\Program Files\Adobe\Flex Builder 3. Si vous faites uniquement "-link-report=report.xml", le fichier report.xml sera donc crée dans le répertoire de FB.
- Cliquez sur OK pour sauver vos changements
- Sélectionnez le projet du module dans le Flex Navigator. Si vous utilisez plusieurs projets pour vos modules, répétez ces étapes pour chaque projet.
- Click droit > Properties > Flex Compiler
- Dans le champ "Additional Compiler Arguments", indiquez le répertoire de sortie dans lequel se trouve le linker report comme ceci:
- Cliquez sur OK pour sauver vos changements
- Assurez-vous que le projet de l'application principale apparait bien en premier dans l'ordre de build. Cela vous assure que le linker report est généré par l'application principale avant qu'il soit consommé par les modules.
Re-compilation de modules
Si vous modifiez un module, vous n'avez pas à recompiler l'application qui utilise le module. L'application charge le module à l'exécution, il n'y a donc pas de vérification à la compilation. De même, si vous ne changer pas votre application, vous n'avez pas à recompiler les modules.
Cependant, si vous faîtes des modifications qui pourraient affecter le "linker report" ou du code commun, vous devriez compiler à la fois l'application et les modules.
Articles similaires
- Flex Modules – Compilation de modules (Flex Builder et mxmlc)
- Flex Modules – Créer une application Flex modulaire
- Flex Modules – Communication entre Module et Application
- Flex Modules – Décharger (Unload) correctement ses modules
- Flex Modules – TypeError: Error #1034: Echec de la contrainte de type : conversion de mx.managers::PopUpManagerImpl@18658d01 en mx.managers.IPopUpManager impossible [Résolu]
Aucun trackbacks pour l'instant






12 février 2010
Salut,
Concernant cette histoire de -link-report il me semble qu'il ne vaut mieux pas utiliser cela lorsque l'on travaille dans Flex Builder mais plutôt lors d'une compilation/packaging/release etc avec Ant ou Maven, et encore, logiquement ce n'est même pas utile. Je m'explique :
Si tu as des bouts de code communs entre un module et une application, ce code devrait être dans une nouvelle bibliothèque (typiquement : les interfaces de communication avec le module). Ainsi, lorsque tu compiles un module, celui-ci utilise des libs qui sont communes (en particulier celles du framework et les interfaces) et des libs spécifiques. A partir de là :
– Dans le module : les libs spécifiques sont "merged", les autres sont "external".
– Dans l'application : touts les lib sont "merged" (ou RSL) et les spécifiques au module sont évidemment absentes.
Avec cette méthode, la compilation des modules et des applications est indépendante (seule la modification des libs communes entraine une recompilation des deux) et logiquement c'est déjà optimisé.
La question que je me pose c'est est-ce que le résultat, en terme d'optimisation, est-il vraiment similaire ? A priori oui mais c'est à vérifier
A+
12 février 2010
Salut Yannick,
Effectivement, je me pose exactement la même question car j'ai besoin d'utiliser les mêmes modules pour deux applications qui sont quasiment identiques (baties sur la même base) et le partage de module n'est pour l'instant pas possible car les plugins (modules) sont compilés uniquement otpimisés sur la première application. Mais je vais essayer d'utiliser simplement les interface de mes libs de base, voir si je peux réutiliser mes modules sur plusieurs applications.
Si tu as eu le temps de tester, tu peux me donner tes résultats (bon ou moins bons)? Je t'ai invité sur GTalk
merci,
Fabien
12 février 2010
Oui je comptai tester, et il me semble qu'il y a d'autres paramètres de compilation pour optimiser les modules. Je posterai les résultats d'ici 2 à 3 semaines.
Ce que je peux déjà affirmer, c'est que s'il y a une différence de taille, celle-ci est minime (mes modules sont de l'ordre de 200ko en comptant bien 150ko à cause des images).
15 février 2010
Juste une remarque : la taille des modules peut bien évidemment beaucoup varier, 400k sans asset (fonts, images, etc) me parait encore raisonnable mais aussi un maximum à ne pas dépasser. Un module de cette taille signifie bien souvent un problème au niveau du linkage des bibliothèques.