My sample code like this (just a sample):
[self.view touchActionWithCompeletion:^(NSSting *text){
self.label.text = text;
}];
The block is a parameter of a method, the method is a instance method of self.view, then I access self in block. If self.view is a strong property, will this situation create retain cycle? And will self.view strong reference the block?
Adding my comment above as answer, after testing the code myself to confirm the logic I mentioned,
I think it should not, dead lock ( I mean memory leak, two strongly held objects holding the reference to each other and never being de-allocated hence I mentioned deadlock) will happen only if you pass a strong reference of an object to the block (in this case self) and then the passed object holds a strong reference to block itself (directly or indirectly).
Hoping that method touchActionWithCompeletion will not save the block passed to it with a strong reference this should not result in a retain cycle
EDIT:
Tested your code and deinit gets called as expected.
Here is what I tried,
class MyView : UIView {
func touchActionWithCompeletion(block :(NSString)->()) {
block("abcd");
}
}
class ThirdViewController: UIViewController {
var myViewInstance = MyView()
#IBOutlet var c: UITextField!
override func viewDidLoad() {
super.viewDidLoad()
self.myViewInstance.touchActionWithCompeletion { (abcd) in
self.c.text = abcd as String
}
}
deinit {
print("deinit called")
}
}
As expected deinit called.
Only thing to notice here, method touchActionWithCompeletion will not store the block passed to it with strong reference. It simply executes it. So my answer above holds true in this case.
EDIT 2:(Clarifying my statement in answer)
I happened mention the passed object holds a strong reference to block itself (directly or indirectly) I guess I need to explain why I mentioned indirectly.
Consider this case, Deadlock will happen if View holds a strong reference to the block passed to its method. Though the strong object passed here to the block is self and self does not hold the reference to block directly, it still result in deadlock if View holds a strong reference to block.
Reason Self - holds a strong reference -> View - holds a strong reference -> Block - holds a strong reference -> Self
Hence deadlock. Though self does not hold the block directly, because it holds the block indirectly, hence deinit on self will not be called. Hence I happened to mention the passed object holds a strong reference to block itself (directly or indirectly)
Hope it helps
Related
Say I have a UITableViewController subclass which has some function in it, eg:
class MyTableVC: UITableViewController {
func doSomething() { ... }
}
and I add a function to it that calls performBatchUpdates with a completion handler which captures self:
func updateStuff() {
tableView.performBatchUpdates(someUpdates, completion: { _ in
self.doSomething()
}
}
Is there a danger of creating a retain cycle? If so, is the view controller guaranteed to be non-nil in the callback? i.e. If there's a possibility of a retain cycle, can I use [unowned self] or is it necessary to use [weak self]
There is no major issue in your solution. self will only be retained until the completion of batch update which is fine. And I'd probably do the same not to complicate the code.
Regularly it is a bit better to still have weak or unowned just to maintain similar code style through your project.
If you decide to pick one of these, weak is the only safe option here. For example, the view controller can be removed from the screen and deallocated while the table performs the update operation (the chance is really tiny but still exists) which will cause a crash in the result.
A function on a UIViewController declares and initializes a reference to a class object. That class has a weak delegate ref. which has been set to the UIViewController. After this function finishes execution the object gets deallocated and its no longer calling the delegate methods.
func registerDevice() {
prepareForLoading(true)
let notificationModel: NotificationModel = NotificationModel(delegate: self)
notificationModel.registerDevice()
}
Is there a way to keep this object alive until the UIViewController dies, without having a global class ref. on the UIViewController to it. This is important because there isn't any use for this object in any other function or in any other situations.
Since you are declaring notificationModel as a constant within the scope of the registerDevice function, the lifetime of that object is limited to that function in the absence of any other strong reference being held.
You say "there isn't any use for this object in any other function or in any other situations.", but this isn't correct; Since your view controller implements delegate functions for this object and you expect those delegate functions to be called, your view controller needs to take responsibility for keeping the model object in memory.
It can do this by simply declaring an instance property
var notificationModel: NotificationModel?
and assigning the object to that property in your function:
func registerDevice() {
prepareForLoading(true)
self.notificationModel = NotificationModel(delegate: self)
self.notificationModel!.registerDevice()
}
Now the lifetime of your model object is (at least) the lifetime of your view controller.
Note, that this property is not a class property or a global; it is scoped to the specific View Controller instance.
I am trying to grasp how I can recognize when a strong retain cycle is possible and requires me to use [weak/unowned self]. I've been burned by unnecessarily using [weak/unowned self] and the self was deallocated immediately before giving me a chance to use it.
For example, below is an async network call that refers to self in the closure. Can a memory leak happen here since the network call is made without storing the call it self into a variable?
NSURLSession.sharedSession().dataTaskWithURL(NSURL(string: url)!) {
(data, response, error) in
self.data = data
)
Here's another example using the NSNotificationCenter, where a call can be made later asynchronously:
NSNotificationCenter.defaultCenter().addObserverForName(
UIApplicationSignificantTimeChangeNotification, object: nil, queue: nil) {
[unowned self] _ in
self.refresh()
}
My question is in what cases is a strong retain cycle possible? If I am making an asynchronous call or static call that references self in a closure, does that make it a candidate for [weak/unowned self]? Thanks for shedding any light on this.
A retain cycle is a situation when two objects has a strong reference to each other.
You are working with static variables NSURLSession.sharedSession() & NSNotificationCenter.defaultCenter() and as you may remember:
A singleton object provides a global point of access to the resources
of its class...You obtain the global instance from a singleton class
through a factory method. The class lazily creates its sole instance
the first time it is requested and thereafter ensures that no other
instance can be created. A singleton class also prevents callers from
copying, retaining, or releasing the instance.
https://developer.apple.com/library/ios/documentation/General/Conceptual/DevPedia-CocoaCore/Singleton.html
Your "self" instance (like the others) doesn't have a strong reference to singletons objects and its closures too, that's why you don't have to worry about retain cycle in your case.
Check this great article for more details:
https://digitalleaves.com/blog/2015/05/demystifying-retain-cycles-in-arc/
In a nutshell:
The retain cycle can happen in two cases.
Case 1:
When two instances hold a strong reference to each other. You have to solve this by marking one of them as weak.
Case 2: (Which is related to your questions)
If you assign a closure to a property of a class instance and the body of that closure captures the instance.
In your two examples, no need to use weak self at all as NSNotificationCenter nor NSURLSession are properties to your class instance. (Or in other meaning, you don't have strong references to them)
Check this example where I have to use weak self:
[self.mm_drawerController setDrawerVisualStateBlock:^(MMDrawerController *drawerController, MMDrawerSide drawerSide, CGFloat percentVisible) {
if (drawerSide == MMDrawerSideRight && percentVisible == 1.0) {
[weakself showOverlayBgWithCloseButton:YES];
}
else{
[weakself hideOverlayBg];
}
}];
I have a strong reference to mm_drawerController and I assign a closure to it right?. inside this closure I want to capture self. So the closure will have a strong reference to self !! which is a disaster. In that case you will have a retain cycle. To break this cycle, use weak self inside the closure.
My question is two-part:
First, Say I have a class:
MyClass.h
#interface MyClass: NSObject
-(id)initWithName:(NSString*)name;
#property(nonatomic, strong) NSString *name;
#end
MyClass.m
#implementation MyClass
-(id)initWithName:(NSString*)name
{
if (self = [super init])
{
self.name = name;
}
return self;
}
#end
My question: I know that self will hold the name property strongly. But how will the name property relate to self? What I mean is that I can access name as self.name but while class instantiation, how is the children of self (which in this case is name) related to self? I am imagining the structure of the class as a tree, with the parent holding strong reference to the children and the children holding a weak reference to the parent. I want to know if I am thinking about it correctly or not. My guess is it will be a weak relationship.
Second, if I add a method which has a block that references the name property. So my updated implementation of MyClass.m is:
MyClass.m
#implementation MyClass
-(id)initWithName:(NSString*)name
{
if (self = [super init])
{
self.name = name;
}
return self;
}
-(void)doSomeStuff
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
self.name = #"Name changed inside block";
}];
}
#end
My second question is: I am not referencing self directly inside my block. So, I guess there is no retain cycle here. But I am referencing name property which is held by self. So does this create a retain cycle?
I know that self will hold the name property strongly. But how
will the name property relate to self?
Each property will have a backing instance variable, conventionally named the same as the property with a leading underscore and a getter and/or setter method. There is no relationship; the property generally makes the class instance larger (due to additional instance variable) and the class larger (due to additional methods).
I am not referencing self directly inside my block. So, I guess there
is no retain cycle here. But I am referencing name property which is
held by self. So does this create a retain cycle?
Yes you are referencing self directly, so a retain cycle is possible. However a retain cycle can only happen under certain circumstances, and it's often just safer to avoid this by creating a weak reference to self and using that within the block.
First: The name property holds no relationship to MyClass, weak or otherwise. (That is, if you pass name to some arbitrary method, it doesn't carry any reference to the MyClass instance where it was a property.)
Second: Since you're simply executing the block rather than storing it, I don't see an opportunity for a retain cycle.
1: The MyClass instance has retained the name property, name property itself has no idea what is MyClass and therefore , there is nothing referring from String-name to the MyClass itself.
2: In the following code
-(void)doSomeStuff
{
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
self.name = #"Name changed inside block";
}];
}
self.name = #"Name changed inside block"; is the same as [self setName:#"Name changed inside block"];
So you are actually retaining MyClass instance inside Block and then executing its method to update the name , ( block needs pointer to this Name to change it , right ? block retains class object which contains this property ) , you are not retaining the property name itself.
But how will the name property relate to self? My guess is it will be a weak relationship.
The name property does not have a reference back to self, so the attributes strong and weak don't apply. An object instance is just a collection of instance variables, gathered into a struct. When we talk about object memory management, we are talking about the memory containing that struct. It doesn't make sense to say that a property (really the instance variable backing the property) has a reference to anything. It is simply one part of what self is.
My question: I know that self will hold the name property strongly. But how will the name property relate to self? What I mean is that I can access name as self.name but while class instantiation, how is the children of self (which in this case is name) related to self? I am imagining the structure of the class as a tree, with the parent holding strong reference to the children and the children holding a weak reference to the parent. I want to know if I am thinking about it correctly or not. My guess is it will be a weak relationship.
The children can have a reference to the parent and then it should be weak for the reasons you mentioned. But NSString instances does not have such an up-reference. So there cannot be a retain cycle.
In general it is up to you to manage such inverse relationship. (Core Data does it automatically in its default setters,if you insert a inverse relationship.) Nothing is done automatically, no definition of an up-reference, no setting of a up-reference.
My second question is: I am not referencing self directly inside my block. So, I guess there is no retain cycle here. But I am referencing name property which is held by self. So does this create a retain cycle?
You refer self inside the block, because you use it. Period.
But a retain cycle needs two references. As long as self is used inside the block, but the block is not stored in a property of self (directly or indirectly) no retain cycle can occur.
In Swift, we mostly use many references of classes like ,
UITableView
UIStepper
UILabel
NSTimer
UISlider and etc..
one example:
var slider : UISlider!
My question is whether we have to create all these as weak refernces by prefixing it as weak, so that ARC will not have a strong hold on it so ARC can delete it as when needed or just creating a strong reference and make it to nil at the viewDidUnload deligate ??
example :
slider = nil
To the point I actually don't know how to manually use ARC or manually handling ARC is not at all needed ?? I have no idea about this meamory handling
Pls do share if u ever came across this and found a solution...
Thanks in advance....
ARC (Automatic Reference Counting) in Swift is explained pretty well in the official documentation.
Below you can find a very simple recap of 4 important aspects of ARC.
1. Basics
ARC associates to each instance of a Class a retainCount integer.
This value represents the number of strong references to that specific instance.
When this number becomes 0 then the memory used by the instance is freed.
class Something {}
var aVariable = Something()
// now the reference counting for this particular instance of Something is 1
Now our instance of Something is keept in memory since its retainCount value is 1.
var anotherVariable = aVariable
Now we have 2 strong references to our instance of Something. Good! Its retainCount now is 2 and the instance is still kept in memory!
aVariable = nil
The retainCount has just become 1. No problem, the instance is still in memory.
anotherVariable = nil
Finally the retainCount of our instance has become 0. This means that the instance has been freed and can no longer be accessed.
2. Should you set to nil your variables when you're done with them?
Nope. Infact when a variable goes out of scope ARC automatically decrease the retainCount of the referenced instance.
In the following example, before the last } the retainCount of the instance of Something gets decreased and reach value 0 (and is freed).
func doSomethingUseful() {
let something = Something()
// ... do very important stuff here
}
So in a common scenario you don't need to set variables to nil in order to force ARC to free the referenced instance.
Another example:
class Son {}
class Father {
var sons: [Son]
init (sons: [Son]) {
self.sons = sons
}
}
func lifeGoesOn() {
let son = Son()
// here the referenceCout of the instance of Son is 1
let father = Father(sons: [son])
// here the referenceCount of the instance of Son is 2...
// now variable son goes out of scope so the reatinCount of the instance of Son becomes 1
// also father goes out of scope, so the variable father.sons goes out of scope as well, so the `retainCount` of the instance of Son becomes 0
// and so both the instances of Father and Son gets freed
}
You can see this like a domino effect. When an instance is freed, all its references to other instances are removed. So the retainCounts of the referenced instances gets decreased. And if becomes 0 they are released. And so on...
3. Retain cycles
Ok, what happen if I have 2 classes as follow?
class Son {
let father:Father
init(father:Father) {
self.father = father
}
}
class Father {
var sons: [Son]
init (sons: [Son]) {
self.sons = sons
}
}
Lets create now a reference from a father to its son and viceversa from the son to its father.
func lifeGoesOn() {
var father = Father(sons:[])
// retainCount of the instance of Father is 1
var son = Son(father: father)
// retainCount of the instance of Father is 2
// retainCount of the instance of Son is 1
father.sons.append(son)
// retainCount of the instance of Father is 2
// retainCount of the instance of Son is 2
// Now we have a problem
}
At the of the function the father variable goes out of scope so the retainCount of the instance of Father becomes 1.
Similarly the variable son goes out of scope and the retainCount of the instance of Son becomes 1.
The problem here is that the instance of Son references the instance of Father (keeping this instance in alive memory). And the instance of Father references the instane of Son. These 2 instances should not be in memory anymore. They are not accessible by the programmer since all the variable to reference them are gone.
This is a problem.
4. Weak references
When you structure your code you should pay attention to strong retain cycles. Let's how to refactor our code to fix this.
class Son {
weak var father:Father?
init(father:Father) {
self.father = father
}
}
Now the reference from a Son to its Father is weak. This means it does not count when ARC calculates the number of (strong) references to an instance. And this fix the problem seen in the previous paragraph.
I hope the subject is a little bit more clear now. There are several scenarios I did not cover. Again, the official documentation is pretty good and exhaustive.
Update (to better answer the comment below)
If you have a custom UIViewController (lets call it MyCustomViewController) and this class has a strong property to an object let's see what happen.
class MyCustomViewController : UIViewController {
var something = Something()
}
class Something {
init() { // called when memory is allocated
debugPrintln("The instance of Something has been created")
}
deinit { // called when memory is freed
debugPrintln("The instance of Something has been freed")
}
}
When you present a MyCustomViewController, an instance of MyCustomViewController is created. Then an instance of Something is created as well.
Now the instance of MyCustomViewController is referenced by the UINavigationController so has retaintCount = 1.
Similarly the instance of Something is referenced by the instance of MyCustomViewController so it has retainCount = 1.
So the instance of UINavigationController keeps alive the instance of MyCustomViewController. And the instance of MyCustomViewController keeps alive the instance of Something.
UINavigationController -(strong)-> MyCustomViewController -(strong)->
Something
Next you decide to dismiss MyCustomViewController, so iOS animates it to leave the screen. When it is no longer visible it is removed the reference from the instance of UINavigationController to the instance MyCustomViewController.
UINavigationController -(REMOVED)- MyCustomViewController -(strong)->
Something
This means that the retainCount of the instance of MyCustomViewController becomes 0 because: no one is referencing it now!
So the instance of MyCustomViewController is going to be removed from memory. In this process its properties are nulled.
UINavigationController -(REMOVED)- [free memory] -(REMOVED)- Something
Now the retainCount of the instance of Something has become 0.
So it will be removed from memory as well.
UINavigationController -(REMOVED)- [free memory] -(REMOVED)-> [free memory]
Finally, I overidden the init and deinit methods of Something so you can keep track of the allocation and deallocation of a related instance. Looking at the log (or using a breakpoint) you can verify what I said here.
Hope this helps.
If you are talking about view controller properties that are initialised by the view itself (such as UILabel or pretty much any subclass from UIView that you define in IB), Xcode will assign them as weak automatically, as the view (and not the view controller) have created the strong reference.
Most of the times you don't need to manually add weak to your properties, unless you have defined a strong relationship somewhere else in your code (which is the typical case when you have delegates).
ARC mostly just works. You normally do not have to worry about declaring weak when using Cocoa classes such as the ones you listed.
You only have to consider it when you have different classes you've developed yourself that have bi-directional references. (Apartment class and Person class in Apple's example).