In an AIR application, the
System.gc()method is only enabled in content running in the AIR Debug Launcher (ADL) or, in an installed applcation, in content in the application security sandbox.
and it worked for me when testing an ipad app. you can create a textfield that displays the system.totalMemory to confirm it's working for you.
It's not useful if you are disposing of your objects properly.
Cache will still ensue. Running a gc at that point can slow you down. iOS knows when it needs more memory and your dereferenced objects will be removed for you.
Again, as long as you're cleaning up your objects properly, there is no need to manually call garbage collection. You may do 'the same thing again' and what otherwise would have already been in memory as cache would have to be reallocated, slowing you down.
Flash Builder memory profiler will show you how it will act and if you're disposing your objects correctly. As long as you don't notice instances being generated and not removed when you thought they should have, you're fine.
using system.gc() is extremely useful during testing and again, you can create a textfield that displays the system.totalMemory to confirm that it's not working for you but that you're properly reading objects for gc.
It can be useful if you don't have flash builder with the memory profiler (which has a button to call for gc cleanup) but ultimately with proper object disposal, what use is it? That memory will be cleaned up the second it is completely dereferenced and the OS needs it.
If you don't have flash builder with the memory profiler then just watching system.totalMemory can give you an idea as you use your app more and more if you're leaking, and if you are, gc won't help.
From the sound of it, doing gc is ultimately useless if one do the proper dereferencing.