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.
Related
I have made an iOS Swift application with some ViewController(s) that are not entirely finished, so I haven't provided methods for them to be presented yet.
Is it safe to leave these ViewController(s) unreachable?
Xcode will display a warning stating that the ViewController is unreachable in the Storyboard, but since it is only a warning, it doesn't affect the build process.
Also...
Do I risk getting my app declined by Apple if some ViewControllers are inaccessible?
Is it safe to leave unreachable ViewControllers (I mean, will it cause any crashes or bugs?)
I want to avoid getting rid of the ViewControllers because I will need it in the next version.
Does this differ from leaving unreachable XIBs, and leaving unreachable Swift files that hold the class for the ViewController?
A view controller in the storyboard has effectively no overhead at runtime unless it is actually loaded, at which point it is turned into an instance. It occupies a pair of nibs (one for the view controller, one for its view), which take up some space in the built app; but the runtime never even bothers to look for those nibs if you do nothing that loads the view controller's nib.
A code file for a view controller that is never instantiated has effectively no overhead at runtime. It has some overhead at compile time because the code has to be compiled, so it adds a small amount of time when you build. The compiled code takes up a tiny amount of space in the binary.
Thus I think you can conclude there is no downside to what you're doing.
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'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");
}
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.
I am trying to reduce memory usage in my app, and analysis with Instruments shows that a UIView drawLayer:inContext: is allocating 2.25 MB. I assume the allocation is done right before my code is called, and is due to an incorrect UIView or CALayer size somewhere. But none of my code is involved in the allocation (see picture below), therefore I have no idea how I can debug this. I have already checked all my views and layers, I think, and I do not see anything wrong.
Any ideas are appreciated!
Don't worry. The system is allocating a backing store for the layer which happens to be 640 * 960 * 4 bytes.
If you don't leak the layer or view, you'll get your bytes back eventually, at the moment your view is unloaded.
iOS apps don't just suddenly crash when they run low on memory -- they unload unneeded views and send memory warnings to the view controllers. If your app's crash seems to be related to memory, make sure that you're handling low memory situations properly: implement -didReceiveMemoryWarning and -viewDidUnload to get rid of data you don't need.
Views can use a lot of memory. UIViewController will release its view when it needs to, but if you have another strong/retained pointer to the same view, the functionality that your view controller inherits won't know to release that, and the view will never be deallocated even though it's not needed. It sounds like this may be what's going on in your case, since it's a large block of memory that's about the right size for a full-screen view. Look at your view controllers for additional pointers to your view controller's view (or any other view) and make sure that you set such pointers to nil or release them (depending on whether you're using ARC or not).