Runnable Class doubles memory need of application

Question

Hi
I use a class called DisplayTimer to throw an event every second. This class is Runnable and runs as an own thread. Then I have OrientedText2D Object in a java3d environment that listen to these events and update their caption (countdown time) every time they receive an event. So far so good, the solution works. BUT the memory need of my application doubles when i .start() the Runnable DisplayTimer class to start the event-throwing for the countdown captions...
Here is the DisplayTimer class:
import java.util.*;
import de.qtobe.events.*;
import de.qtobe.tools.*;
public class DisplayTimer implements Runnable {
    private List _listeners = new ArrayList();
    Thread t;
    public DisplayTimer() {
        t = new Thread(this);
        t.start();
    public void run() {
        while (true) {
            _fireUpdateNotificationEvent();
            //Runtime r = Runtime.getRuntime();
            //System.out.println("before: " + r.freeMemory());
            //r.gc();
            //System.out.println("after: " + r.freeMemory());
            try {
                Thread.currentThread().sleep(900);
            } catch (java.lang.InterruptedException e) {
                Log.log("Error in DisplayTimer occured.");
    public synchronized void addUpdateNotificationListener(UpdateNotificationListener l) {
        _listeners.add(l);
    public synchronized void removeMoodListener(UpdateNotificationListener l) {
        _listeners.remove(l);
    private synchronized void _fireUpdateNotificationEvent() {
        UpdateNotificationEvent updateNotification = new UpdateNotificationEvent(this, false);
        Iterator listeners = _listeners.iterator();
        while (listeners.hasNext()) {
            ((UpdateNotificationListener) listeners.next()).updateNotificationReceived(updateNotification);
        updateNotification = null;
        listeners = null;
}This is how the listeners react:
    public void updateNotificationReceived(UpdateNotificationEvent event) {
            if (this.impactInfo != null) {
                //Ausgabe kommt in die "Machine"
                //String caption = "Remaining service time: " + this.impactInfo.getFormattedRemainingServiceTime();
                //caption += ", Countdown to breach of contract: " + this.impactInfo.getFormattedCountdown();
                String caption = "" + this.impactInfo.getFormattedCountdown();
                caption += " (remaining fullfill time: " + this.impactInfo.getFormattedRemainingServiceTime() + ")";
                this.setCaption(caption);
                if (impactInfo.getCountdownBreachContract() <= 0) {
                    this.setCaptionColor(Def.COLOR_RED);
                } else {
                    this.setCaptionColor(Def.COLOR_HOTRED);
                caption = null;
            }The events transport no information or data btw.
Does anyone have an idea how I can optimize this solution?
Thanks in advance!

Answer 1

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#WS19 f279b149e7481c45454d9412c561d3223-8000
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.