This part of my blog is dedicated to the memory management tips for iPhone application development. In this article I have tried to explain the things I have learnt during my iPhone application development. Any update or comment is highly appreciated.
First of all we start with the simple and most common question,
“How much memory an iPhone application can allocate?”
There is no exact answer to this question because the memory an iPhone application can allocate entirely depend on the current memory state of the iPhone. The most common scenarios are as follows:
- If you have just restarted your iPhone i.e. it’s a fresh reboot then you will be able to allocate approximately 35-40 MB before you receive the memory warning.
- Installing an application in your iPhone through Xcode is a big task and it takes a lot of memory. So after installing the application on the device It is more likely to happen that you will not be able to allocate memory more then 20-25 MB.
- The amount of memory you can allocate also depends on the background processes currently running. And if there are memory leaks or extensive object allocation in those processes then your application will not be able to get much memory.
So the lesson we have learnt so far from the previous question is that we have to build our application with as much memory optimization as we can. To do this you can follow the following tips.
By resources I mean the images, Nibs, Web pages and sounds etc. As you load a resource in your iPhone application, iPhone caches that resource in the memory so that next time it loads quickly. So if you have big resource files and you are loading them frequently then what happens is that these pile up in the memory and become the reason of your application crash.
· Avoid use of imageNamed: For images we mostly use the imageNamed: message to load the image. I agree that its very easy to use but what when you load your image using the imageNamed: message, the iPhone caches that image into the memory. So you should only use this message in specific scenarios when you really need image caching, Otherwise you can use the following method to load the image.
-(UIImage *) myImageLoader:(NSString *) filename
NSString *imageFile = [[NSString alloc] initWithFormat:@"%@/%@",
[[NSBundle mainBundle] resourcePath], filename];
UIImage *image = nil;
image = [[[UIImage alloc] initWithContentsOfFile:imageFile] autorelease];
You can use this method in the same way you use ImageNamed:
· Nibs: When you create a view using the interface builder and load that nib using a UIViewController sub class, all the objects in that view are loaded and all the resources associated to that view are loaded. When you add this view to superView, the retain count of this view is incremented. And when this view is removed from its superView then this view is released and all the objects in it are also released.
When you bind an object in your code with the object in the Nib (using IBOutlet), then it becomes your responsibility to make sure that the object you have binded is released when your view is released. To do this:
1. If you have not defined this IBOutlet as property and have not synthesized it then you have to release this object in the dealloc of your ViewController. Otherwise this object will remain in the memory when your view is removed from the superview.
2. If you have defined this IBOutlet as a property using assign then you have to synthesize it also. Now this object will be automatically released when your view is removed from superview.
3. If you have defined this IBOutlet as a property using retain then you have to synthesize it also and release it in dealloc of your ViewController. Now this object will be released when your view is removed from superview.
In iphone SDK you find static methods with some classes to create an instance of that class. For Example:
[NSString stringWithString:@”Hello Sami”]
When you create an object using these static messages, The object is added in the autorelease pool that is created in the main() function of your application. Using these static functions to create the objects is not reliable because most of the objects remain in that autorelease pool until your application terminates.
I hope you find this post interesting and of use. I will post more information on this topic soon.