Swift Managing Memory

This question was cleaned up and the important info moved to the answer below.

I have some questions about memory management.

I am building a photo editing app. So keeping memory usage low is important. Also I am not going to post code because I do not have a big memory leak when doing one specific thing. I just lose a couple of KB's/MB's with everything that happens. And going over tens of thousands of lines of code to find kilobytes is no fun ;)

my app uses core data, lots of cifilter stuff, location, and the basics.

My first view is just a tableview which costs me about 5mb of memory. Then you take some photos, apply some filters, this gets saved to core data and then you go back to that first view.

Is it possible to truly get rid of everything in memory except for the data needed to drive that first view. (that very save and awesome 5mb)

Or will there always be something left behind, even if you set everything to nil?

Bonus Question: is there a difference in file size / cpu load between UIImageJPEGRepresentation and UIImagePNGRepresentation? I know you can set a compression quality with the JPEG method (harder on the cpu/gpu?).

Just trying to reduce memory pressure by all means possible.

Update:

It was pointed out to me that the question might be too vague.

The problems I was having at some point or another were the following:

At some points peak memory usage is too high
Navigating to a second viewcontroller and back causes a leak
Editing an image causes a memory leak.
Applying a filter to more than 4-5 images causes a crash because of low memory, there were no more memory leaks at this point. (verified in instruments)

P.s this was all tested on an iPhone 4s , not the simulator.

There was a meme here to lighten the mood on this site a bit.

回答1:

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.

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.

回答2: