I'm having a problem with a view controller that's dismissed and not referenced but still in memory, just wondering in general when is the object actually released in memory when no one references it?
The way I used to test is that I installed the PVC tool from Facebook and use it to print out the view hierarchy when the view controller is presented, after it's dismissed, I make sure no one's referencing it and paused the execution so I can po the memory address of the view controller from the previous PVC tool, but I can still see the view controller instance there.
Thanks!
You appear to be confusing being released and being cleared from memory. When the class is destroyed, the memory it occupied is not zeroed, just like when you delete a file in the filesystem, the disk blocks are not zeroed either.
This would simply take up too much time and have very little benefit.
Being released simply means the memory the class occupied can now be re-used.
One way to see if the class has been destroyed is to add a log in the dealloc method:
- (void)dealloc
{
NSLog(#"I'm being destroyed");
}
Related
I just spent an hour trying to fix a retain cycle in my code. It was basically the view controller not getting deallocated after dismiss.
However, when I was using Instruments to check for memory leak, it passed every leak check. Please see the image below.
The problem was when I declared the class protocol, I forgot to mark the delegate as weak...But how come Instruments failed to notice this retain cycle?
I'm quite new to Memory management, if my question is dumb, please understand. Thanks. :)
Instruments detect leaks in fairly simple way - if there are no references leading to the root components (say Application Delegate) from an instance, it means that the instance and all instances retaining it are a memory leak, just like Garbage Collector. So if, say, your parent ViewController merely retains another ViewController (which should have been released getting back), and the parent ViewController is still retained itself by any class that is in chain of references to the root components, it is not considered leak.
I have a quick question- does it matter if the memory that is used by an app while it is running increases slightly (0.1mb) every single time a view controller is loaded? I have a game which has an infinite level, and if the player loses the view controller basically refreshes (e.g. all timers invalidated) and the main menu controller is loaded. Then every time the infinite level is restarted, the memory (shown in the debug navigator) goes up. So the first time the level is played it is 226 mb, the second it is 226.2 mb, third it is 226.4 mb etc. Is this a problem?
What is probably happening is that there are a few strong references to Views/iVars/Properties still left dangling when you release your infinite level view controller (by dismissing/removing from superview). Try to release all your properties and instance variables just before you release your view controller. You could also try to define all your IBOutlets (which don't get removed from the view) as Weak type, so they get released when the view controller is dismissed.
Some points you can remember as a checklist for memory management:
Any property/variable with a strong/retain type should be released by the user. ARC does it automatically, but sometimes it does not release correctly (Don't ask why).
Instance variables are by default a "Strong" reference type, which means you have to release them manually
IBOutlets that remain in the view and you don't removeFromSuperview, can be of weak type, since the view holds a strong reference to it.
(if you do not have ARC on) Make sure that you have an NSAutoReleasePool block so that it releases all local variables, thereby preventing memory leaks.
Your problem, while not serious at the moment, could become serious quite soon. The average iPad/iPhone starts giving memory warnings around 300 MB, so if you start adding any more features to your game, this could become a big problem.
Hope this answer helps.
I have a UITableiew listing n number of contacts and from Table view delegate didSelectRowAtIndexPath I am navigating to a 'Contactview' UIViewController by using UINavigationController pushviewcontroller.
For an instance if I navigate the first contact to Contactview, Live Bytes memory goes up from 1 MB to 3 MB. Then when I tap on the back button the viewcontroller delloc method is called but the memory still stay around 2.95MB to 3MB . My question is when the viewcontroller delloc method is called the memory of the viewcontoller should be released right ? Am I wrong anywhere ? Please suggest me if I am wrong. And I am using ARC project.
Thanks in Advance..
If you push your navigation back and forth and you see memory climbing unlimitedly, you have a memory management problem. Even with ARC, you may have abandoned memory. You can detect it using the Allocations template in Instruments.
In Instruments, put the application in a well-known starting state (for example, showing the table view).
Click Mark Heap button under Heapshot Analysis.
Navigate your controller back and forth once.
You will see a small increase in memory usage in the allocations graph. This is normal, internal caches may be storing some information.
Click the Mark Heap button again.
You will see a number of objects in the Still Live column.
Repeat steps 3-6 many times and see if there are "still living" objects after every iteration.
If there is an almost constant number of still living objects in each heapshot, click the right arrow button in one of the heapshots and you will see all the objects that are still living. Look for objects probably created by you, select one, expand it, and select its memory address with a simple click. Then click the Extended Detail button to see a stack trace showing where the object was allocated. With this code context I'm sure you will understand why your memory was abandoned.
See.. one thing ARC will release it the contents some where in future right.Its Automatic right.. how can expect the ARC to do the Gatrbage collection after class will disappear.It might take time to free the memory.
Did you check retainCount? is that showing your desired value?
UIImage caches images for you as an optimisation, so this is expected behaviour.
If you wish to confirm that this is the case, for peace of mind, you can force a low memory warning (Under the Hardware menu for the simulator). This should get UIImage to throw out its cache.
You can also use this private method, but of course throw it out before submission.
[[UIApplication sharedApplication] performSelector:#selector(_performMemoryWarning)];
You might own a strong reference for the view controller elsewhere in the code. You should be sure if it's really deallocated... If any other object has reference to it beyond the navigation controller it won't be deallocated. Try override dealloc. (You could override dealloc in an ARC project as well, you are only not allowed to use retain count manipulation calls.) To be sure if dealloc is called put some logging or something debugable code into that method.
When memory is low and views get cleaned up by the OS, my understanding is that viewDidUnload is an appropriate place to clean up objects and memory used by your UIViewController (that otherwise wouldn't get cleaned up as a function of being in the view hierarchy). This data is then re-initialized when loadView is called again to create the view. Can someone give examples of what sort of things might be cleaned up (and likewise initialized in loadView)?
I have some data I initialize in loadView currently which sets the stage for my view controller to run a complex animation script involving captions, images, etc. I figured it would make sense to release and cleanup that data if my view were to be removed by the OS (and viewDidUnload were called), but then I thought to myself, why wouldn't I just initialize that data within init and clean it up in dealloc instead of repeatedly initializing and cleaning up the same data (it doesn't change as a function of when the view is loaded or shown). Would this be a better place for it?
Basically, my thinking is:
yes, i should just initialize it in init and release in dealloc because it never changes
initializing things in loadView (and subsequently cleaning in viewDidUnload) is an appropriate practice when either that data will initialize differently based upon when the view is loaded (or even more appropriately when the view appears in viewWillAppear/viewWillDisappear) or it is a good candidate for freeing memory because it takes up a lot of memory that you'd like to see freed up if the view is not active.
Can anyone give me some clarification on my questions and/or my line of thinking?
if you're going to be going back and forth between that view and another and the viewcontroller will be kept around, you could indeed move the initialisation to init, and clean it up in dealloc. but what you would want to do is also clean it up in - (void)didReceiveMemoryWarning (be careful not to use self.view in didReceiveMemoryWarning otherwise that'll reload the view :) ). then you could use lazy loading to reload it in viewDidLoad (i.e. if it doesn't already exist then initialise the data, otherwise don't).
of course, you can't do any initialisation in init that depends on the view being present.. viewDidLoad is the place for that.
When my iPhone app receives a memory warning the views of UIViewControllers that are not currently visible get unloaded. In one particular controller unloading the view and the outlets is rather fatal.
I'm looking for a way to prevent this view from being unloaded. I find this behavior rather stupid - I have a cache mechanism, so when a memory warning comes - I unload myself tons of data and I free enough memory, but I definitely need this view untouched.
I see UIViewController has a method unloadViewIfReloadable, which gets called when the memory warning comes. Does anybody know how to tell Cocoa Touch that my view is not reloadable?
Any other suggestions how to prevent my view from being unloaded on memory warning?
Thanks in advance
Apple docs about the view life cycle of a view controller says:
didReceiveMemoryWarning - The default
implementation releases the view only
if it determines that it is safe to do
so
Now ... I override the didReceiveMemoryWarning with an empty function which just calls NSLog to let me know a warning was received. However - the view gets unloaded anyway. Plus, on what criteria exactly is decided whether a view is safe to unload ... oh ! so many questions!
According to the docs, the default implementation of didReceiveMemoryWarning: releases the view if it is safe to do (ie: superview==nil).
To prevent the view from being released you could override didReceiveMemoryWarning: but in your implementation do not call [super didReceiveMemoryWarning]. That's where the view is released by default (if not visible).
The default didReceiveMemoryWarning releases the view by calling [viewcontroller setView:nil], so you could override that instead.
What appears to be working for me was to override setView: to ignore setting to nil. It's kludgy, but then, this is a kludgy issue, and this did the trick:
-(void)setView:(UIView*)view {
if(view != nil || self.okayToUnloadView) {
[super setView:view];
}
}
Could it be so simple?
Even though nowhere in the documentation this is mentioned, it seems that if I exclusively retain my view in viewDidLoad, then it does not get released on Memory Warning. I tried with several consecutive warnings in the simulator and all still seem good.
So ... the trick for the moment is "retain" in viewDidLoad, and a release in dealloc - this way the viewcontroller is "stuck" with the view until the time it needs to be released.
I'll test some more, and write about the results
I don't think any of these ideas work. I tried overriding [didReceiveMemoryWarning], and that worked for some phones, but found one phone unloaded the view BEFORE that method was even called (must have been in extremely low memory or something). Overriding [setView] produces loads of log warnings so I wouldn't risk that by Apple. Retaining the view will just leak that view - it'll prevent crashes but not really work - the view will replaced next time the controllers UI is loaded.
So really you've just got to plan on your views being unloaded any time they're off-screen, which is not ideal but there you go. The best patterns I've found to work with this are immediate commit so your UI is always up-to-date, or copy-edit-copy, where you copy your model to a temporary instance, populate your views and use immediate commit with that instance, then copy the changes back to your original model when the user hits 'save' or whatever.
Because the accepted solution has problems with viewDidUnload still getting called even though the view was blocked from being cleared, I'm using a different though still fragile approach. The system unloads the view using an unloadViewForced: message to the controller so I'm intercepting that to block the message. This prevents the confused call to viewDidUnload. Here's the code:
#interface UIViewController (Private)
- (void)unloadViewForced:(BOOL)forced;
#end
- (void)unloadViewForced:(BOOL)forced {
if (!_safeToUnloadView) {
return;
}
[super unloadViewForced:forced];
}
This has obvious problems since it's intercepting an undocumented message in UIViewController.
progrmr posted an answer above which recommends intercepting didReceiveMemoryWarning instead. Based on the stack traces I've seen, intercepting that should also work. I haven't tried that route though because I'm concerned there may be other memory cleanup which would also be blocked (such as causing it to not call child view controllers with the memory warning message).