This question has been open long enough and I now feel confident enough to answer it.
Different Levels of MM:
Hardware Memory
In Swift with ARC we have no way to clean up the actual hardware ram. We can only make it possible for the OS to do that for us. One part is using the right code (optionals and weak) the other part is creating time for the OS to do it's job.
Imagine we have a function that runs on all threads indefinitely. It does one thing, load an image, convert to black/white and save.
All images max at a couple of mb’s and the function creates no Software Memory Leaks.
Because images don’t have a set size and might have different compression they don’t have the same footprint.
This function will always crash your app.
This “Hardware” Memory Leak is caused by the function always taking the next available slot of memory.
The OS does not step in to “actually clean the memory” because there is no idle time. Putting a delay between each pass completely fixes this.
Language specific MM
Casting
Some operations don’t have an impact on memory, others do:
let myInt : Int = 1
Float(myInt) // this creates a new instance
Try casting instead:
(myInt as Float) // this will not create a new instance.
Reference Types vs Value Types | Classes vs Structs
Both have their advantages and their dangers.
Structs are memory intensive because they are Value Types.
This means they copy their values when assigned to another instance, effectively doubling memory usage.
There is no fix / work around for this. It is what makes Structs Structs.
Classes don’t have this behaviour because they are Reference Types. They don’t copy when assigned.
Instead they create another reference to the same object. ARC or Automatic Reference Counting is what keeps track of these references.
Every Object has a reference counter. Each time you assign it, it goes up by one. Each time you set a reference to nil, the enclosing function ends, or the enclosing Object deinits, the counter goes down.
When the counter hits 0 the object is deinitialised.
There is a way to prevent an instance from deinitialising, and thus creating a leak. This is called a Strong Reference Cycle.
Good explanation of Weak
class MyClass {
var otherClass : MyOtherClass?
deinit {
print("deinit") // never gets called
}
}
class MyOtherClass {
var myclass : MyClass?
deinit {
print("deinit") // never gets called
}
}
var classA : MyClass? = MyClass()
// sorry about the force unwrapping, don't do it like this
classA!.otherClass = MyOtherClass()
classA!.otherClass!.myclass = classA // this looks silly but in some form this happens a lot
classA = nil
// neither the MyClass nor the MyOtherClass deinitialised and we no longer have a reference we can acces. Immortalitiy reached they have.
set one reference to weak
class MyOtherClass {
weak var myclass : MyClass?
deinit {
print("deinit") // gets called
}
}
inout
Functions capture the values passed to them. But it is also possible to mark those values as inout. This allows you to change a Struct passed to a function without copying the Struct. This might save memory, depending on what you pass and what you do in the function.
It is also a nice way of having multiple return values without using tuples.
var myInt : Int = 0
// return with inout
func inoutTest(inout number: Int) {
number += 5
}
inoutTest(&myInt)
print(myInt) // prints 5
// basic function with return creates a new instance which takes up it's own memory space
func addTest(number:Int) -> Int {
return number + 5
}
Functional Programming
State is Value over Time
Functional programming is the counter part of Object Oriented programming. Functional programming uses Immutable state.
More on this here
Object Oriented programming uses Objects that have changing/mutating states. Instead of creating a new value, the old values are updated.
Functional Programming can use more memory.
example on FP
Optionals
Optionals allow you to set thing to nil. This will lower the reference count of Classes or deinitialise Structs. Setting things to nil is the easiest way to clean up memory. This goes hand in hand with ARC. Once you have set all references of a Class to nil it will deinit and free up memory.
If you don’t create an instance as an optional, the data will remain in memory until the enclosing function ends or the enclosing class deinits. You might not know when this will happen. Optionals give you control over what stays alive for how long.
API MM
Many "memory leaks" are cause by Frameworks that have a “clean up” function that you might not have called.
A good example is UIGraphicsEndImageContext() The Context will stay in memory until this function is called. It does not clean up when the function that created the context ends, or when the image involved is set to nil.
Another good example is dismissing ViewControllers. It might make sense to segue to one VC and then segue back, but the segue actually creates a VC. A segue back does not destroy a VC. Call dismissViewControllerAnimated() to remove it from memory.
Read the Class References and double check there are no “clean up” functions.
If you do need Instruments to find a leak, check out the other answer on this question.
