Módulos e gerenciamento de memória

O problema dos módulos sempre foi e ainda é o gerenciamento de memória, mesmo agora na versão 4, fiz um teste com a versão 4.5.1, mesmo depois de descarregar o módulo usando loader.url = null e loader.unloadModule o módulo ainda continua ativo consumindo memória juntamente com os recursos que este carregou.

Um exemplo, se criar um módulo que tem um timer que de tantos em tantos segundo faz uma requisição http ou com um música tocando, depois que você o descarregar você verá que as requisições http ainda continuam ocorrendo e que a música ainda está tocando.

Nesse caso, além de "descarregar" o módulo é necessário desativar os recursos, mas mesmo assim a memória ainda estará sendo usada.

Não vejo a necessidade de usar módulos para conter somente uma tela, são realmente úteis com projetos muito grandes e mesmo assim tem que ser bem avaliado, porque ao gerar o swf da aplicação e colocar no servidor o client / browser irá identificar o novo swf e irá utilizá-lo.

E mesmo numa aplicação grande que terá benefícios reais modularizar o projeto acredito que usar sub-apps é mais recomendável, isto é, em vez de usar módulos criar sub-projetos cada um tendo o seu swf podendo ser independentes o que não acontece com os módulos que dependendem da aplicação principal.

Mais sobre sub-apps veja aqui.

Loading Applications - About security domains

About security domains

Security domains define the level of trust between applications. In general, if a sub-application is loaded into the same security domain as the main application, then the applications have the highest level of interoperability.

You determine whether a sub-application is loaded into the same security domain as the main application when you load it. You can set the value of the trustContent (false=default) property to true to load a remote sub-application into the same security domain as the main application. To do this, though, the sub-application’s server must have a policy file (crossdomain.xml) that allows you to load it. The result is that the SWF file becomes trusted, and acts as if it was loaded locally.

Note: This behavior only applies if that application is loaded from a different web domain or subdomain than the main application. If the sub-application is loaded from the same web domain as the main application, then it is by default loaded into the same security domain.

Note: Setting the value of the loadForCompatibility property does not affect the trustContent property.

Note: When using AIR, you cannot set the value of the trustContent property to true.

Loading Applications - About application domains

About application domains

An application domain is a container for class definitions. Applications have a single, top-level application domain called the system domain. When you load a sub-application into another, main application, you can load it into one of three application domains: sibling, child, and current. Each of these locations defines where the sub-application can get its class definitions from.

The System domain

Classes defined by Flash Player are in the system domain. The system domain parents all other application domains. The main application’s application domain is a child of the system domain. Classes defined in the system domain are never redefined in sub-applications or main applications. Those applications all share the common definitions of Flash Player. These definitions include classes such as DisplayObject, Event, and Sprite. The definitions of these shared classes are contained in the playerglobal.swc file.

Sibling applicaton domains

The application domain that a sub-application is in determines where the sub-application gets its class definitions from. If the main application loads a sub-application into a sibling application domain, the sub-application defines its own non-player class definitions. This is the configuration for multi-versioned applications.

Child application domains

If a main application loads a sub-application into a child application domain of its application domain, the subapplication gets its class definitions from the main application. This behavior is the default for application loading. It can result in runtime errors if the applications are compiled with different versions of the Flex framework. These errors occur because the applications are sometimes compiled against different definitions of the same classes.

If a sub-application defines one of the classes that is already defined in the main application, the child’s definition is ignored. If multiple sub-applications define the same class that isn’t defined in the main application, each sub-application uses its own definition.

The current application domain

If you load a sub-application into the current application domain, the sub-application’s class definitions are often ignored. This behavior is because the first definition in a domain is used. Subsequent definitions loaded into that domain are ignored. If new class definitions are added, the main application can use them.

Using the current application domain is typical of RSLs and other specially compiled resources, and is not typically used when loading sub-applications.

Setting application domain

You specify the application domain of a sub-application by setting the value of the loadForCompatibility property on the SWFLoader. If you set the value of this property to true, then the sub-application is loaded into a sibling application domain. If you set the value of this property to false (default), then the sub-application is loaded into a child application domain.

You can also specify the application domain on the LoaderContext object. You do this if you specify the value of the loaderContext property when using the SWFLoader control.

Note: The value of the loadForCompatibility property is ignored if you explicitly set the value of the loaderContext property.

Loading Applications - About loading sub-applications

About loading sub-applications

Flex lets you load and unload sub-applications in a main application. Reasons:

• Reduce the size of the main application
• Encapsulate related functionality into a sub-application
• Create reusable sub-applications that can be loaded into different applications
• Integrate third-party applications into your main application
  

Level of interoperability

The way in which the sub-application is loaded defines the level of interoperability between the main application and its sub-applications. Consider the following factors when loading sub-applications in your main application:

Trusted applications What level of trust do the applications have? The higher the level of trust greater interoperability with the main application. In general, though, if you do not have complete control over the development and deployment of a loaded application, consider that application to be untrusted.

Versioning Are the applications compiled with the same version of the Flex framework? The default method of loading sub-applications assumes that all applications are compiled by the same version of the framework. However, Flex can load applications that were compiled with different versions of the framework. These applications are known as multi-versioned applications.

The level of trust and use of versioning are determined by the application domain and the security domain into which the sub-applications are loaded.

Types of loading

Single-versioned applications are guaranteed to have been compiled with the same version of the compiler as the main application. They have the greatest level of interoperability with the main application, but they also require that you have complete control over the source of the sub-applications.

Multi-versioned applications can be compiled with different versions of the Flex framework than the main application that loads them. Their interoperability with the main application and other sub-applications is more limited than single-versioned applications.

Sandboxed applications are loaded into their own security domains, and can be multi-versioned. Using sandboxed applications is the recommended practice for loading third-party applications. In addition, if your sub-applications use RPC or DataServices-related functionality, you should load them as sandboxed.

Sandboxed applications have the greatest number of limitations on application interoperability. These restrictions include the following:

• Stage Access to the stage from the sub-application is limited to some stage properties and methods.
• Mouse You cannot receive mouse events from objects in other security domains.
• Pixels Applications cannot access the pixels drawn in applications that are in other security domains.
• Properties While applications can get references to objects in other security domains, avoid doing this for security reasons. Some properties are restricted, such as the Stage or any parent of a DisplayObject that another application instantiates.

Note: multi-versioned and sandboxed applications must be compiled with the same or older version of the compiler the main application was compiled with.

Note: When compiling each of these types of applications (multi-versioned and sandboxed), you should include the MarshallingSupport class into the main application and sub-applications. You do this with the includes compiler argument, as the following example shows:
-includes=mx.managers.systemClasses.MarshallingSupport

Loadding Applications - Preface

Existem várias formas e práticas para diminuir o swf final ou carregá-lo sobre demanda diminuindo a carga de banda.

Algumas formas: RSL, CSS carregado em runtime, Módulos e Loadding Application (Sub-Apps).

Estarei lançando a partir de hoje uma série de posts falando sobre Loadding Application, o primeiro posto daqui a pouco, espero que seja útil.

Na sua maioria estes posts se consistem de um resumo da documentação oferecida pela Adobe neste site.

[]s

Modules

Estou estudando sobre módulos (Flex 3 Developer Guide) e fiz um resumo dos tópicos que achei importantes para melhor fixação e abaixo estou disponibilizando este resumo.

About modules

Modules are SWF files that can be loaded and unloaded by an application. They cannot be run independently of an application, but any number of applications can share the modules. The main application, can dynamically load other modules that it requires, when it needs them.

Benefits of modules

• Smaller initial download size of the SWF file.
• Shorter load time due to smaller SWF file size.
• Better encapsulation of related aspects of an application.

A module is a special type of dynamically loadable SWF that contains an IFlexModuleFactory class factory. This allows an application to load code at run time and create class instances without requiring that the class implementations be linked into the main application. Modules are similar to Runtime Shared Libraries (RSLs) in that they separate code from an application into separately loaded SWF files. Modules are much more flexible than RSLs because modules can be loaded and unloaded at run time and compiled without the application.

Creating ActionScript-based modules

If your module does not include any framework code, you can create a class that extends ModuleBase. If you use the ModuleBase class, your module will typically be smaller than if you use a module based on the Module class because it does not have any framework class dependencies.

Reducing module size

Module size varies based on the components and classes that are used in the module. By default, a module includes all framework code that its components depend on, which can cause modules to be large by linking classes that overlap with the application’s classes.

To reduce the size of the modules, you can optimize the module by instructing it to externalize classes that are included by the application. The result is that the module includes only the classes it requires, while the framework code and other dependencies are included in the application.

To externalize framework classes with the command-line compiler, you generate a linker report from the application that loads the modules. You then use this report as input to the module’s load-externs compiler option. The compiler externalizes all classes from the module for which the application contains definitions. This process is also necessary if your modules are in a separate project from your main application in Flex Builder.

1. Generate the linker report and compile the application:
mxmlc -link-report=report.xml MyApplication.mxml

2. Compile the module and pass the linker report to the load-externs option:

mxmlc -load-externs=report.xml MyModule.mxml

Note: If you externalize the module’s dependencies by using the load-externs or optimize option, your module might not be compatible with future versions of Adobe Flex.

Note: At Flash Builder this process can be performed in Project > Properties > Flex Modules.

ModuleManager and ModuleLoader

The ModuleManager manages the set of loaded modules, which are treated as a map of Singletons that are indexed by the module URL. The ModuleLoader class is a thin layer on top of the ModuleManager API that is intended to act similarly to the mx.controls.SWFLoader class for modules that only define a single visual UIComponent. The ModuleLoader class is the easiest class to use when implementing a module-based architecture, but the ModuleManager provides greater control over the modules.

When you load a module, Flex ensures that there is only one copy of a module loaded, no matter how many times you call the loadModule() method for that module.

Using the ModuleLoader class to load modules

Setting the target URL of a ModuleLoader object triggers a call to the loadModule() method. This occurs when you first create a ModuleLoader object with the url property set. It also occurs if you change the value of that property.

If you set the value of the url property to an empty string (""), the ModuleLoader object unloads the current module.

Using the ModuleManager class to load modules

To use the ModuleManager to load a module in ActionScript, you first get a reference to the module’s IModuleInfo interface by using the ModuleManager getModule() method. You then call the interface’s load() method.

Finally, you use the factory property of the interface to call the create() method and cast the return value as the module’s class.

import mx.events.ModuleEvent;
import mx.modules.ModuleManager;
import mx.modules.IModuleInfo;
public var info:IModuleInfo;

private function initApp():void {

info = ModuleManager.getModule("ColumnChartModule.swf");
info.addEventListener(ModuleEvent.READY, modEventHandler);
// Load the module into memory. Calling load() makes the
// IFlexModuleFactory available. You can then get an
// instance of the class using the factory's create() method.
info.load();

}

private function modEventHandler(e:ModuleEvent):void {

// Add an instance of the module's class to the display list.
vb1.addChild(info.factory.create() as ColumnChartModule);

}

You do not need to call the unload() method when adding and removing modules using the IModuleInfo class. You just need to set the IModuleInfo instance to null.

Module domains

By default, a module is loaded into a sibling domain of the current application domain. You can specify a different application domain by using the applicationDomain property of the ModuleLoader class. Because a module is loaded into a child domain, it owns class definitions that are not in the main application’s domain. For example, the first module to load the PopUpManager class becomes the owner of the PopUpManager class for the entire application because it registers the manager with the SingletonManager. If another module later tries to use the PopUpManager, Adobe ® Flash® Player throws an exception. The solution is to ensure that managers such as PopUpManager and DragManager and any other shared services are defined by the main application (This technique also applies to components). Typically, this is done by adding the following to a script block:

import mx.managers.PopUpManager;
import mx.managers.DragManager;
private var popUpManager:PopUpManager;
private var dragManager:DragManager;

Because a Flex module must be in the same security domain as the application (SWF) that loads it, when you’re using modules in an AIR application any module SWF must be located in the same directory as the main application SWF or one of its subdirectories, which ensures that like the main application SWF, the module SWF is in the AIR application security sandbox.

By default, modules do not share the main application’s StyleManager, however. They have their own instances of the IStyleManager2 class. As a result, modules can define their own styles. For example, style properties set on a Button control in one module are not applied to the Button control in another module or to the main application.

See also:
Gerenciamento de memória e tamanho dos arquivos em grandes aplicativos utilizando o Modules do Flex 2.0.1
Module unload doesn't competely unload a module (SDK-12025)