Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This will not solve your problem but I hope it helps. </p> <ol> <li><p>First and foremost you are not getting anywhere just by looking and refactoring code. You need hardcore data that proves that you have a leak, which then will tell you what is leaking so you can fix it. From all the memory profilers I've used the FlashBuilder one is still the best, the IntelliJ one was not reliable a year and Adobe Scout only does performance analysis. </p></li> <li><p>Start by your smallest modules and with the memory profiler open prove that opening and closing a module (preferably in isolation of the main rig) creates a leak. If that's the case I would start by removing ALL the code from the module, and testing it again, add part by part which will lead you to the lead eventually. You can use a best suspects search, where you first address event listeners, etc.</p></li> <li><p>This <a href="http://blogs.adobe.com/tomsugden/2010/02/how_to_unload_modules_effectively.html#more" rel="nofollow">article from Thomas Sugden</a> is still the best I've read about flex memory profiling and you should read it from end to end if you haven't.</p></li> <li><p>It worth your time to write tools that allow you to test your modules, who knows even automate the process that evaluates if there are leaks or not. This is important because sometimes there are leaks that will not be your fault, the Flex framework has a bunch of them that you just can't avoid.</p></li> </ol> <p>Hope this helped.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload