AIR runtime Memory Leak?

Question

Hi,
I have an app developed with AIR 3.7 for iOS (iPad)
The app gets very sluggish after a while, eventually crashes.
I've been -very- careful to pool objects where possible and cleanup / nullify all objects once they're not needed any more.
Profiling the app in Scout returns a pretty stable memory profile (the peaks and the lows translate very well to what's happening on screen)
Simultenously profiling the app using XCode's Instruments, shows me that the memory consumption off the app constantly rises up to the point the systems spends more time throwing memory warning than anything else.
Here are screenshots of both profilers: they show as3 memory usage being pretty stable, on the app level, memory keeps rising...
https://dl.dropboxusercontent.com/u/608333/AIR_memory_leak.zip
If AS3 is not leaking any memory (according to scout), but the app is (according to Instruments), would I be right assuming there's a memory leak in the AIR-runtime itself?
thanks for your feedback!
bart.

Answer 1

ok, lots of trial and error has showed me the following:
There are two issues when loading assets using the Loader Class with its LoaderContext set to ImageDecodingPolicy.ON_LOAD.
These issues typically arise in a magazine-like app, where many images are loaded and unloaded continously.
Issue 1:
When initializing a load() on a Loader class with LoaderContext to ImageDecodingPolicy.ON_LOAD, all image decoding seems to be queued in a seperate thread. With several large images, especially on mobile devices, the time to crunch through a queue like this can easily go into dozens of seconds. During that time, some of the loaders can be unloaded, cleared, nulled and deleted. Yet, the loader isn't removed from the decoding queue.
In other words: once you fire the 'load' method on a Loader instance, you're not able to cancel the decompression process, even though the decompression might not even have started yet, as queued by other decompressions.
Issue 2:
When a Loader instance is unloaded, cleared, nulled and deleted while its decompression is still queued and not yet fully decompressed, there seems to be a memory leak. With several dozens of images loading and interupting the loading, you'll notice a difference in memory consumtion when comparing memory output in Scout and in Instruments. Both memory graphs build up very similar yet after the runtime's garbarge collection kicks in, the memory graph in Instruments seems to not release memory fully. Consumption gradually rises until the app eventually crashes.
https://dl.dropboxusercontent.com/u/608333/AIRMemoryLeakExample.zip
This example app allows you to create loaders in bursts by touching the screen.
You'll instantly see the massive waiting times for decompression, despite the fact there's only a few Loader instances in memory at the same time. After several short bursts and wait-a-bit-for-decompression-to-catch-up, you should also notice the difference in memory profiling between Scout and Instruments.
I managed to work around both issues by making a LoaderQueueManager class.
This class instantiates and returns a Loader instance, queues these instances and tracks its onComplete handler. Only when one loader is finished loading, the next loader starts loading. This way, you never have different instances trying to simulataneously decompress their content. As such decompressions are never interrupted and loaders can also be de-queued. This practically speeds up decompression dramatically, since images that are removed won't get decompressed in vain. Memory Leaks also don't occur, since not a single decompression is ever interupted.
This solution only works with content loaded locally.
Hope you can get somewhere with this,
and hopefully, you find a fix in one of the next AIR releases.
best,
bart.