I have two view controller in swift "A" and "B". Let I have some variable in A. So after initialization, it stored in Memory area. Then what happen, when I moved to B view controller. The memory gets released or still there in the memory space ?
As long as view controller A is still present in the view controller hierarchy, it will still be strongly referenced and any variables that it strongly references will still be in memory.
If you had previously presented A and then dismissed it, then A and its variables would potentially have no strong references and would no longer be in memory.
Related
I have added multiples UIViews on outside of UIViewController and all views have week outlet connected. How can i Release memory of all view when pop to back ViewController.
First: Views (or other objects) on the top level of a xib should not have a weak kind of property in their corresponding view controller. Unlike view's in the view hierarchy, they don't have an owner after the xib is loaded and so they get deallocated anyway.
Now you seem to use ivars directly (why?), so I am actually not sure, but I don't think that makes a difference. Assuming Interface Builder accepts those as outlets and sets them, they're gone soon without an owner.
From that point of view, you've already saved memory...
Without knowing more about your project I can't tell, but the fact you're not asking for help on running into nil problems makes me guess you're taking ownership of these views somewhere else. To free them, you need to set whatever property (you are hopefully soon using properties for this) refers to them strongly to nil. ARC does the rest for you. Not using ARC? Start using it...
I would recommend to restructure this. Give the view controller (I guess that's some kind of FirstFlyerViewController) strong properties to the views (if you definitely need to have them outside the view hierarchy, otherwise, just add them as subviews somewhere). Use them, and once you pop the view controller and it gets dealloced (note that this is usually done by the framework and not yourself) they get freed along with it.
I have added two view controllers before moving to split view controller. In split view controller as the details controllers are changing, memory usage is increasing according to newly allocated view controller memory usage. But, Previous Detail View Controllers' memory are not automatically released by ARC. In simulator I have checked with simulated memory warnings, but ARC never releases those unused view controllers' memory. Due to increasing memory usage app crashes.
I checked splitViewController.viewControllers array and inner array but never find out unused details view controllers' instance.
I have tried with #autorelease block. It didn't work.
Please get me out of this nightmare.
I have view controllers that aren't be released from memory after a pop and I can't seem to zero-in on the pointers that are keeping them alive. How can I see what pointer variables are pointing to my view controller(s)?
I have an application where the user can push infinitely deep into views (pushing onto nav stack). At some point, there will be a memory warning. I'd like to remove view controllers from the navigation controller and dealloc them. If the user goes back to those view controllers, I'd like to recreate the view controllers and push them back into the correct position in the stack.
Is this the right way to be thinking about this problem?
Is there an open source project that does this? It doesn't seem like an uncommon issue and I'd rather not reinvent the wheel.
There was a time where you needed to make sure that calls to viewDidLoad and viewDidUnload matched properly so that memory warnings could be handled this way. Since iOS 6 this is no longer necessary.
As it says in the documentation for viewDidUnload:
In iOS 5 and earlier, when a low-memory condition occurred and the
current view controller’s views were not needed, the system could opt
to call this method after the view controller’s view had been
released. This method was your chance to perform any final cleanup. If
your view controller stored separate references to the view or its
subviews, you could use this method to release those references. You
could also use this method to remove references to any objects that
you created to support the view but that are no longer needed now that
the view is gone. You would not use this method to release user data
or any other information that cannot be easily recreated.
In iOS 6 and later, clearing references to views and other objects in
your view controller is unnecessary.
If you're manually keeping large objects in memory, such as image or video data, then you can override didReceiveMemoryWarning to release those objects where necessary.
A colleague and I have been designing our code so that our view controller objects are being allocated within the viewDidLoad method of our controller objects. We did this a lot and the object graph seemed to come out just fine. After a while we found the need to add another layer above our current view controller hierarchy that would own, allocate, and release our previous parent view controller.
This got me thinking about low memory warnings and view did load. Before, our views were always visible and thus wouldn't be released if a low memory warning occurred, but now there is a chance of that happening. If it does, it seems like when the views are reloaded, they will allocated new memory for new view controllers.
Will this cause widespread memory leaks? Or will the fact that we used retained declared properties save us, since the old controllers will be released automatically? Are there styles or conventions I should consider? Thanks for the help!
If you do create your view controllers in viewDidLoad, you should release them in viewDidUnload. True for pretty much any object, not just view controllers.
But I would not be surprised if you say "Wut!?" If your view controllers need to keep their state through memory warnings, then you don't want to release them. But it will be no better if you replace them with new ones that have fresh state.
It probably doesn't make sense to create view controllers in viewDidLoad. Create them in initWithNibName:bundle: (and release them in dealloc). The design pattern is that view controllers stay around, their views can come and go. If your subordinate view controllers have anything memory-intensive, release just that object in their viewDidUnload. Then on a memory warning, you will still free up a lot of memory, but all your view controllers will stay around in a low-memory usage state, retaining only a few flags, lists of indexes, etc., that they will need to restore their views when requested.
If you are explicitly releasing each view controller that is not needed any more you will not cause any memory leaks. Usually when you present a view controller the object that is doing the presenting will retain the controller for you, so you can release it if you don't need access to it anymore. But if you are using a UINavigationController and you are pushing new view controller's then you should be implementing the viewDidUnload method. This is straight from Apple's documentation:
After it is loaded into memory, a view controller’s view remains in memory until a low-memory condition occurs or the view controller itself is deallocated. In the case of a low-memory condition, the default UIViewController behavior is to release the view object stored in the view property if that view is not currently being used. However, if your custom view controller class stores outlets or pointers to any views in the view hierarchy, you must also release those references when the top-level view object is released. Failure to do so prevents those objects from being removed from memory right away and could potentially cause memory leaks later if you subsequently overwrite any pointers to them.
There are two places where your view controller should always clean up any references to view objects:
The dealloc method
The viewDidUnload method
If you use a declared property to store a reference to your view, and that property uses retain semantics, assigning a nil value to it is enough to release the view. Properties are by far the preferred way to manage your view objects because of their convenience. If you do not use properties, you must send a release message to any view that you explicitly retained before setting the corresponding pointer value to nil