Discussion Area

ask questions, discuss topics, solve problems

Discussion Home | About | Threads By Date | Search

Approaches identified for Flex Memory Management

Thread posted 07/24/09 by Appyfizz007 last edited 07/24/09
2,674 views, 6 comments.

Title
Approaches identified for Flex Memory Management

Content

Hi All,

I am in the process of making a Flex Memory management approach document which will primarily cover the areas related to Flex GC and the Flex memory costly processes and also the workarounds that how can we resolve them.

I will update on that very shortly......

Thanx

Appy

Comments

posted 08/11/09 by Appyfizz007 | Report Abuse

Hi All, I am sharing few of the analysis I had in my past experience with Flex memory management. Please go through it as it might be quite helpful in the memory management in your projects.   Thanks Appy

posted 08/11/09 by Appyfizz007 | Report Abuse

<h1 style="background: #e0e0e0; margin: 12pt 0in 12pt 0.3in; text-indent: -0.3in; text-align: center; tab-stops: list .3in; mso-list: l0 level1 lfo1;"><a name="_Toc235961581">1.       Painful areas </a></h1>   The following issues which might be critical in our application   1.     Flex Event Listeners   Best Practice: Always make Weak Reference “true” for any event listeners we make.   Actual: textInput.addEventListener('change', handleTextChanged, false, 0, false);   Expected: textInput.addEventListener('change', handleTextChanged, false, 0, true);   2.     Flex Cairngorm Event Listeners     Best Practice:  Always remove the commands which are not in use. Example: In Cairngorm we have a Load Command which will be used only during the load of the application and will never be used in the later stage of the application.   It is always better to remove LoadCommand from the application.   Expected: How to remove:   Use removeCommand(eventName);   This API should be called in the controller of the application.   3.     Always use dictionary The model locator should have dictionary objects for huge data storage in the memory cache.   Actual: Array Collection and XMLListCollection   Problem: No weak reference parameter is present.     Expected: Dictionary   Solution Weak Reference attribute can be set by passing “true” in the constructor.   Example:   Var dict:Dictionary = new Dictionary(true);   This will pick the dictionary reference for GC when the parent class is removed.   4.     Binding             Binding is not removed from the class object if declared statically.                         Actual: <mx:Binding source=”” destination=””/>                         Expected:             BindingUtils.bindproperty() or BindingUtils.bindsetter() should be used.               Using the above, binding can be removed while the parent class is destroyed by    using:               //  watcherSetter.unWatch();   Note: It is better to use Flight Framework which has Binding API’s which removes the Binding memory leaks occurs in Flex Binding.   5.     Module Loading and Unloading   Actual: Module Loader or Module Manager for loading and unloading the module. Module Loader multiple instances are created for loading every new module.   Expected: Use the same module loader instance for loading and unloading new module.   For loading multiple modules, multiple instances needs to be created and each instance should be marked as weak reference.   For making any instance as weak reference use GSkinner Classes for making an object “weak reference”. Refer to sec: 14   6.     Effect used in Charts               Actual: Effect are started by calling the method:                         effectInstance.play();               Expected:             Explicitly register an EFFECT_START listener on the effect to set   EffectManager.lastCreatedEffect = null when the effect plays.   7.     Application domains             Actual: While module is loaded the current module loaded is not considered to      be loaded in the same domain.         Expected: Always make the domain of the module to be “currentdomain”                         <mx:ModuleLoader ApplicationDomain=”current”/>                                     Or             moduleLoaderInstance.applicationdomain = ApplicationDomain.currentDomain               This will optimize the module to the current application and the memory utilization             for the module can be minimized.   8.     States             Actual: States are loaded and removed dynamically which consumes the memory a lot.             Expected: Always try avoiding adding and removing the states while state             change and the objects can be used judicially by showing/hiding the state           information.   9.     Popup Manager Actual: Popup is created and destroyed by following the below methods:   PopupManager.createPopup() and PopupManager.removePopup()   Expected:   Popup should be created once and should be added later.   Example:   Var objPopup = PopupManager.createPopup() // One time   objPopup.removePopup(); // Called   PopupManager.addPopup(objPopup); // Later for creating the same popup.   It is always good to remove the created popup and a similar popup should be created only by using addPopup method.     10. Judicial Usage of Static Objects, variable and methods   Expected:  Only the application level objects whose life time is supposed to remain throughout the application lifetime should be declared static objects. Static Objects and Methods is good in terms of memory consumption but there is no way to allocate Static Objects for GC.   Static objects hold the memory throughout its life time and Flash Player/ADL never allocates a static object for Garbage Collection. Flash player skips the static objects considering that it has a reference available in the application.   11. Use of Runtime Shared Library               Expected:  Runtime shared library should be created for commonly used             components in the application and it should never be reloaded by every module            using   them.

posted 08/12/09 by Ram p | Report Abuse

not very clear with 8th point...can you be more specific....however, I find this very informative! Thx for sharing this.

posted 08/12/09 by Appyfizz007 | Report Abuse

Hi, In Flex states are used quite often for changing the views of the application. In case of adding new components in the same base view quite a number of operations of adding and removing the child components take place. States that are meant to be changed through often user's interations should not be handled in such a way. In case of similar views of the states all the components should be created at the startup and they should be handled by show/hide operations. Example:   <mx:states> <mx:State name="Register" > <mx:AddChild relativeTo="{loginForm}" position="lastChild" > <mx:target> <mx:FormItem id="confirm" label="Confirm:" > <mx:TextInput/> </mx:FormItem> </mx:target> </mx:AddChild> <mx:SetProperty target="{loginPanel}" name="title" value="Register" /> <mx:SetProperty target="{loginButton}" name="label" value="Register" /> <mx:SetStyle target="{loginButton} " name=" color" value="blue" />  <mx:SetProperty target="{registerLink}" name="visible" value="false" /> <mx:SetProperty target="{registerLink}" name="includeInLayout" value="false" /> <mx:AddChild relativeTo="{spacer1}" position="before" > <mx:target> <mx:LinkButton id="loginLink" label="Return to Login" click="currentState=''" /> </mx:target> </mx:AddChild> </mx:State> </mx:states>  <mx:Panel title="Login" id="loginPanel " horizontalScrollPolicy=" off" verticalScrollPolicy="off " paddingTop=" 10" paddingLeft="10" paddingRight="10" paddingBottom="10" > <mx:Text width="100%" color="blue " text=" Click the 'Need to Register?' link to change state. Click the 'Return to Login' link to return to the base state." />   <mx:Form id="loginForm" > <mx:FormItem label="Username:" > <mx:TextInput/> </mx:FormItem> <mx:FormItem label="Password:" > <mx:TextInput/> </mx:FormItem> </mx:Form> <mx:ControlBar> <mx:LinkButton id="registerLink" label="Need to Register? " click="currentState= 'Register'" /> <mx:Spacer width="100%" id="spacer1" /> <mx:Button label="Login" id="loginButton" /> </mx:ControlBar> </mx:Panel> See the bold out colored part in the code.   Happy Flexing Thanks Appy

posted 09/15/09 by Pankaj Munjal | Report Abuse

cool, i like all tricks to avoid memory leaks in Flex.

posted 09/29/09 by Ravi S Sharma | Report Abuse

Hi, In Section 4 (Module Loading and Unloading) you are redirecting us for "Refer to sec: 14" where we would get this. Thanks Ravi

Use of this website signifies your agreement to the Terms of Use and Online Privacy Policy (updated 07-14-2009).

Site powered by the all powerful, super charged, amazing ColdFusion 9!