Theoretically, modules are dynamically loaded libraries of classes, whereas SWFLoader loads applications that can function as sub-applications so more like launching sub-processes or something like Iframe. SWFLoader SWFs often can run on their own unless they expect something from the host application.
Thus modules are usually more lightweight and smaller. I doubt there will be benefits to converting your modules into sub-applications, and it can sometimes make debugging memory leaks harder as it doubles the number of application instances and runs the bootstrap lifecycle twice. One possible debugging technique is to make a TestModuleLoader. I generally do this by commenting out as much of the app as possible, and adding or repurposing a few buttons. The first level test is press a button to load a module, then press another button to unload the module. Test all of your modules using a profiler to check for leaks. Sometimes you'll catch a bad module in these tests and then you know the bad code is in the initialization of the classes in the module since there is lots of code in the module that probably didn't run in such a simple case. But often all modules do easily unload if they haven't had to do any work. But then you have a harness where you can exercise code in the module between the time you load and unload it. You can comment out code in the modules, run other code in the modules and narrow down which ones are not unloading and what code is preventing the unload. Good luck, -Alex On 12/5/17, 4:11 PM, "Kyle McKnight" <kamck...@gmail.com> wrote: > 1. I think it's a matter of preference and style really. In my mind I > view modules as more standalone than SWFs I might be loading otherwise. > Though I rarely use modules in my programming, but I come from a more >pure > AS3 background so I tend to use those APIs even within Flex and stick >to > more GUI mockup for my flex work. > 2. I've never had much difficulty with using SWFLoader, I think it's > easier than modules. > 3. I don't think there would be much of a difference, it all depends on > where the leaks come from. You can unload a module and they even get > garbage collected if you set the instance of the module to null and >there > are no references to it. I don't think switching to using SWFLoader >will > inherently cause less leaks. Have you been able to profile your >application > using a tool like Scout? > > > >Kyle McKnight >Senior UI Engineer - Accesso >321.347.7318 (M) > > >On Tue, Dec 5, 2017 at 4:59 PM, aceinc <pa...@compuace.com> wrote: > >> I am using the Flex 3.5 SDK. >> >> My entire application(s) have been developed using the moduleloader and >> mx:module. I am having memory leak(s) and I am trying to isolate and >>remove >> them. >> >> In my research I noticed "SWFLoader" and its UnloadAndStop() method. I >>was >> wondering if; >> >> 1) This would be a better choice? >> >> 2) It would be easy to implement? >> >> 3) If it would be likely to resolve my memory leak issues? >> >> Thanks for your help. >> >> >> >> >> -- >> Sent from: >>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl >>ex-users.2333346.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C5f1 >>1f458d9924d7635c008d53c3dee3d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% >>7C636481159043134352&sdata=8Gponggll3jsL7WjQa7tuazk4Y473lRMNcrokog9jlk%3D >>&reserved=0 >>
