Understanding Instruments memory allocation log on iOS

Question

I have built an iOS app that is almost done, however, I have recently experienced that it crashes after while due to \"Memory pressure\". So I started profiling the memory alloc

Answer 1

Instruments is saying that your UIViews are leaking (or not deallocated to be precise).

Each push will create a new destinationController and the destinationController's view will be backed by a CALayer and CALayer kills memory.

To prove that, you can just implement dealloc for your destinationController and set a breakpoint there to see if it's called.

If the dealloc is called than you can do this for other objects to find out which one. (Like destinationController.view )

Why leaking?

1, You may have retain cycles that capturing destinationController. It's a pain to debug, you may have to check through all your code related.

2, Every destinationController may be retained by some long living object. (Repeated NSTimer that are not invalidated, Singleton, RootViewController, CADisplayLink ...)

3, False cache. You cache something and try to reuse it. However, the cache logic has bugs and those objects never get reused and new objects are constantly inserted in.

Answer 2

Check first to see if (scheme diagnostics) you have zombies turned on. Zombies means nothing is ever deleted. Given that your memory chart never goes down at all that would be my first check.

Answer 3

Here's how I debug these.

1. In Instruments, use the Allocations instrument and turn on "Record reference counts"

2. Run your app to a "steady state", including performing the operation you think is leaking a few times.

3. In Instruments, set your baseline memory level using the in/out markers.

4. Perform the operation you think is leaking a few times. (say 7)

5. In Instruments, switch to the view that shows all allocations and look for objects that have been allocated yet not deallocated the same number of times as the operation you just performed (again maybe 7 times). You'll first want to try to find an object specific to your program... So prefer MyNetworkOperation instances instead of generic foundation classes like NSData.

6. Select one of the objects that hasn't been deallocated and look at it's allocation history. You'll be able to see the call stack for every alloc/retain/release/autorelease for the object in question.. Probably one of the calls will look suspicious to you.

I suppose these steps apply more in a non-ARC environment. Under ARC you might be looking for something that's a retain cycle.

In general you can avoid retain cycles by making sure your strong references only go in one direction... For example, a view has strong references to it's subviews and each subview must only ever use weak references to refer to any parent view. Or perhaps your view controller has a strong reference to your view. Your view must only have a weak reference to its view controller. Another way to say this is to decide in each relationship which object "owns" the other.

Answer 4

Your animation mostly contains changing alpha value or colour. To reduce the animation code in custom segue, I suggest you move your animation code for destination view controller (i.e. the method destinationControllerIn) to viewDidLoad: of destination view controller.