Memory Leaks vs High Memory Allocations?

Question

In my iPhone app I have a very long table which I am loading from xml (online xml). This table shows one image and some text data in a row. I am also using Lazy Loading to load image. Now in instruments there is no serious leaks, but overall memory allocation raising as I scrolling the table to down (means loading new images).

I want to know will this cause app crashing? My client is saying that the app is crashing on 3GS and iPhone 4, I am testing app on iPod 4G. I am not seeing any crashes but I can see high memory allocations in Instruments.

Please Help!

update -

Yes I am using resuable Cells. When the image loads I add them into the cells using this code -

- (void)appImageDidLoad:(NSIndexPath *)indexPath
{

IconDownloader *iconDownloader = [imageDownloadsInProgress objectForKey:indexPath];
        if (iconDownloader != nil)
        {
            UITableViewCell *cell = (UITableViewCell *)[tblView cellForRowAtIndexPath:iconDownloader.indexPathInTableView];

            // Display the newly loaded image
            UIImageView *mixtapeImage =  (UIImageView *) [cell viewWithTag:TAG_IMAGE];
            mixtapeImage.image = iconDownloader.appRecord.mixtape_image_obj;

        }

}

You are right that i am not releasing the image because if I scroll up the table I have to add images in cells again thats why I am caching them in "imageDownloadsInProgress" dictionary.

Is there more efficient way of doing this?

Answer 1

The issue could very well be the images being cached, in which case the best solution would be to remove some images from the cache when you get a low memory warning. You could possibly write them to disk temporarily, which would provide a faster load time next time they're needed than re-downloading.

Answer 2

Do you respond to memory warnings? If you do, and you do it properly, your app will not crash. However, if you are simply scrolling a table view, and memory is building up (does it keep building up, and by how much?) there is something wrong. It could be something as simple as an autorelease pool that is out of place (you are doing image loading), but it could very well be more serious.

Not seeing crashes on one device does not mean it will not crash on devices with a different state (i.e.: low memory state).

You could update your post with a screenshot of instruments, maybe the object allocations list, etc.

Answer 3

Yes, it can cause a crash. Once you've taken into account the background processes, the shared libraries and your own code, your app only has a few megabytes of memory available on some iOS devices for custom data. If you blow through that, even if you can account for all of the allocations, then you will get killed by the low memory system. Or your app will, anyway.

You've already launched Instruments, which puts you in the top 1% of iOS app developers for knowing how your app behaves on the device. Well done! The next step is to understand why you're monotonically increasing memory usage as the table scrolls through. OK, so you lazily load images when they're needed, but do you dispose of them again when they're not? That should be easy to do using a UITableView with reusable cells, but perhaps you're caching the images somewhere and never emptying the cache. What happens in Instruments when you send a low memory warning in the simulator?

Answer 4

Memory increasing as you scroll is not a good sign. A common issue is that you are reusing cells and you keep piling elements on top of each other. Cells look fine because you only see the last layer of UI elements. These are not leaks because they are referenced by the table cell as parent view.

In terms of diagnostics, try the "Allocations" instruments to see if you have more live objets of some type (say, UIImages) than you expect. This is how you would do it:

In the Allocations instrument, using the top-right search box, search for "Image". Then look for the column labeled #linving in UIImage. That number is the number of UIImage objects. That is a better compass in to figuring out where are your UIImages going. If at some point you have more objects than what you expect, and thease UImages are not going away you have a UIImage leak in your hands. An UIImage leak will kill your app real fast.

quote from this answer.

Answer 5

What does your cellForRowAtIndexPath method look like? Do you actually autorelease the cell you allocate in there?

There's no need for you to retain images - iOS is very good at caching results, and if it wants to release cells for memory management reasons, you should let it.

iOS versions pre-4.0 have lower limits for memory allocation. That's why the app crashes on your client's iPhone but not on yours.