Serious memory leak!

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

var scrollView = Titanium.UI.createScrollableView({

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

var files = dir.getDirectoryListing();

    var img = Titanium.UI.createImageView({

    var scroll = Titanium.UI.createScrollView({




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 5 years ago by Vitali Virulaine
  • Any reason you're using the backgroundImage property instead of image in createImaveView?

    — commented 5 years ago 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 5 years ago by Vitali Virulaine

24 Answers

  • This might help you.


  • 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.

  • 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.

  • 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…

  • 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)

  • 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.

  • 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.

  • 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?

  • 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:

    — answered 5 years ago by Goran Skledar
    • Very interesting. Thanks, I will investigate this. I saw your posts a lot, could you give your email or other contacts?

      — commented 5 years ago by Vitali Virulaine
    • What device you have? 3G or 3GS?

      — commented 5 years ago 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 5 years ago 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 5 years ago 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 5 years ago 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 5 years ago 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 5 years ago by jd nguyen
  • posting so that i can follow this one

  • posting so that i can follow this one

  • Has anyone tested this since this commit? (Not sure if it's related)