Treehouse Intermediate Course Part 8 (Memory Management)

Continuing my run - now four days in a row, the next course looks to be about memory. There are only four videos with a quiz on the end, so I aim to complete that today. I'm also going to make a note of the time I started learning from now on - pausing it for any breaks, or making a note of these - to see how many minutes I've done. My aim of three hours per week is from Sunday to Saturday, so this is the last day to ensure I get that.

Time - 12:10pm

Manual Retain Release

Every instance created takes up memory. For simple apps like we've done so far, there's a tiny memory footprint. However, for larger ones, the program can fail if there is too much memory to hold.

MRR - the programmer was in charge of this, including reference counting. I've seen that reference counting from one of Ray's courses. Doing this manually must have been exhausting, even though it did put you in control.

Automatic Reference Counting (ARC)

So this only counts for class/reference types. Not for value types like for structs.

ARC - keeps tracks of how many properties, variables and constants are being held on to in an instance of a class.

One active reference - ARC will not deallocate the reference use.

Strong reference - as long as the reference exists, the memory for that instance is not deallocated.

Deinit method - this is for more complex classes.

Here is an example with code (I've edited it for something relevant - from HOMAM 3!)

class Creature {

    

    let name: String

    

    init(name: String) {

        self.name = name

        print("Allocated memory for \(name)")

    }

    

    deinit {

    print("\(name) is being deinitialized. Memory is being deallocated")

    }

}

Here is a way of showing the deinit part. 

var reference1: Creature? = Creature(name: "gargoyle")

The first print statement is executed - so the ARC would go up by 1. 

var reference2: Creature? = reference1

reference1 = nil

reference2 = nil

Right so with these examples, the ? is used, just in case they then will equal nil (which they will...), then when reference1 = nil, it does not print the second statement, as the value is now held in reference2. So when reference 2 = nil, it means that the deinit method is executed and that print statement comes up to show you that there is no memory allocated. 

Right, so it's a way of keeping the memory allocation as low as possible. Makes sense!

I need to pause there. So time is now: 12:27 pm (17 minutes so far!)

*Restarting at 13:06

Memory Leaks

So it is possible for an instance to never get the ARC back to 0....

Code snippet missing so not able to interact with the code. Let's have a look at what Pasan does.

So setting a variable to the value of another can have complications. Setting to nil would not remove both - I think.

Weak References

This is the last video in this course before the quiz. Has gone quickly!

So weak references - using the weak keyword. I've done this before on Xcode when creating labels which do not have any interactivity, just displays.

An instance can have several weak references and one strong one - this would have a reference count of 1.

ARC only cares about strong references.

So all objects with the weak keyword must be optionals and variables.

Now with the code example we're getting a bit technical. With protocols involved, it gets more!

One point -we cannot use the weak keyword with something associated with a value type (from a struct in the example).

*Paused at 13:21 (15minutes)
*Restart at 13:56

protocol Loan {

    

    var payee: Customer { get set }

    

}

class Customer {

   weak var loan: Loan?

    

}

An error comes up here - we have no way of guaranteeing that the loan var will be a reference type. If it uses a protocol then it can't be. So we want to tell the compiler that loan CONFORMS to the Loan protocol, but is still a reference type!

OK - specifying class after Loan means that ONLY classes can conform to the protocol, therefore the error goes away as loan will be a reference type. Very technical and confusing stuff! Let's do a little more reading up on this!

*Paused at 14:02 (6 minutes)
*Restart at 14:15

ALL OF THESE INTERRUPTIONS!!

Some important information from the official Swift website:

However, if ARC were to deallocate an instance that was still in use, it would no longer be possible to access that instance’s properties, or call that instance’s methods. Indeed, if you tried to access the instance, your app would most likely crash.

So you must be careful to not deallocate when that instance is still needed. 

To make sure that instances don’t disappear while they are still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance. ARC will not deallocate an instance as long as at least one active reference to that instance still exists.

To make this possible, whenever you assign a class instance to a property, constant, or variable, that property, constant, or variable makes a strong reference to the instance. The reference is called a “strong” reference because it keeps a firm hold on that instance, and does not allow it to be deallocated for as long as that strong reference remains.

Strong reference cycle - comes from linking together two variables. So this stops deallocation and creates the 'memory leak'.

That's helped a tiny but but it still all seems very technical when looking at it in action.

Right so one more thing clarified - the system does ALL of the memory management for structs/enums/value types basically. That's good. But it doesn't do this for classes - so this is why you need to be aware of deallocation/deinit etc.

Right, quiz time! 4 out of 5 - not bad.

So, an unusual thing to focus on as there was little coding involved. I get the concept now, and know that it is with reference types that you need to be careful. When it comes to using lots of these, I'll read up again on Memory Management and study the syntax for using 'weak' in the right places, so that deallocation can work. Next time it will be Access Level/Access Control. And then that's the entire course done! Next, I will be looking at Udemy - not necessarily Angela's course, but out of what I have, what I can use to refine any understanding. Doing some more practical will be good too!

Exit time - 14:36 (21 minutes)

Total time for this blog - 59 minutes