I do not clean up singleton objects that live the life of the application in the dealloc. Is there any reason I should?
- (void) dealloc
{
// never deallocs
[super dealloc];
}
I'm kind of assuming that the iOS has me sufficiently walled off to clean all of my app's memory up when it ends. Is that right?
Yes, when your app is terminated, your app's virtual memory address space will be completely wiped/freed. You can fill out -dealloc if you want, but it will never get called, so the only advantage to doing so is that if you decide to make your object a non-singleton down the track, you've got the dealloc method there already.
One thing to keep in mind is that any singleton (which will exist for the entire life of your app) that has any kind of cache that could reach a large size should register for the UIApplicationDidReceiveMemoryWarningNotification, and reduce or flush the cache as appropriate when a memory warning occurs.
Related
I am getting a bit confused. I am creating an app with storyboard, and running it on iPad 1. the application uses a lot of memory, so reached the 120mb, crashes. accordingly to what I have understood to remove this problem you need to release, dealloc... the point is that with ARC this should be automatic. In fact if I add for e.g.: [label1 release]; it gives me an error. But this ARC automatic release and dealloc does not seem to work! Is this because there are different ways to release with ARC??
You don't need to manually retain/release/autorelease with ARC. However if you have active references to a lot of unused objects they will still remain in memory. Profile your app with Instruments and it will show you how many objects you're creating of each class and how much memory they're consuming.
With ARC you still need to think about memory usage you just don't need to worry as much about memory leaks.
NSObject *bigMemObj = [[BigMemClass alloc] init];
//This creates the object in memory. In both arc and manual counting the retain count is 1
//Do stuff
//Prior to ARC you would have had to call [bigMemObj release]; before setting the variable to nil
bigMemObj = nil
//With ARC you don't have to do anything. The compiler inserts the release at compile time
Also read the documentation on declaring iVars __strong vs __weak.
Without looking at your code it's hard to identify what is consuming all the memory but hopefully that should help you determine where to start looking.
You should implement #autoreleasePool{} inside each method. In essence, each method will look like the following:
-(void)methodName{
#autoreleasePool{
//do method stuff
}
}
This will ensure that, upon exiting the autoreleasePool, memory is properly released.
I can't vote this back up, otherwise I would. I think Alessandro is asking about ARC vs using release and dealloc, not about what he's loading!
So, Alessandro, your understanding is correct that with ARC you don't release or dealloc. Therefore, those won't work if you're using ARC. Also, there is no alternative to release/dealloc, since ARC doesn't use it.
My suggestion would be to look at what you're using in the app that is taking up all this memory. Do you have a large number of pictures, for example, that are very large? Keep any graphics as small as possible, matching the resolution of the iPad. Especially the iPad 1, which doesn't have the "retina display".
You can use Autorelease pools in ARC. Here is some documentation on when to use them:
NSAutoreleasePool Class Reference
Advanced Memory Management Programming Guide: About Memory Management
My Question is When the dealloc method will cal before the application termination, If it happens , When the application terminates all the memory of the objects and application will be removed from memory, then what is the use of writing dealloc method?
This is a general question about memory management. You use dealloc in Objective-C, free in C etc. to clean the memory allocated for the variables that are no longer in use. When the application terminates of course all of the memory allocated by the application will be released. However, if your application keeps allocating memory as it runs, and if the user runs the application for long enough, unless you release unused memory, the device's memory would get eventually used up. This is why you need to use dealloc.
The dealloc method describes how the object will be released. When an object is being deallocated unless you override the dealloc method only the object's pointer will be released. Therefore, in order to release properties and fields in your object you need to manually release them in your dealloc method.
I use code like the following (inside my appController.m for example) to do some cleanup when my application terminates...
- (void) dealloc {
[myObject release]; // myObject 's dealloc will not be called either !!!
[arraySMSs release];
[super dealloc];
}
This method never get called when the app quits! Why ? Is there a better place to do my clean up ? The fact that is not called addresses memory-leak issues ? Or the OS does take care of clean up ?
Thank you...
There is no reason for the system to ensure that every object is individually deallocated upon application termination.
Doing so is just a waste of CPU cycles and a waste of the user's time.
When an app is terminated, all resources used by that app are reclaimed by the system in an entirely automatic and unavoidable fashion.
If you need something to happen at app termination, use the application delegate's hooks for doing so. But don't rely on that. A user may force reboot a device or force quit an application at whim.
Here's the quote from NSObject Reference:
"Important: Note that when an application terminates, objects may not be sent a dealloc message since the process’s memory is automatically cleared on exit—it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods."
It pretty much confirms what many people have said.
nice question, i was confused too.
now i got this:
Said that there's no object managed by our custom code that owes the appDelegate class itself, we don't really need to worry to "release" its instance.
UIApplication is the only class that retain it, but we don't owe it.
But, for academic discussion or if there's any purpose i don't know at the moment,
when you wanna test the dealloc in your appDelegate class:
applicationWillTerminate is the right place to know if your app is going to quit.
- (void)applicationWillTerminate:(UIApplication *)application
{
// Called when the application is about to terminate. Save data if appropriate. See also applicationDidEnterBackground:.
[UIApplication sharedApplication].delegate = nil;
// after this, the dealloc method of our appDelegate class will be called
}
What makes you think dealloc is not being called? Have you run this is the debugger? Please see this question for why you won't necessarily be able to call NSLog in the dealloc method: when is dealloc executed?
Where is the best place to invoke removeObserver:name:object: since the dealloc method does not always be executed as mentioned in NSObject class reference ??
If you're referring to this note:
Important: Note that when an application terminates, objects may not be sent a dealloc message since the process’s memory is automatically cleared on exit—it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods.
It says dealloc is typically not guaranteed to be called only on application termination. So even if dealloc isn't called, the resources used by your application will still be cleared by the OS. That means all your objects will be gone anyway because your application isn't there anymore.
Therefore, the best place to remove a notification observer from the notification center is still within the observer's dealloc method.
I inherited an iPhone app at work and I'm new to Objective-C so I don't have my bearings just yet. I encountered code similar to this:
- (void) dealloc {
[[StaticObject sharedObject] showSomeDialog];
[super dealloc];
}
I know this is frowned upon in other languages. My spider sense is going crazy looking at that code.
Is this a common Objective-C idiom? Or do I have a crappy codebase to fix?
You should not put UI code in a -dealloc. General rule of thumb, only use -dealloc to clean up what you've done: release objects, remove observers, etc.
Consider what would happen if this object lived on a thread other than the main thread... now you'd have UI code running on the non-main thread, which is a bad thing.
You can do such thing for some debugging reasons. But I don't think you should ever do anything like this!
This means a dialog is prompted when an object is being deallocated. So if you need any mechanism to show a dialog at a certain time don't make it depended on an object being deallocated.
In the dealloc method you should really just release all objects retained by the deallocated object. And not doing some fancy application features.