Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Android memory leak issue

I have an application with 3 tabs.

From tab #1 the user can browse to another window and I call:

    Titanium.UI.currentTab.open(winx
    , {
        animated: true
    });

If you browse back and forth the application will eventually crash due to an out of memory error:
[TRACE] E/AndroidRuntime( 787): java.lang.OutOfMemoryError: bitmap size exceeds VM budget

It seems as though the memory for a window is never freed, or some type of other memory leak.

Is this a memory leak, or is there a more appropriate way to handle windows to prevent the issue?

You can re-create this from Kitchen Sink by going to image views and going into the Animated example and hitting the 'back' button on the phone then click on the Animated example again. Repeat this about 20 times and the application will crash.

— asked May 5th 2010 by Vinh Bui
  • android
  • leak
  • memory
  • window
0 Comments

14 Answers

  • I think I have a temporary solution for the issue.

    When closing every window of your app, meaning in the

    win.addEventListener('close',function(e){ //here });
    
    1. Release all sounds you might have used with sound.release();.
    2. Change the source of all your images to nothing (myImage.image = ''), and the same for backgroundImage.
    3. Remove all UI elements and controls from your window (win.remove(scrollView);.

    If you have too many, loop through them. I'm not sure if this solution completely fixes the problem, at least it seems it does in my case. I hope an official fix comes soon. This simply 'shucks'.

    — answered December 10th 2010 by George Marmaridis
    permalink
    2 Comments
    • Thanks George! This worked very well! Despite it being a brute-force method.

      — commented January 8th 2011 by Zheng Da Clinton Goh
    • This doesn't seem to work with a ScrollableView. I tried looping through every view in a scrollableView and set image to '' then also remove each view and then finally remove the scrollableView. But the memory doesn't get all released. So when opening that window again the memory always keep growing.
      Titanium on Android seems like really alpha unstable version. I'm regretting using this framework.

      — commented March 31st 2011 by Daniel Tome
  • Did anyone ever figure anything out on this (how to release the image views). I am running out of ideas. Using SDK 1.8.

    — answered August 18th 2011 by Ken Rucker
    permalink
    0 Comments
  • Bump. This is still an issue in 1.7.2. and 1.8.0.

    — answered October 7th 2011 by Jaron Rubenstein
    permalink
    0 Comments
  • Hi,

    I'm reproducing this issue (in 1.7.3). I tried the « solution » given by George Marmaridis above but the application freeze when I close the window if I tried to remove either an image or view.

    — answered October 31st 2011 by Raphaël Lemaire
    permalink
    0 Comments
  • Hi,

    I'm reproducing this issue. I tried the « solution » above, but the application freezes if I tried to reset a Image view and/or remove a view.

    Moreover the "close" event is not catched if close() is called manually (for instance to make use of the android back button), so I had to use a customClose function.

    — answered October 31st 2011 by Raphaël Lemaire
    permalink
    0 Comments
  • Did anyone find a fix for this? I cant even run my app for more than 10 secs on the device and a little longer on the emulator.

    I get this error -
    java.lang.OutOfMemoryError: bitmap size exceeds VM budget

    I understand it could mean that the images are too big, but actually they are not.

    I also got an error that there was some leak in the activity. I didnt copy the error at that time. But I will add it again later.

    Anyone know a fix? Titanium team?? Aaron Saunders? You should be answer these questions and help us find a solution, so we continue using this product! Everything seems to be an issue. Please help us!

    — answered October 31st 2011 by Sridevi Kolluri
    permalink
    0 Comments
  • Using DDMS i found that Memory allocated to application is get increases as i am navigating screen by screen and after some time it crash application with force close message/Fail to load resources. Even i have remove all objects from window and after that assign null to it. i.e
    window.remove(viewname);
    viewname=null;
    window.close();
    window=null.
    Please help Me OUT.

    — answered February 16th 2012 by Fernan Delgado
    permalink
    0 Comments
  • Any help suggestion which help me out.

    — answered February 21st 2012 by Fernan Delgado
    permalink
    0 Comments
  • We are seeing a similar issue, but is seems to be happening on every window that we open, not just windows with image views, or table views. Basically any window that we open, then close enough times will crash the app. I open up ddms and monitor the device memory, and it slowly runs out of free space, until our android app crashes.

    There just seems to be a general memory leak on all windows, in fact I don't ever notice the app releasing any memory back to the device. I really hope this will be addressed in 1.5, because it causes any app with navigation to crash if used long enough, and our app has some pretty large windows with tables views, many label, text boxes, etc.. so, our app crashes in about 15-25 open/closes of a window.

    Seems like this should be a very high priority to fix.

    — answered August 22nd 2010 by Jeremy Diviney
    permalink
    1 Comment
    • Same issue with me, app crashes after opening too many windows with imageviews.
      Please fix…

      — commented September 4th 2010 by Friedrich Seydel
  • I just want to bump this as it's still an issue for me - Ticket 886 that Don Thorp mentioned says it's resolved but it's clearly not. If any of the Appcelerator team are listening, please look into this - it's stopping one of my apps from being released!

    — answered September 17th 2010 by Michael Park
    permalink
    0 Comments
  • I might be able to add another usecase, when u have a single scalable imageview (canScale is true), then open the gallery and set it to the image you picked. Then do it again several times.

    I dont know what happens, but eventually you cannot change the image in the imageview, and not at all (in fact, the application doesnt enter in none of the gallery callbacks at all, nor success, nor error).

    If u go to "manage applications" area and do "clear data" operation, you will be able to change the image again a couple of times, then it gets stuck again.

    You can also see that in the data section of the application, the amount of data used is always the same constant thing, when u come to clear it.

    — answered October 5th 2010 by Ganna Kozynenko
    permalink
    0 Comments
  • reseting image.url and removing children doesn't seem to work. still experiencing this issue with 1.7.2

    — answered July 28th 2011 by dev 1605
    permalink
    0 Comments
  • @michael are you running with the latest CI build?

    — answered September 20th 2010 by Don Thorp
    permalink
    0 Comments
  • Thanks! I've added Ticket 886 to track it.

    — answered May 5th 2010 by Don Thorp
    permalink
    1 Comment
    • Hi,

      OutOfResourcesException creating surface am geting this error, when i have more than 50 images in an scroll view control. Those image am getting from webservice call. how do i get rid of this error.

      My application should not get force quit. how do i handle this exception?

      Thanks in advance.

      — commented January 13th 2013 by Sudhindra BA
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.