Memory consumption of class declarations (with embedded graphics, animations and audio)

[kaveri2]

Hi all,

our application is a "portal", where the user can choose from many different activities. The activities are AS3 classess, mostly FLA library symbols, exported for ActionScript. The classes are loaded into Flash Professional using SWC files. The classes are made in the old-fashioned way on the timeline, containing graphics, animations and audio.

The memory consumption of the app goes up, when a class instance is created and it goes down, when the instance is destroyed. This works well and we've taken care of memory leaks.

What I don't know, is how much memory the class declarations take and do the "embedded" graphics, animations and audio use memory? Or are the assets loaded only when the class instance is created? Any help understanding this? It just seems that now that the app has grown bigger, it has become unstable even when only accessing the previously stable parts of the app...

[Blakflag]

I found that the memory footprint grows with the size of embedded assets. That is, that if you're embedding symbols with linkage names, then doing new clazz(), the memory is taken up even before the instantiation (or if it is never instantiated).  Just embedding alone is enough to cause the memory use to bloat up.

I'm not sure why this is, but it forced me to abandon yet another strategy for getting around the iOS swf-with-actionscript reloading problem.

I'd suggest running Adobe Scout to do memory profiling on your app and you can see how much the  memory grows as you add new swcs.

Edit: you didn't mention the platform. I was answering with my experiences compiling an App for iOS.

Message was edited by: Blakflag

[jadams602]

The common understanding is that the swf is loaded into memory at once and in full, and so embedded assets take up initial memory based on how much they contribute to the SWF size even before any of them get instantiated into their runtime class form.  This is certainly the case for Android or desktops that use the SWF, it isn't clear if the native iOS compiling ends up treating the embedded assets memory footprint in the same way or not, but possible.

There is a compiler flag which you can add called -size-report=report.xml that can give you a complete breakdown of how  each type of data within the SWF contributes to the size in compressed form. It is most likely this memory footprint that contributes to loading the SWF (independent of actually instantiating or hydrating any of the embedded assets).

http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf67110-7ff4.html#WS19f279b149e7...

There most likely are others here that know more details or might even want to correct some of these assumptions, but that is why most mobile developers choose to load assets from the filesystem if possible as opposed to embedding assets to avoid the extra memory hit on the initial SWF loading into memory.

[kaveri2]

Thank's for the hint. I created the size report and it's not horrible. The SWF is about the same as APK, only 30 megs. We'll have to use Adobe Scout to see if the compressed files are decompressed to some level, when the application starts. That's how we would know the priority order of externalizing assets.

[kaveri2]

Thank you for replying. So we'll have to go through the classes one by one and test how much the embedded assets use memory. Any rules of thumb would be great, for example how much compression helps?

Luckily the bulk of our application loads assets from the disk. It's just that some of our content developers preferred the old way and we decided not to be strict about it. Now we have to find clever ways to fix the problems...

And yes, we have created Android and iOS applications. In fact, the same FLA files that we compile into SWC files, compile into SWF files too. So the project is published on the web too, with dynamic SWF loading. There AS code in Flash Builder has the same role as the HTML embed code.

[kaveri2]

We profiled memory with XCode. The minimum memory consumption seems to increase according to the size of the SWF, though with some inconsistencies. But we can assume the embedded assets are always in the memory, in packed format.

Our problem was that there were a few extremely large (over 20 megapixels) bitmaps, which were created using "Generate Sprite Sheet..." tool. What happened with them was interesting: When they appear on the timeline, Flash unpacks them creating a huge memory spike. Then instantly the memory consumption eases - apparently Flash instantly optimizes the bitmaps to fit texture memory. That's why we didn't see major performance problems runtime, but the application started crashing because of that initial memory spike.