Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Start a free Basic trial
to watch this video
Like modern Objective-C, Swift makes use of Automatic Reference Counting (ARC). In this video, we'll see how to prevent reference cycles, handle closures and keep our Swift code optimized.
-
0:00
Like Objective C, Swift makes use of automatic reference counting or ARC.
-
0:05
Many of the considerations you need to make are similar to Objective C,
-
0:09
though overall you actually have even less to worry about.
-
0:12
In this video, we won't repeat all the theory but
-
0:15
we will focus on what's different in Swift memory management, and
-
0:18
a few of the most common snags developers hit.
-
0:21
The first thing you'll notice as different in Swift memory management
-
0:24
is that we aren't explicitly declaring memory directives like strong and
-
0:28
copy, like they would be in Objective C property declarations like this.
-
0:33
In Swift, all properties of a class are assumed to be strong, so
-
0:36
you'd simply write them like this.
-
0:38
[SOUND] No strong required.
-
0:40
Of course Swift, like objective C, isn't immune to retain cycles.
-
0:44
So often, you will need to explicitly request a weak reference, for
-
0:48
instance, between a parent and a child.
-
0:50
To do this, you do need to use the keyword, weak.
-
0:53
In this example, we can imagine that a person may, or may not have a car.
-
0:57
When the person object is active in the app, we would want that reference.
-
1:01
When that person is set to nil, which could happen for any number of reasons,
-
1:05
we would wanna release the car object and the person object.
-
1:09
If there were strong references in both directions, that would never happen.
-
1:14
Now in the person car example, both objects could be nil.
-
1:17
Neither a person nor a car must exist in order for the other to exist, but
-
1:22
what about situation where one of the objects could never be nil?
-
1:26
For example, let's say we have a user and a user avatar.
-
1:31
In this scenario, a user might elect not to have a user avatar, and
-
1:35
instead just display some placeholder image.
-
1:38
However on the flip side, a user avatar must be associated with a user.
-
1:43
Without being link to a user, it wouldn't have any meaning in our app.
-
1:46
In this case, instead of using a weak reference like this,
-
1:50
we would use an unowned reference like so.
-
1:54
The last variant on this situation is one in which
-
1:57
neither member of the relationship should ever be nil.
-
2:00
For example, between two objects, mobileDevice and SerialNumber.
-
2:05
Neither should exist without a link to the other.
-
2:08
Here you see our solution was to combine one explicitly unwrapped optional,
-
2:13
that's the exclamation point following the SerialNumber property
-
2:15
of the mobileDevice class,
-
2:17
along with an unowned reference pointing from the SerialNumber to the mobileDevice.
-
2:23
If you need a refresher on unwrapped optionals, check below for a helpful link.
-
2:27
Given that blocks in Objective C are susceptible to memory issues,
-
2:31
it isn't surprising that their Swift counterpart, closures, are as well.
-
2:36
Now a closure could cause a strong reference cycle in a few ways.
-
2:40
But generally it would occur when you assign a closure to a property of a class
-
2:44
instance and that closure itself is actually capturing the instance.
-
2:49
Imagine the closure is capturing self.myproperty or
-
2:53
self.mymethod, common things you might place in a closure, right?
-
2:57
Well in both situations, you've now captured self and
-
3:01
therein have given yourself a strong reference cycle.
-
3:04
The solution for this problem is creating something called a capture list.
-
3:08
Simply put,
-
3:09
a capture list lets you explicitly specify how you capture constants and
-
3:13
variables in a closure, and what special memory handling you might want.
-
3:18
Getting into the nitty gritty of closures and
-
3:20
capture lists are beyond the scope of this overview, but
-
3:23
if it interests you or if you think your code might be subject to this issue,
-
3:27
I'd direct you to the Apple documentation linked below in the teacher's notes.
You need to sign up for Treehouse in order to download course files.
Sign up