tags:

views:

69

answers:

2

Hello All,

I have two queries

  1. I was running a sample app which having single view controller in it implemented. When I check the memory using Instrument it was showing 3.66 MB . Wondered why it is taking so much of RAM as there is nothing much heavy in app.

  2. When I have added UIImageview with the Image having size of 25 KB,then Memory uses go to 4.24 MB
    [ I come to know the reason behind is "image is unpacked 320*480*4 = 580 KB" but need to debug more on this & it remains in cache ]

Along this I have also observed two scenarios

  1. When we uses api [UIImage imageNamed:aName] for loading image, then calling [UIImageview release] doesn't have any effect.

  2. But When we use

[UIImage imageWithContentsOfFile:[[NSBundle mainBundle] pathForResource:aName ofType:nil]];

Some memory is cleaned up when I call [UIImageview release]

In my app , I am going to use lot of images and that will cause a low memory and will crash the app.

Please provide me some ref or path to analyse why this behavior.

Thanks,

Sagar

A: 

Images, loaded with imageNamed, are cached in memory by UIKit, and images, loaded with imageWithContentsOfFile are not.

Nickolay O.
then how to implement a scenario where "UITableView will have cell with Images in it and that Table is released when we terminate the app" e.g list of Online and Offline users in Chat like application.
Sagar Mane
If you need to load predefined icons, or small amount of images, use imageNamed. If all images are different, and there is a lot of them (so they doesn't fit to memory) (i.e. avatars, or so on), better dynamically load them in cellForRowAtIndexPath:, and release in [cell rellease] handler.However, this will affect performance.
Nickolay O.
Thanks Nickolay for quick response. it seems with current tool if you are implementing such kind of app with lot of images holding, then there is lot of possibility to move in low memory. this implementation conflicts with reusebility.
Sagar Mane
A: 

Trying to fit your app in memory is a losing game. It'll lead you down weird paths of trying to figure out which sort of device you're running on, swapping in and out resources based on that, etc, etc.

The better option is to design your memory structure for ditchability, and then support a fairly harsh ditching regimen when you're notified of low memory conditions. Go ahead and use memory--it's there for that--and let the low memory warning be your signal to prune out unused resources.

A lot of people seem to feel bad that their application generates memory warnings. That's silly. The design pattern here is, eat all you want, but respond appropriately when you're told you're overweight. Given you're running on a broad range of devices with a broad range of memory profiles (an iPhone 3G has 1/4 the RAM of an iPhone 4 for instance), the best way is just to be sensitive to when you've filled memory.

The main hurdle you'll encounter is recovering from having ditched data. I find what works best is to explicitly set UIImage objects to nil, and then test for nil before using them, reloading them from the bundle or the network or whatever if necessary.

All that said: [UIImage imageNamed:] supports ditchability, but you don't have control over it. When a UIViewController subclass gets a memory warning, it will ditch cached UIImages that you've created with that method, but nothing you can do will make them go away until then. Even assigning a tiny something to the UIImage in question won't help because it's cached associated with the "name" that it's "Named", not the object that it is assigned to. So that method is good for images you're going to reuse a lot, but even so, it will get pruned when the time comes, and you need to respond appropriately.

Dan Ray
Thanks Dan for this detail explanation.Need to work when we receives memory warning to avoid any weird behavior.
Sagar Mane