Titanium Community Questions & Answer Archive

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

Serious memory leak!

Hello. I investigated the memory leak issue. I have such code (modified KitchenSink):

var scrollView = Titanium.UI.createScrollableView({
    views:[],
    showPagingControl:true,
    pagingControlHeight:30,
    maxZoomScale:2.0,
    currentPage:1,
});

var dir = Titanium.Filesystem.getFile(Titanium.Filesystem.resourcesDirectory+'/hires');

var files = dir.getDirectoryListing();

for(i=0;i<files.length;i++)
{        
    var img = Titanium.UI.createImageView({
        backgroundImage:'../hires/'+files[i],
        width:640,
        height:880,
        left:0,
        top:0,
    });

    var scroll = Titanium.UI.createScrollView({
        contentWidth:320,
        contentHeight:440,
        minZoomScale:0.5,
    });

    scroll.add(img);

    scrollView.addView(scroll);    
}

win.add(scrollView);

So I noticed that every Scroll event free memory decreased by 2-3MB, looks like Titanium creates new view for current focused view and there is NO way to release the memory.
I don't understand why memory consumes when I scroll to new view. All views already loaded in that For cycle.
I have app crash after 7-8 scrolls on my iPhone 3G.
1.3.0 SDK

— asked July 25th 2010 by Vitali Virulaine
  • crash
  • memory
2 Comments
  • Any reason you're using the backgroundImage property instead of image in createImaveView?

    — commented July 31st 2010 by Goran Skledar
  • Yeah, I need to change the image smoothly, it cannot be done by setting new "image" attribute, it blinks a lot

    — commented July 31st 2010 by Vitali Virulaine

24 Answers

  • This might help you.

    http://shakilspace.blogspot.com/2011/02/appcelerator-titanium-scrollview-swipe.html

    :)

    — answered February 3rd 2011 by Manaday Mavani
    permalink
    0 Comments
  • i can concur with this problem and lots of others on Q/A here too. The memory reduces each time an imageView is adding to the scrollableview (either using backgroundimage or image attribute do not matter).

    If you compile/run your project in XCODE/DEBUGGER you can see that garbage collect only occurs only when the memory is almost depleted, at that point the app would be starting to crash. I still haven't found a solution to it yet, but been trying to mess around with TI iphone/class to force a garbage collect…so we'll see.

    1.4 is complete a bug kill for me since there're so many problems i've run into.

    — answered July 31st 2010 by jd nguyen
    permalink
    1 Comment
    • Yes, I tried 1.4.0 too, old bugs not fixed + new ones

      — commented July 31st 2010 by Vitali Virulaine
  • ScrollableView is absolutely useless when adding many objects to every view. I failed to complete my application, it was just 5 small images, 10 labels and 1 background on every view, scrolling was horrible, it just crashed (probably because of memory).
    As I know Titanium has its own garbage collector, it definitely needs improvements. You just cannot imagine how many times I faced same memory problem, in fact Titanium is suitable for text-based simple applications, if you want to to something beautiful with custom graphics - just forget it, it will always be slow and may crash on iPhone 3G.

    — answered December 9th 2010 by Vitali Virulaine
    permalink
    0 Comments
  • I think I run into the same problem.

    My app loads tons of images and crash very soon and it's always on view.add(something, button, image, anything).

    The app freezes.
    In simulator, it happens pretty fast.

    I load a 450x450 png and make a zoom, sometimes it freezes the first time.

    On iPhone 4, I can do this a hundred times but it still happen to freeze…

    — answered December 15th 2010 by Thomas Bullier
    permalink
    0 Comments
  • This code crashes my iPhone 3G (scrolling from left to right), free memory 2-3 MB

    The Code

    Images in /pages 50-60KB
    Images in /hires 300-500KB

    Even setting back backgroundURL doesn't free up memory

    1.4.1 SDK from continious build, iOS 4.0 (emulator and iPhone 3G)

    — answered July 31st 2010 by Vitali Virulaine
    permalink
    0 Comments
  • Subscribing - bump. FYI try running that on an iPod touch. Even worse. This is a major hurdle for my apps… if there is actually a way to fix the garbage collection it should be a huge priority for Appcelerator.

    — answered August 24th 2010 by Todd Soligo
    permalink
    0 Comments
  • Yeah, waiting for a fix long time. I cannot find the way to fix it on my side, it's inside the SDK. I hope in 1.5 version it will be fixed.

    — answered August 25th 2010 by Vitali Virulaine
    permalink
    0 Comments
  • Why are you saying Up on a Q/A without asking a question or giving an answer? Nobody is going to have an answer if you don't have a question so what is it? Do you feel there is a memory leak? Have you experienced one? Or are you trying to see if this has been resolved?

    — answered November 10th 2010 by John McKnight
    permalink
    1 Comment
    • If you read the title he "feels" there is a memory leak.

      — commented April 4th 2011 by Daniel Tome
  • Up

    — answered July 27th 2010 by Raul Magdaleno
    permalink
    0 Comments
  • up

    — answered July 30th 2010 by Vitali Virulaine
    permalink
    0 Comments
  • up

    — answered July 31st 2010 by Vitali Virulaine
    permalink
    0 Comments
  • I tried running this on my iPhone4 device, iOS SDK 4.0.1 and the latest Titanium continuous build (Jul 30th) from here.

    I loaded 10 images, about 2MB in size (2592x1936px) each. I didn't experience any memory leaks or app crashes after fiddling with the scrollable view for a few minutes, zooming in/out etc.

    Titanium.Platform.availableMemory reported these figures:

    1. Application start: 266
    2. Scrolling through all images once: 235
    3. Scrolling, zooming for ~1 minute: 235
    4. Suspending to background/reopening: 236

    Here's the exact code I used for testing: http://www.pastie.org/1068804

    — answered July 31st 2010 by Goran Skledar
    permalink
    7 Comments
    • Very interesting. Thanks, I will investigate this. I saw your posts a lot, could you give your email or other contacts?

      — commented July 31st 2010 by Vitali Virulaine
    • What device you have? 3G or 3GS?

      — commented July 31st 2010 by Vitali Virulaine
    • I tested on iPhone 4 running iOS 4. I can also test with 3GS on iOS 3.1.3 if that helps. For older (3G) devices I would definitely try to implement some sort of progressive loading of larger images. I would load 2-3 images at the beginning and then add/remove images when the user is scrolling back and forth.

      — commented July 31st 2010 by Goran Skledar
    • Is there any way to change current imageview "image" attribute to hi-res file? I tried to zoom it out but it doesn't work. The Idea is to change current image to hi-res an the rest to lo-res.

      — commented July 31st 2010 by Vitali Virulaine
    • Goran Skledar, with iPhone 4 you do have more RAM on the device, so I think it can handle a bit. Since TI is notorious from not releasing memory on views…eventually it will be eaten up alive. Have you try to load more than 50 or 60 images?

      I have an iPhone 3G and already employed different methods of loading on demand or remove as well, but problem is views are not properly released, so eventually it will crash.

      — commented August 1st 2010 by jd nguyen
    • JD Nguyen, have you resolved that memory issues?Is there any way to release the memory? The only way is to load bigger image to different window and close it when done, that will release memory

      — commented August 1st 2010 by Vitali Virulaine
    • i was able to inject my own code (you could call it a close function) into the TI's scrollableview in xcode, that to close on views/scrollview directly and it appeared to reduce the memory usage. However, by doing this I'm basically removing left and right of imageview, but show only the current active one, and dynamically repopulate other deleted ones when scroll again. I was able to get to that till 3AM this morning, but couldn't keep my eyes open :), so I'll continue playing around with it some more.

      I think the only way to really stabilize the scrollableview out without running into this memory is to offload the images to the device, into an sql table, and not saving it to RAM. I hope TI's team will consider that.

      — commented August 1st 2010 by jd nguyen
  • posting so that i can follow this one

    — answered August 13th 2010 by karlo kilayko
    permalink
    0 Comments
  • posting so that i can follow this one

    — answered August 13th 2010 by karlo kilayko
    permalink
    0 Comments
  • same issue here, nothing get ?

    — answered September 15th 2010 by Esteban Fernandez
    permalink
    0 Comments
  • Has anyone tested this since this commit? (Not sure if it's related)

    http://github.com/appcelerator/titanium_mobile/commit/00c73f859f79d422b4c08d05816986a51cb0c999

    — answered September 16th 2010 by Richard Venneman
    permalink
    0 Comments
  • up

    — answered November 10th 2010 by sean oreilly
    permalink
    0 Comments
  • up

    — answered November 10th 2010 by sean oreilly
    permalink
    0 Comments
  • up

    — answered November 10th 2010 by sean oreilly
    permalink
    0 Comments
  • up

    — answered November 10th 2010 by sean oreilly
    permalink
    0 Comments
  • up

    — answered November 10th 2010 by sean oreilly
    permalink
    0 Comments
  • up

    — answered November 10th 2010 by sean oreilly
    permalink
    0 Comments
  • up too!

    — answered December 7th 2010 by Adriano Paladini
    permalink
    0 Comments
  • bump

    — answered August 10th 2010 by Sindre Sorhus
    permalink
    0 Comments
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.