Memory Consumption

Memory consumption refers to the RAM that an app consumes.

The iOS virtual memory model does not include swap memory, which means that, unlike with desktop apps, the disk cannot be used to page memory. The end result is that the apps are restricted to available RAM, which is used not only by the app in the foreground but also by the operating system services and potentially also by background tasks being run by other apps.

There are two parts to memory consumption in an app: stack size and heap size. The following subsections take a closer look at each.

Stack Size

Each new thread in an app receives its own stack space consisting of both reserved and initially committed memory. The stack is freed when the thread exits. The maximum stack size for a thread is small, and among other things, it limits the following:

Maximum number of methods that can be called recursively

Each method has its own stack frame and contributes to the overall stack space consumed. For instance, as shown in Example 1-1, if you call main, which in turn calls method1 (which subsequently calls method2), there are three stack frames contributing a few bytes each. Figure 1-1 shows how a thread stack looks like over time.

Example 1-1. Call tree

main() {
    method1();
}

method1() {
    method2();
}

Maximum number of variables that you can use within a method

All variables are loaded on the method stack frame, and hence contribute to the stack space consumed.

Maximum number of views that you can nest in the view hierarchy

Rendering a composite will invoke layoutSubViews and drawRect recursively across the complete hierarchy tree. If the hierarchy is deep, it may result in a stack overflow.

Figure 1-1. Stack with stack frame of each method

Heap Size

All threads of one process share the same heap. The total heap size available for an app is generally much lower than the device RAM. For example, an iPhone 5S may have 1 GB of RAM, but the maximum heap size allocated to an app may be 512 MB or even less. The app cannot control the heap allocated for it. It is managed by the operating system.²

Processes such as NSString, loading images, creating or consuming JSON/XML data, and using views will consume a lot of heap memory. If your app is an image-heavy one (something along the lines of the Flickr and Instagram apps), you will need to take special care to minimize average and peak memory usage.

Figure 1-2 shows a typical heap that may exist at some time in an app.

In Figure 1-2, the main thread started by the main method creates UIApplication. We assume that at some point in time the window comprises a UITableView that uses a UITableViewDataSource whose method tableView:cellForRowAtIndex: is called when a row must be rendered.

The data source has a reference to all the photos to be shown in a property named photos of type NSArray. If not implemented properly, this array can be huge, resulting in high peak memory usage. One solution is to always store a fixed number of images in the array and swap in and out as the user scrolls the view. This fixed number will determine your app’s average memory usage.

Figure 1-2. Heap demonstrating use of a model HPPhoto in a UITableViewDataSource

Each item in the array is of type HPPhoto, which represents a photo. HPPhoto stores data associated with the object—for example, image size, date of creation, owner, tags, web URL associated with the photo (not shown in the image), reference to local cache (not shown in the image), and so on.

All data related to objects created from classes is stored on the heap.

The class may have properties or instance variables (iVars) of value types such as int, char, or struct, but because the objects are created on the heap, they will consume only heap memory.

When objects are created and values assigned, they may be copied from stack to heap. Similarly, when values are used within a method, they may be copied from heap to stack. This may be an expensive operation. Example 1-2 highlights when the copy from stack to heap and vice versa happens.

Example 1-2. Heap versus stack

@interface AClass 

@property (nonatomic, assign) NSInteger anInteger; 
@property (nonatomic, copy) NSString *aString; 

@end

//some other class
-(AClass *) createAClassWithInteger:(NSInteger)i
    string:(NSString *)s { 

    AClass *result = [AClass new];
    result.anInteger = i; 
    result.aString = s; 
}

-(void) someMethod:(NSArray *)items { 
    NSInteger total = 0;
    NSMutableString *finalValue = [NSMutableString string];

    for(AClass *obj in items) {
        total += obj.anInteger; 
        [finalValue appendString:obj.aString]; 
    }
}

The class AClass has two properties.

anInteger is of type NSInteger, which is passed by value.

aString is of type NSString *, which is passed by reference.

The createAClassWithInteger:string: method (in some class that is not of relevance here) instantiates AClass. This method is provided with the values required to create the object.

The value for i is on the stack. However, when assigned to the property, it must be copied to the heap because that is where result is stored.

Although NSString * is passed by reference, the property is marked copy, which means that the value must be duplicated or cloned, depending on how the method [-NSCopying copyWithZone:] is implemented.

someMethod: processes an array of AClass objects.

When anInteger is used, its value must be copied to the stack before it can be processed. In this example, the value is added to total.

When aString is used, it is passed by reference. In this example, appendString: uses the reference to the aString object.

Tip

It is a good idea to keep your memory requirements to not more than a percentage of available RAM. Though there is no hard rule to it, it is recommended to not use more than 80%–85%, leaving the remainder for core OS services.

Do not ignore didReceiveMemoryWarning signals.

Memory Management Model

In this section, we study how the iOS runtime manages memory and the effect it has on the code.

The memory management model is based on the concept of ownership. As long as an object is owned, the memory it uses cannot be reclaimed.

Whenever an object is created in a method, the method is said to own the object. If this object is returned from the method, then the caller is said to claim the ownership. The value can be assigned³ to another variable, and the corresponding variable is likewise said to have claimed the ownership.

Once the task with the object is completed, you relinquish ownership. This process does not transfer ownership, but increases or decreases the number of owners, respectively. When the number of owners goes down to zero, the object is deallocated and the memory is released.

This ownership count is more formally referred to as the reference count. When you manage it yourself, it is called manual reference counting (MRC). Although it is rarely used today, MRC is useful to understand. Modern-day apps use automatic reference counting (ARC), which we discuss in “Automatic Reference Counting”.

Example 1-3 demonstrates the basic structure of manual memory management using reference counting.

NSString *message = @"Objective-C is a verbose yet awesome language"; 
NSString *messageRetained = [message retain]; 
[messageRetained release]; 
[message release]; 
NSLog(@"Value of message: %@", message); 

Example 1-4 demonstrates how methods affect the reference count.

//part of a class Person
-(NSString *) address {
    NSString *result = [[NSString alloc]
            initWithFormat:@"%@
%@
%@, %@",
            self.line1, self.line2, self.city, self.state]; 
    return result;
}

-(void) showPerson:(Person *) p {
    NSString *paddress = [p address]; 

    NSLog(@"Person's Address: %@", paddress);

    [paddress release]; 
}

If you look at Example 1-4, showPerson: does not know if address creates a new object or reuses one. However, it does know that the object would have been returned to it after incrementing the reference count by 1. As such, it does not retain the address. Once the job is completed, it releases it. If the object had a reference count of 1, it will become 0 and object will be dealloced.

Official Apple and LLVM documentation prefers the term ownership. The terms ownership and reference count are used interchangeably in the lesson.

Autoreleasing Objects

Autoreleasing objects allows you to relinquish the ownership of an object but defer its destruction. It is useful in scenarios in which you create an object in a method and want to return it. It helps in the management of an object’s life in MRC.

In the strict sense of naming conventions of Objective-C, in Example 1-4, there is nothing to denote that the address method owns the returned string. The caller, showPerson:, therefore has no reason to release the returned string, resulting in a potential memory leak. [paddress release] is a piece of code that has been added for illustrative purposes.

So, what is the correct code for the method address?

There are two possibilities:

• Do not use alloc or associated methods.

• Return an object with a deferred release message.

The first fix is easy to implement when working with NSString. The updated code is shown in Example 1-5.

-(NSString *) address {
    NSString *result = [NSString
            stringWithFormat:@"%@
%@
%@, %@",
            self.line1, self.line2, self.city, self.state]; 
    return result;
}

-(void) showPerson:(Person *) p {
    NSString *paddress = [p address];

    NSLog(@"Person's Address: %@", paddress);
    
}

However, this fix is not easy to apply when not working with NSString, as it is generally difficult to find the appropriate method that will serve the need. For example, when working with a third-party library or with a class that has multiple methods to create an object, it may not always be clear which method retains the ownership.

And this is where deferred destruction comes into play.

The NSObject protocol defines the message autorelease that can be used for deferred release. Use it when returning an object from a method.

The updated code using autorelease is given in Example 1-6.

-(NSString *) address
{
    NSString *result = [[[NSString alloc]
            initWithFormat:@"%@
%@
%@, %@",
            self.line1, self.line2, self.city, self.state]
        autorelease];
    return result;
}

The code can be analyzed as follows:

1. You own the object (NSString, in this case) returned by the alloc method.

2. To ensure no memory leak, you must relinquish the ownership before losing the reference.

3. However, if you use release, the object will be dealloced before return and the method, as a result, will return an invalid reference.

4. autorelease signifies that you want to relinquish ownership but at the same time allow the caller of the method to use the returned object before it is dealloced.

Autorelease Pool Blocks

The autorelease pool block is a tool that allows you to relinquish ownership of an object but avoid it being dealloced immediately. This is a very useful feature when returning objects from a method.

It also ensures that the objects created within the block are dealloced as may be needed once the block is complete. This is useful when you need to create several objects. Local blocks can be created to dealloc the objects as early as possible and keep the memory footprint low.

An autorelease pool block is marked using @autoreleasepool.

If you open the main.m file in the sample project, you will notice the code shown in Example 1-7.

int main(int argc, char * argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil,
            NSStringFromClass([HPAppDelegate class]));
	}
}

All objects that were sent an autorelease message within the block will be sent a release message at the end of the autoreleasepool block. More importantly, a release message will be sent for each autorelease call. This means that if an object was sent an autorelease message more than once, the release message will be sent more than once. This is good, as it will keep the reference count of the object down to the same as it was before the autoreleasepool block. If the count is 0, the object will be dealloced, keeping a low memory footprint.

If you look at the code in the main method, you’ll see that the entire app is within the autoreleasepool block. This means that any autorelease object will be dealloced at the end, resulting in no memory leak.

Like other code blocks, autoreleasepool blocks can be nested, as shown in Example 1-8.

@autoreleasepool {
 // some code
 @autoreleasepool {
  // some more code
	}
}

Because control passes from one method to another, it is uncommon to use nested autoreleasepool blocks in the same method. However, the called method may have its own autoreleasepool block for early object deallocations.

There are some occasions where you will likely want to create autoreleasepool blocks of your own. For example:

When you have a loop that creates lot of temporary objects

Use an autoreleasepool block within the loop to deallocate the memory for each iteration. Although the eventual memory use before and after the iteration may still be the same, the maximum memory requirement for your app may be reduced by a large factor.

Example 1-9 provides examples of bad as well as good code to write when using autoreleasepool blocks.

When you create a thread

Each thread will have its own autoreleasepool block stack. The main thread starts with its own autoreleasepool because it comes from the generated code. However, for any custom thread, you have to create your own autoreleasepool.

See Example 1-10 for sample code.

//Bad code 
{
    @autoreleasepool {
        NSUInteger *userCount = userDatabase.userCount;

        for(NSUInteger *i = 0; i < userCount; i++) {
            Person *p = [userDatabase userAtIndex:i];

            NSString *fname = p.fname;
            if(fname == nil) {
                fname = [self askUserForFirstName];
            }

            NSString *lname = p.lname;
            if(lname == nil) {
                lname = [self askUserForLastName];
            }
            //...
            [userDatabase updateUser:p];
        }
    }
}

//Good code 
{
    @autoreleasepool {
        NSUInteger *userCount = userDatabase.userCount;

        for(NSUInteger *i = 0; i < userCount; i++) {

            @autoreleasepool {
                Person *p = [userDatabase userAtIndex:i];

                NSString *fname = p.fname;
                if(fname == nil) {
                    fname = [self askUserForFirstName];
                }

                NSString *lname = p.lname;
                if(lname == nil) {
                    lname = [self askUserForLastName];
                }
                //...
                [userDatabase updateUser:p];
            }
        }
    }
}

-(void)myThreadStart:(id)obj {
    @autoreleasepool {
        //New thread's code
    }
}

//Somewhere else
{
    NSThread *myThread = [[NSThread alloc] initWithTarget:self
        selector:@selector(myThreadStart:)
        object:nil];

    [myThread start];
}

Automatic Reference Counting

Keeping track of retain, release, and autorelease is not easy. What is even more puzzling is determining where, when, and to whom to send these messages.

Apple introduced Automatic Reference Counting (ARC) at WWDC 2011 as a solution to this problem. Swift, the new language for iOS apps, also uses ARC. Unlike Objective-C, Swift does not support MRC.

ARC is a compiler feature.⁴ It evaluates the lifetime requirements of the objects in the code and automatically injects appropriate memory management calls at compile time. The compiler also generates appropriate dealloc methods. This means that most of the difficulties related to keeping track of memory usage (e.g., ensuring that it is deallocated when not required) are eliminated.

Figure 1-3 demonstrates the relative development time with MRC versus ARC. Development with ARC is faster because of reduced code.

Figure 1-3. ARC reduces development time and prevents headaches

You’ll need to ensure that ARC is enabled in the Xcode project settings, which is the default starting with Xcode 5 (see Figure 1-4).

Figure 1-4. Project settings for ARC in Xcode

//Not allowed
@property NSString * newTitle;

//Allowed
@property (getter=getNewTitle) NSString * newTitle;

-(NSString *) address
{
    NSString *result = [[NSString alloc] initWithFormat:@"%@
%@
%@, %@",
        self.line1, self.line2, self.city, self.state]; 
    return result;
}

-(void) showPerson:(Person *) p
{
    NSString *paddress = [p address];

    NSLog(@"Person's Address: %@", paddress);
    
}

Reference Types

ARC introduced a new reference type: weak references. Understanding the available reference types is important to memory management. The supported types are:

Strong references

A strong reference is the default reference created. Memory referred to by a strong reference cannot be relinquished. A strong reference increases the reference count by 1, resulting in extension of the object’s lifetime.

Weak references

A weak reference is a special reference that does not increase the reference count (and hence does not extend the object’s lifetime). Weak references are a very important part of ARC-enabled Objective-C programming, as we explore later.

TypeName * qualifier variable;

Person * __strong p1 = [[Person alloc] init]; 
Person * __weak p2 = [[Person alloc] init]; 
Person * __unsafe_unretained p3 = [[Person alloc] init]; 
Person * __autoreleasing p4 = [[Person alloc] init]; 

@property (nonatomic, strong) IBOutlet UILabel *titleView;
@property (nonatomic, weak) id<UIApplicationDelegate> appDelegate;
@property (nonatomic, assign) UIView *danglingReference; 
@property (nonatomic, assign) BOOL selected; 
@property (nonatomic, copy) NSString *name;
@property (nonatomic, retain) HPPhoto *photo; 
@property (nonatomic, unsafe_unretained) UIView *danglingReference;

Getting Your Hands Dirty

OK, now that we have learned a bit about the new lifetime qualifiers for variables and properties, let’s put them to use, update our project, and see the effects.

File → New → iOS → Cocoa Touch → Objective-C class

//HPPhoto.h
@interface HPPhoto : NSObject

@property (nonatomic, strong) HPAlbum *album;
@property (nonatomic, strong) NSURL *url;
@property (nonatomic, copy) NSString *title;
@property (nonatomic, strong) NSArray *comments;

@end

//HPPhoto.m
@implementation HPPhoto

-(void) dealloc
{
    DDLogVerbose(@"HPPhoto dealloc-ed");
}

@end

Storyboard Update

Add a label and four buttons to the view of the First View Controller in the storyboard. The buttons will trigger creation of these variables while the label will be used to display the result. The final UI should look similar to that shown in Figure 1-6.

Figure 1-6. Updated view of First View Controller

We also add appropriate IBOutlet and IBAction references in the code, as shown in Example 1-16.

Example 1-16. Reference updates in HPFirstViewController.h

@interface HPFirstViewController : UIViewController

@property (nonatomic, strong) IBOutlet UILabel *resultLabel;

-(IBAction)createStrongPhoto:(id)sender;
-(IBAction)createStrongToWeakPhoto:(id)sender;
-(IBAction)createWeakPhoto:(id)sender;
-(IBAction)createUnsafeUnretainedPhoto:(id)sender;

@end

-(IBAction)createStrongPhoto:(id)sender
{
    DDLogDebug(@"%s enter", __PRETTY_FUNCTION__);
	HPPhoto * __strong photo = [[HPPhoto alloc] init];
    DDLogDebug(@"Strong Photo: %@", photo);
	photo.title = @"Strong Photo";

	NSMutableString *ms = [[NSMutableString alloc] init];
	[ms appendString:(photo == nil ? @"Photo is nil" : @"Photo is not nil")];
	[ms appendString:@"
"];
	if(photo != nil) {
		[ms appendString:photo.title];
	}
	self.resultLabel.text = ms;
	DDLogDebug(@"%s exit", __PRETTY_FUNCTION__);
}

-(IBAction)createWeakPhoto:(id)sender
{
    DDLogDebug(@"%s enter", __PRETTY_FUNCTION__);
	HPPhoto * __weak wphoto = [[HPPhoto alloc] init];
    DDLogDebug(@"Weak Photo: %@", wphoto);
	wphoto.title = @"Weak Photo";

	NSMutableString *ms = [[NSMutableString alloc] init];
	[ms appendString:(wphoto == nil ? @"Photo is nil" : @"Photo is not nil")];
	[ms appendString:@"
"];
	if(wphoto != nil) {
		[ms appendString:wphoto.title];
	}
	self.resultLabel.text = ms;
	DDLogDebug(@"%s exit", __PRETTY_FUNCTION__);
}

-(void)createStrongToWeakPhoto:(id)sender
{
    DDLogDebug(@"%s enter", __PRETTY_FUNCTION__);
	HPPhoto * sphoto = [[HPPhoto alloc] init];
    DDLogDebug(@"Strong Photo: %@", sphoto);
	sphoto.title = @"Strong Photo, Assigned to Weak";

	HPPhoto * __weak wphoto = sphoto;
	DDLogDebug(@"Weak Photo: %@", wphoto);

	NSMutableString *ms = [[NSMutableString alloc] init];
	[ms appendString:(wphoto == nil ? @"Photo is nil" : @"Photo is not nil")];
	[ms appendString:@"
"];
	if(wphoto != nil) {
		[ms appendString:wphoto.title];
	}
	self.resultLabel.text = ms;
    DDLogDebug(@"%s exit", __PRETTY_FUNCTION__);
}

-(void)createUnsafeUnretainedPhoto:(id)sender
{
    DDLogDebug(@"%s enter", __PRETTY_FUNCTION__);
	HPPhoto * __unsafe_unretained wphoto = [[HPPhoto alloc] init];
    DDLogDebug(@"Unsafe Unretained Photo: %@", wphoto);
	wphoto.title = @"Strong Photo";

	NSMutableString *ms = [[NSMutableString alloc] init];
	[ms appendString:(wphoto == nil ? @"Photo is nil" : @"Photo is not nil")];
	[ms appendString:@"
"];
	if(wphoto != nil) {
		[ms appendString:wphoto.title];
	}
	self.resultLabel.text = ms;
    DDLogDebug(@"%s exit", __PRETTY_FUNCTION__);
}

Output Analysis

The output is shown in Figure 1-7.

Figure 1-7. Lifetime qualifiers for variables

It’s mostly self-explanatory, with some interesting observations:

1. A __strong reference (method createStrongPhoto:) ensures that the object is not destroyed until it goes out of scope. The object was dealloced only after the method completed.

2. A __weak reference (method createWeakPhoto:) does not contribute to the reference count. Because the memory was allocated in the method and pointed to a __weak reference, the reference count was 0 and the object was immediately dealloced, even before it could be used in the very next statement.

3. In the method createStrongToWeakPhoto:, even though the __weak reference does not increase the reference count, the __strong reference created earlier ensures that the object is not released before the method ends.

4. The results of the method createUnsafeUnretainedPhoto: are more interesting. Notice that the object was dealloced immediately, but because the memory was still not reclaimed, the reference was usable and did not result in an error.

5. However, when we call the method again, we see not only that the object has been dealloced but also that the memory has been reclaimed and repurposed. As such, using the reference resulted in an illegal access, causing the app to crash with a signal of SIGABRT. This is possible if the memory is reclaimed at a later time (after the object deallocation but before the object access).

   Looking at Figure 1-8, you will notice that the memory was reclaimed just before the title property was set, resulting in an unrecognized selector sent to instance error because the memory is gone and may be now used by some other object.

   

   Figure 1-8. __unsafe_unretained crash

Zombies

Zombie objects are a debugging feature to help catch memory errors.

Normally when an object’s reference count drops to 0 it is freed immediately, but that makes debugging difficult. If zombie objects are enabled, instead of the object’s memory being instantly freed, it’s just marked as a zombie. Any further attempts to use it will be logged, and you can track down where in the code the object was used past its lifetime.

NSZombieEnabled is an environment variable that controls whether the Core Foundation runtime will use zombies. NSZombieEnabled should not be left in place permanently, as by default no objects will ever be truly deallocated, which will cause your app to use tremendous amounts of memory. Specifically, remember to disable NSZombieEnabled for archived release builds.

To set the NSZombieEnabled environment variable, navigate to Product → Scheme → Edit Scheme. Choose the Run section on the left, and the Diagnostics tab on the right. Select the Enable Zombie Objects entry, as shown in Figure 1-9.

Figure 1-9. Xcode settings to enable zombies

Rules of Memory Management

Now that we know the details of these lifetime qualifiers, it is important to review some basic rules of memory management.

As per Apple’s official documentation, there are four basic rules of memory management:

• You own any object you create, using, for example, new, alloc, copy, or mutableCopy.

• You can take ownership of any object using retain in MRC or a __strong reference in ARC.

• You must relinquish ownership of an owned object when you no longer need it using release in MRC. It’s not necessary to do anything special in ARC. The ownership will be relinquished after the last reference to the owned object (i.e., the last line in a method).

• You must not relinquish ownership of any object that you do not own.

To help avoid memory leaks or app crashes, you should keep these rules handy when writing Objective-C code.

Retain Cycles

One of the biggest gotchas with reference counting is that it cannot handle cyclic references, or what are known as retain cycles in Objective-C. In this section, we look at common scenarios where retain cycles may be introduced and best practices to avoid them.

If you closely look at the rules described in the previous section, you’ll see that they are nothing more than the implementation of reference counting. A claim of ownership increments the reference count, whereas relinquishing ownership decrements the reference count. When the reference count goes down to zero, the object is dealloced and the memory is released.

In our app, the HPAlbum entity may have a coverPhoto and an array of photos to represent the album’s cover photo and other photos associated with it. Similarly, HPPhoto may represent a photo that belongs to an album, apart from having other attributes (e.g., the URL, title, comments, etc.). Example 1-21 shows representative code for the entity definitions.

@class HPPhoto;

@interface HPAlbum : NSObject

@property (nonatomic, copy) NSString *name;
@property (nonatomic, strong) NSDate *creationTime;
@property (nonatomic, copy) HPPhoto *coverPhoto; 
@property (nonatomic, copy) NSArray *photos; 

@end


@interface HPPhoto : NSObject

@property (nonatomic, strong) HPAlbum *album; 
@property (nonatomic, strong) NSURL *url;
@property (nonatomic, copy) NSString *title;
@property (nonatomic, copy) NSArray *comments;

@end

Let’s take a simple scenario of one album with two photos: p1 (the cover photo) and p2. The reference count is as follows:

• p1 has strong references in photos and coverPhoto. The reference count is 2.

• p2 has a strong reference in photos. The reference count is 1.

• album has strong references in both p1 and p2. The reference count is 2.

We discussed strong references earlier, in “Reference Types”.

To start with, let’s also say that these objects are created in some method named createAlbum. Even if the objects are never used after a certain point, the memory will not be released because the reference count never goes down to 0. Figure 1-10 demonstrates this relationship.

Figure 1-10. Album and photo references

Common Scenarios for Retain Cycles

There are more than a handful of common scenarios that can result in retain cycles. For example, using threads, timers, simple blocks, or delegates might result in retain cycles. Let’s explore each of these scenarios and the steps that need to be taken to prevent the retain cycles.

Delegates

Delegates are probably the most common place for introducing retain cycles. At app start, it’s common to retrieve the latest data from the server and update the UI. A similar refresh may be triggered when, for example, the user taps the refresh button.

Consider this specific scenario: a view controller that shows a list of records and has a refresh button that refreshes the list upon tap.

For the implementation, let there be two classes: HPDataListViewController for the UI and HPDataUpdateOp to simulate the network call. Example 1-22 shows the code for the view controller, and Example 1-23 shows the code for the update operation.

Example 1-22. App refresh invocation

//HPDataListViewController.h
@interface HPDataListViewController : UIViewController 

@property (nonatomic, strong) HPDataUpdateOp *updateOp; 
@property (nonatomic, strong) BOOL refreshing;

- (IBAction)onRefreshClick:(id)sender;

@end

//HPDataListViewController.m
@implementation HPDataListViewController

//Code of viewDidLoad omitted for brevity

- (IBAction)onRefreshClicked:(id)sender { 
    DDLogDebug(@"%s enter", __PRETTY_FUNCTION__); 
    if([self.refreshing == NO]) {
        self.refreshing = YES;
        if(self.updateOp == nil) {
            [self.updateOp = [[HPDataUpdateOp new];
        }
        [self.updateOp startWithDelegate:self
            withSelector:@selector(onDataAvailable:)]; 
    }
    DDLogDebug(@"%s exit", __PRETTY_FUNCTION__); 
}

- (void)onDataAvailable:(NSArray *)records { 
    //Update UI using latest records
    self.refreshing = NO;
    self.updateOp = nil;
}

@end

HPDataListViewController shows data in a list.

updateOp is the network operation that fetches the records.

The method called when the user taps the refreshButton.

Log to monitor the execution sequence.

The updateOp method can invoke a callback when the results are available.

onDataAvailable is the callback method. It updates the view controller state and UI.

Example 1-23. Update operation

//HPDataUpdateOp.m
@implementation HPDataUpdateOp

-(void)startWithDelegate:(id)delegate withSelector:(SEL)selector {
 dispatch_async(
  dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ 
	 //perform some operation 
		dispatch_async(dispatch_get_main_queue(), ^{ 
		 if([delegate respondsToSelector:selector]) {
			 [delegate performSelector:selector
     withObject:[NSArray arrayWithObjects:nil]; 
		 }
	 });
	});
}

-(void)dealloc {
	DDLogDebug(@"%s called", __PRETTY_FUNCTION__);
}

@end

All long-running tasks should be done outside of the main thread.

Let’s say it took 2 seconds for the operation.

Once results are available, switch the context back to the main thread, and…

… invoke the selector.

If you look at the method onRefreshClicked, it passes self to updateOp. At the same time, HPDataListViewController holds a reference to updateOp. This is where the cyclic reference is created.

For the solution, one option is to not have updateOp as a property but instead to create an instance of HPDataUpdateOp in the onRefreshClicked: method, so that updateOp holds a reference to the HPDataListViewController object, but not vice versa. The updated code is shown in Example 1-24.

Example 1-24. App refresh without property

- (IBAction)onRefreshClicked:(id)sender {
    DDLogDebug(@"%s enter", __PRETTY_FUNCTION__);
    if(self.refreshing == NO) {
        self.refreshing = YES;
        HPDataUpdateOp *updateOp = [[HPDataUpdateOp new]; 
        [updateOp startWithDelegate:self withSelector:@selector(onDataAvailable:)];
    }
    DDLogDebug(@"%s exit", __PRETTY_FUNCTION__);
}

Create a local variable so that it is not retained.

This does solve the problem of introducing a retain cycle, but it presents another problem. The updateOp object is never referenced elsewhere, and as a result, the moment control exits the onRefreshClicked: method, its reference count goes down to 0 and it may be dealloced immediately. The output is shown in Figure 1-11.

Figure 1-11. Result using local variable

HPDataUpdateOp, as demonstrated here, is simplistic. Typically, the app will have a network queue on which the update operation will be queued for execution. And it is possible that by the time the operation is complete, the user may have moved to a different view controller. If that is the case, ideally the view controller should be dealloced immediately, but because it is being used by the operation, it will not be. Now imagine this being true for several view controllers being retained by these operations on the queue. This does not create retain cycles, but does increase peak memory requirements. And this is also a definite bug, because if there is no view controller, the operation should ideally release the object.

So, strictly speaking, this doesn’t work either. What’s the cause? The issue is the strong reference to the HPDataListViewController object being held by the HPDataUpdateOp. But it cannot be weak either, because then there may be no link between these objects at all.

The solution is to have a strong reference to the operation in the delegate (which is the view controller in our case) and a weak reference to the delegate in the operation. When the operation is ready to invoke the callback method, it should get the strong reference to the delegate.

Additionally, we should introduce a cancel method in HPDataUpdateOp that can be called when the view controller is about to be dealloced. Example 1-25 shows the updated code to this effect.

Example 1-25. Final HPDataListViewController and HPDataUpdateOp

//HPDataListViewController
-(IBAction)onRefreshClicked:(id)sender {
 DDLogDebug(@"%s enter", __PRETTY_FUNCTION__);
	self.updateOp = [[HPDataUpdateOp new]; 
	[self.updateOp startUsingDelegate:self
	    withSelector:@selector(onDataAvailable:)];
	DDLogDebug(@"%s exit", __PRETTY_FUNCTION__);
}

-(void)onDataAvailable:(NSArray *)records {
 DDLogDebug(@"%s called", __PRETTY_FUNCTION__);
	self.resultLabel.text = @"[- onDataAvailable] called";
	self.updateOp = nil; 
}

-(void)dealloc {
 DDLogDebug(@"%s called", __PRETTY_FUNCTION__);
	if(self.updateOp != nil) {
		[self.updateOp cancel]; 
	}
}

//HPDataUpdateOp.h
@protocol HPDataUpdateOpDelegate <NSObject>

-(void)onDataAvailable:(NSArray *)records;

@end

@interface HPDataUpdateOp

@property (nonatomic, weak) id<HPDataUpdateOpDelegate> delegate; 

-(void)startUpdate;
-(void)cancel;

@end

//HPDataUpdateOp.m
@implementation HPDataUpdateOp
-(void)startUpdate {
	dispatch_async(
  dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
		//perform network call, and then report the result
  //NSArray *records = ...
		dispatch_async(dispatch_get_main_queue(), ^{
   id<HPDataUpdateOpDelegate> delegate = self.delegate; 
   if(!delegate) { 
				return;
			} else { 
				[delegate onDataAvailable:records];
			}
		});
	});
}

-(void)cancel { 
 //cancel inflight network request
	self.delegate = nil;
}

Use property for the operation. Operation is owned by the view controller.

Set property to nil once job is done. Enables deallocation of the operation object.

Cancel operation if view controller is about to be dealloced.

Operation keeps a weak reference to the callback delegate.

Try to get a strong reference for the delegate.

If the original object is still around…

… use that to report onDataAvailable.

The cancel operation explicitly calls for the callback objects to be dereferenced.

In essence, we implemented the first rule of “Rules to Avoid Retain Cycles”. HPDataListViewController is the owner, while HPDataUpdateOp is the object owned (i.e., the child in the ownership hierarchy).

Figure 1-12 shows the result when the response is ready before the user navigates back. Figure 1-13 shows the output when the user navigates back before the response is available.

Figure 1-12. Result using updated code with view controller available after operation completes

Figure 1-13. Result using updated code with view controller deallocated before operation completes

Although this might seem straightforward, it becomes more complicated as the execution goes through various layers and results in a complex object graph. It is very important to ensure that you do not retain the references in the lowest layers of networking, database, and storage that are used by the higher layers of the user interface (i.e., the layers whose usage creates objects).

Blocks

Similar to the problem that arises out of improper use of delegate objects is that of capturing outer variables when using blocks.

Consider the simple code in Example 1-26.

Example 1-26. Variable capturing using blocks

-(void)someMethod {
    SomeViewController *vc = [[SomeViewController alloc] init];
    [self presentViewController:vc animated:YES
        completion:^{
            self.data = vc.data;
            [self dismissViewControllerAnimated:YES completion:nil];
        }];
}

Unfortunately, this again results in long-lived objects—the child view controller will not die off because it is shown to the user, and the parent view controller will not clean up because it is captured in the completion block. In a scenario where SomeViewController may perform long-running tasks such as image processing or complex view rendering, with the parent view controller memory not cleared, the application may run the risk of low memory.

The solution, shown in Example 1-27, is similar to what we discussed in the previous section.

Example 1-27. Variable capturing using blocks

-(void)someMethod {
    SomeViewController *vc = [[SomeViewController alloc] init];

    __weak typeof(self) weakSelf = self; 

    [self presentViewController:vc animated:YES
        completion:^{
            typeof(self) theSelf = weakSelf; 

            if(theSelf != nil) { 
                theSelf.data = vc.data; 
                [theSelf dismissViewControllerAnimated:YES completion:nil];
            }
        }];
}

Grab a weak reference.

Grab the strong reference from the weak. Note that __strong is implicit. It increases the reference count…

…but only if it was not already nil. If so…

…proceed with subsequent operations.

Threads and timers

Inappropriate use of NSThread and NSTimer objects can also result in retain cycles. Some common ways of running async operations include the following:

• Using dispatch_async on the global queue, unless you write advanced code to manage custom queues

• Using NSThread to spin off async executions whenever and wherever you want

• Using NSTimer to execute a piece of code periodically

Consider a news app with a UI that shows the newsfeed of the logged-in user and autorefreshes it every 2 minutes.

Example 1-28 presents some commonly used code for performing a periodic update.

Example 1-28. Using NSTimer

@implementation HPNewsFeedViewController

-(void)startCountdown {
 self.timer = [NSTimer scheduledTimerWithTimeInterval:120
  target:self
  selector:@selector(updateFeed:)
  userInfo:nil repeats:YES];
}

-(void)dealloc {
    [self.timer invalidate];
}

@end

The retain cycle in Example 1-28 is obvious—the object retains the timer and the timer retains the object. Similar to the case of Example 1-22, we cannot solve the problem by not having a property. In fact, we will need the property so that it can be invalidated later.

For our code, the run loop will also retain the timer and will not release it until invalidate is called.

This creates a secondary retained reference to the timer object, resulting in a retain cycle even without an explicit reference in our code.

Caution

NSTimer objects result in indirect references held by the runtime. These are strong references, resulting in the reference count of the target going up not by 1 but by 2. You must invalidate the timer to remove the reference.

For a moment, assume that the code in Example 1-28 belongs to a view controller and the view controller is created several times in the app because of user interaction. Imagine the amount of memory leaked.

And don’t get excited if you use NSThread. Exactly the same problem happens here as well. There are two solutions to the problem:

• Include a deterministic call to invalidate.

• Split the code into separate classes.

Let’s explore both.

Do not rely on dealloc to clean up these objects. Why? If a retain cycle has been established, dealloc will never be called and the timers will never be invalidated. Because the run loop keeps track of live timers and threads, they are never destroyed by just niling their references in the code. To solve this, you can create a custom method that will perform this cleanup in a more deterministic manner.

For the case of a view controller, a good place to call this method is when the user moves away from the view controller, either by pressing the Back button or by taking any other action (the point is that the class knows when this happens). Let’s call this method cleanup. An implementation is provided in Example 1-29.

Example 1-29. Cleaning up NSTimer

-(void)didMoveToParentViewController:(UIViewController *) parent { 
 if(parent == nil) {
  [self cleanup];
 }
}

-(void)cleanup {
 [self.timer invalidate];
}

didMoveToParentViewController is called whenever the view controller moves into or out of the parent view controller.

In Example 1-29, we do the cleanup when the user navigates out from this view controller into its parent by overriding the didMoveToParentViewController: method. This call is far more deterministic than the dealloc call.

The other way out is to change the target of the Back button, as shown in Example 1-30.

Example 1-30. Cleaning up by intercepting the Back button

-(id)init {
    if(self = [super init]) {
        self.navigationItem.backBarButtonItem.target = self;
        self.navigationItem.backBarButtonItem.action
            = @selector(backButtonPressDetected:); 
    }
    return self;
}

-(void)backButtonPressDetected:(id)sender {
    [self cleanup]; 
    [self.navigationController popViewControllerAnimated:TRUE];
}

Intercept the Back button press of the navigation controller.

Clean up before popping up the view controller.

The next, cleaner option is to split the task ownership into multiple classes—a task class that actually performs the action, and the owner class that executes the task.

The latter option is preferred because:

• It is cleaner and has well-defined ownership of responsibilities.

• The task can be reused across multiple owners whenever needed.

We can break the previous code into two classes: HPNewsFeedViewController shows the latest feed, and HPNewsFeedUpdateTask runs periodically and checks for the latest feed that is fed into the view controller.

To this effect, the refactored code will now be as shown in Example 1-31.

Example 1-31. Refactored code for using timers

//HPNewsFeedUpdateTask.h
@interface HPNewsFeedUpdateTask

@property (nonatomic, weak) id target; 
@property (nonatomic, assign) SEL selector;

@end

//HPNewsFeedUpdateTask.m
@implementation HPNewsFeedUpdateTask

-(void)initWithTimeInterval:(NSTimeInterval)interval
    target:(id)target selector:(SEL)selector { 

    if(self = [super init]) {
        self.target = target;
        self.selector = selector;

        self.timer = [NSTimer scheduledTimerWithTimeInterval:interval
            target:self selector:@selector(fetchAndUpdate:)
            userInfo:nil repeats:YES];
    }
    return self;
}

-(void)fetchAndUpdate:(NSTimer *)timer { 
    //Retrieve feed
    HPNewsFeed *feed = [self getFromServerAndCreateModel];
    __weak typeof(self) weakSelf = self; 

    dispatch_async(dispatch_get_main_queue(), ^{
        __strong typeof(self) sself = weakSelf;
        if(!sself) {
            return;
        }

        if(sself.target == nil) {
            return;
        }

        id target = sself.target; 
        SEL selector = sself.selector;

        if([target respondsToSelector:selector]) {
            [target performSelector:selector withObject:feed];
        }
    });
}

-(void)shutdown { 
    [self.timer invalidate];
    self.timer = nil;
}
@end

//HPNewsFeedViewController.m
@implement HPNewsFeedViewController

-(void)viewDidLoad { 
    self.updateTask = [HPNewsFeedUpdateTask initWithTimeInterval:120
        target:self selector:@selector(updateUsingFeed:)];
}

-(void)updateUsingFeed:(HPNewsFeed *)feed { 
    //update the UI
}

-(void)dealloc { 
    [self.updateTask shutdown];
}
@end

Let’s take a look at a detailed analysis of HPNewsFeedUpdateTask:

1. The target property is weakly referenced. It is the target that instantiates the task here and owns it.

2. initWithTimeInterval: is the preferred method to be used. It takes the necessary inputs and starts the timer.

3. The fetchAndUpdate: method is executed periodically.

4. When using async blocks, we must ensure that we do not introduce a retain cycle. We have a __weak reference to be used inside the block.

5. In the method fetchAndUpdate: , the local variables for the target and the selector are created before calling respondsToSelector: and performing the operation.

   This is done to avoid a race condition arising during the following possible sequence of execution:

   1. Invoking [target respondsToSelector:selector] in some thread A.

   2. Changing either target or selector in some thread B.

   3. Invoking [target performSelector:selector withObject:feed] in thread A. With this code, even if either target or selector is changed, performSelector will be called on the correct target and selector.

6. The shutdown method invalidates the timer. The run loop deferences it, resulting in it being the only reference held by the task object.

On the usage side, HPNewsFeedViewController uses HPNewsFeedUpdateTask. The controller is not referenced by any object other than its parent controller. So, when the user navigates out of the controller (say, when the Back button is pressed), the reference count goes down to zero and it is dealloced. This in turn causes the update task to be shut down, which causes the timer to be invalidated, triggering the dealloc chain across all the associated objects (including the timer and the updateTask).

Let’s now look at an analysis of the HPNewsFeedViewController code in Example 1-31:

1. In the viewDidLoad method , the task is initialized, which internally triggers the timer.

2. The updateUsingFeed: method is the callback invoked periodically by the HPNewsFeedUpdateTask object.

3. dealloc is responsible for invoking the shutdown method on the task, which internally invalidates the timer. Note that dealloc is deterministic here because the object is not referenced anywhere else.

Tip

When using NSTimer and NSThread, always use a layer of indirection with deterministic invalidation. The indirection layer ensures a weak link, causing the owner object to be dealloced when not used in the app.

@interface ObserverObserveeHandle

@property (nonatomic, strong) MyObserver *observer;
@property (nonatomic, strong) NSObject *obj;
@property (nonatomic, copy) NSString *keyPath;

-(id)initWithObserver:(MyObserver *)observer
 target:(NSObject *)obj
 keyPath:(NSString *)keyPath;

@end

@implementation ObserverObserveeHandle

-(id)initWithObserver:(MyObserver *)observer
 target:(NSObject *)obj
 keyPath:(NSString *)keyPath {
  //Omitted for brevity
}

-(void)removeObserver {
 [self.obj removeObserver:self forKeyPath:self.keyPath context:nil];
 self.obj = nil;
}

-(void)dealloc {
 [self removeObserver];
}
@end

@interface ObserverManager
//Omitted for brevity
@end

@implementation ObserverManager
NSMutableArray *observers;

+(ObserverObserveeHandle)addObserverToObject:(NSObject *)obj
 forKey:(NSString *)keyPath {
 MyObserver *observer = [[MyObserver alloc] init];
 [obj addObserver:observer forKeyPath:keyPath
  options:(NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld)
  context:NULL];

 ObserverObserveeHandle *details = [[ObserverObserveeHandle alloc]
  initWithObserver:observer target:obj keyPath:keyPath];
 [observers addObject:details];

 return details;
}

@interface SomeViewController

@property (nonatomic, strong) IBOutlet UILabel *resultLabel;
@property (nonatomic, strong) ObserverObserveeHandle *resultLabelMonitor;

@end

@implementation SomeViewController

-(void)viewDidLoad {
 self.resultLabelMonitor = [ObserverManager
   addObserverToObject:self.nameTextField
   forKey:@"text"];
}

@end

@implementation SomeViewController

-(void)viewDidLoad
{
    __weak typeof(self) weakSelf = self;
    self.resultLabelMonitor = [ObserverManager
        addObserverToObject:self.nameTextField
        forKey:@"text" block:^(NSDictionary *changes) {

            typeof(self) sSelf = weakSelf;
            if(sself) {
                NSLog(@"Text changed to %@",
                    [changes objectForKey:NSKeyValueChangeNewKey]);

                //use sSelf if need be
                sSelf.resultLabel.text = @"Name changed";
            }
        }];
}

@end

-(Matrix *)transposeMatrix:(Matrix *)matrix error:(NSError * __autoreleasing *) error
{
    //process
    //if error
    *error = [[NSError alloc] initWithDomain:@"transpose" code:123 userInfo:nil];
}

NSError * __autoreleasing *error;

Weak Type: id

There are several cases where we use the type id. It is not uncommon to see this used in the Cocoa framework itself. For example, in the Xcode-generated code, the IBAction methods have a parameter of type id to denote the sender.

Another scenario is working with objects in an NSArray.⁶ Consider the code in Example 1-35.

@interface HPDataListViewController
    : UITableViewController <UITableViewDataSource, UITableViewDelegate>

@property (nonatomic, copy) NSArray *input;

@end

@implementation HPDataListViewController

-(void)tableView:(UITableView *)tableView
    didSelectRowAtIndexPath:(NSIndexPath *)indexPath

{
    NSUInteger value = [self.input objectAtIndex:indexPath.row].someProperty;
    //proceed
}

@end

In the method tableView:didSelectRowAtIndexPath:, we expect the array input to consist of objects of some type—let’s call it ClassX—that has a property someProperty.

This code looks great, and if you try it out, you will most likely get the correct result. We know that as long as the object at the corresponding index responds to the someProperty selector, this code will work as intended. But if the object does not respond to the selector it may result in an app crash.

It is assumed that the compiler does not need to know the type information, because the runtime will know which object and method to invoke. But the fact is that the compiler does require a fair bit of detail—specifically, it must know the sizes of all the parameters and the type of the return value so that it can have correct instruction sets for pushing and popping the values on to and off of the stack. For example, if the method takes two parameters of type int, 8 bytes need to be pushed to the stack.

Normally, we do not need to take any steps for this to happen, though. The compiler obtains the parameter information by looking at the name of the method we are trying to invoke, searching through the included headers for methods matching the invoked method name, and then getting the parameter lengths from the first matching method it finds.

The good part is that this works most of the time. It fails when there are multiple classes that have exactly the same method signature (i.e., name and parameters).

Consider a scenario in which, at compile time, the compiler zeros in not on the ClassX class but say, for example, the ClassY object. The method may not return an NSUInteger, but maybe an NSInteger or even an NSString. In another scenario where we expect an NSUInteger, it may return a reference to an object that we are supposed to invalidate or cleanup ourselves (e.g., CGColor or CGContext), resulting in a memory leak.

Solution to the Problem

Why does the type mismatch happen? How can the compiler be so naïve? It does the hard work of resolving the object for the message to be sent. The compiler is responsible for generating accurate instructions (i.e., the correct values to pass to the objc_msgSend method).

Fortunately, it is not hard to solve the problem of incorrect type matching by the compiler. There are two parts to the solution.

First, we must configure the compiler to report an error if it finds multiple matches for selectors on id objects. This is controlled by the Strict Selector Matching setting, which is turned off by default. It corresponds to the -Wstrict-selector-match flag passed to the compiler. Turn it on to generate warnings when the compiler finds two selectors that have different parameter or return types.

Figure 1-14 shows the project settings in Xcode.

Figure 1-14. Xcode settings for strict selector matching

There are a few issues related to the use of this option:

• Built-in frameworks will result in several warnings, even though the majority of them will never cause you any trouble.

• You will still not be able to catch issues when working with a class rather than an object.

• It will not help if you did not import the header with the correct definition.

That brings us to the second part of the solution: give enough information to the compiler to generate messages against correct types. You can do that by using a strong type (ClassX in our case). Example 1-36 shows the changes to be made to the code.

Example 1-36. Using strong types

-(void)tableView:(UITableView *)tableView
    didSelectRowAtIndexPath:(NSIndexPath *)indexPath

{
    ClassX *item =  (ClassX *) [self.input objectAtIndex:indexPath.row];
    NSUInteger value = item.someProperty;
    //Proceed
}

In a nutshell, when working with methods that are commonly named, be sure to avoid using id. Use a specific class instead.

Object Longevity and Leaks

The longer the objects live in memory, the higher are the chances of memory never being cleaned up. Avoid long-lived objects as much as possible. Of course, you will need references to key operations all over your code, and you will not want to waste time re-creating them each time. Due diligence must be done on their usage.

One of the most common scenarios of long-lived objects is singletons. Loggers are a good example of this—they are created once but never destroyed. We discuss these kinds of scenarios in depth in the next section.

Another scenario is using global variables. Global variables are dreaded in programming.

Complex object graphs provide fewer opportunities for reclaiming memory, and hence increase the risk of crashes due to memory exhaustion. App responsiveness can suffer if the main execution thread is forced to wait for subthread operations such as network or database access.

Singletons

The singleton pattern is a design pattern that restricts the instantiation of a class to one object. In practice, the instantiation occurs near the start of the app and the object never dies.

Having an object that has a very long life compared to the overall life of the app is never a good idea. And if the object becomes the source of other objects (more like a service locator), there is risk of memory buildup if the locator is not correctly implemented.

Singletons are necessary—there is no doubt about it. But how they are implemented plays an important role in determining how they will be used.

Before we fully discuss the problems that singletons introduce, let’s take a step back to better understand what singletons are and why we really need them.

Singletons are useful when exactly one object is needed to coordinate actions across the system. We need singletons in several scenarios:

• Queuing operations (e.g., logging and instrumentation)

• Shared resource access (e.g., cache)

• Pooling constrained resources (e.g., thread pool or connection pool)

Singletons, once built up and ready to use, continue to live until the app is shut down. Loggers, instrumentation services, and the cache are good examples of singletons.

More importantly, these singletons are generally initialized at app startup, as other components that intend to use them get them ready. This increases the app load time.

What is the way out? There is no one solution that can be used. The memory constraints become visible as you start integrating more and more off-the-shelf solutions, especially if you do not have their source code.

Here are some guidelines that you can use:

• Avoid singletons as much as possible.

• Identify the sections that need memory—for example, an in-memory-buffer for instrumentation (used before flushing to the server).

  Look for ways to minimize the memory overhead. Note that you will have to trade off with something else. If you keep the buffer smaller, you will have to make more frequent server trips.

• Avoid object-level properties as much as possible, as they will stay with the object forever. Try to use local variables.

Finding Mystery Retains

A class may have been well designed, and the objects well retained, and there may or may not be memory leaks. It may, however, be a good idea to be able to get the reference graph. This brings us to the question, is it possible to find all the retains on an object?

The answer lies in the pre-ARC method retain. All we have to do is get the count of the method invocation. ARC does not allow you to override or call it, but you can temporarily disable ARC for the project (see Figure 1-15 for the details).

Figure 1-15. Disabling ARC in a project

Then, add the code given in Example 1-39 to all your custom classes. The code not only logs the call to the retain method but also prints the call stack so that you can get details of where exactly it has been invoked, and not only how many times.

#if !__has_feature(objc_arc)
-(id) retain
{
    DDLogInfo(@"%s %@", __PRETTY_FUNCTION__, [NSThread callStackSymbols]);
	return [super retain];
}
#endif

Best Practices

By following these best practices, you will largely avoid any trouble with memory leaks, retain cycles, and large memory requirements (you may want to print out a copy of this section to hang in your workstation for quick reference):

• Avoid huge singletons. Specifically, do not have God objects (i.e., objects that do too much or have too much state information). This is an antipattern, a common solution pattern that gets counterproductive sooner rather than later.

  Helper singletons like loggers, instrumentation services, and task queues are good, but global state objects are bad.

• Use __strong references to child objects.

• Use __weak references to parent objects.

• Use __weak references to off-the-graph objects such as delegates.

• For scalar properties (NSInteger, SEL, CGFloat, etc.), use the assign qualifier.

• For block properties, use the copy qualifier.

• When declaring methods with NSError ** parameters, use __autoreleasing with the correct syntax: NSError* __autoreleasing *.

• Avoid directly referencing outer variables in a block. weakify them outside the block and then strongify them inside the block. See the libextobjc library for helper macros @weakify and @strongify.

• Follow these guidelines for deterministic cleanup:

  • Invalidate timers.

  • Remove observers (specifically, unregister for notifications).

  • Unlink callbacks (specifically, nil any strong delegates).

Memory Usage in Production

Note that whatever setup you do to your Xcode, it will work only when debugging the app on a device. You really do not know what additional variations may arise until the app has gone live and been used by tens of thousands of users, if not millions.

To be able to profile your app in varying scenarios, use instrumentation. Send periodic information about your app to the server—memory consumed, especially if it grows beyond a threshold, along with a breadcrumb navigation trail is a great option.

As an example, if the memory consumption is beyond 40 MB, you may want to send the details of what screens the user navigated to and key operations performed. Another option is to keep track of memory consumption and log it locally at periodic intervals, and then upload the data to the server. You can use the code in Example 1-40 to find the memory used as well as the available memory.

//HPMemoryAnalyzer.m

#import <mach/mach.h>

vm_size_t getUsedMemory() {
 task_basic_info_data_t info;
 mach_msg_type_number_t size = sizeof(info);
 kern_return_t kerr = task_info(mach_task_self(), TASK_BASIC_INFO,
  (task_info_t) &info, &size);

 if(kerr == KERN_SUCCESS) {
  return info.resident_size;
 } else {
  return 0;
 }
}

vm_size_t getFreeMemory() {
 mach_port_t host = mach_host_self();
 mach_msg_type_number_t size = sizeof(vm_statistics_data_t) / sizeof(integer_t);
 vm_size_t pagesize;
 vm_statistics_data_t vmstat;

 host_page_size(host, &pagesize);
 host_statistics(host, HOST_VM_INFO, (host_info_t) &vmstat, &size);

 return vmstat.free_count * pagesize;
}

Summary

Now that you have a deeper understanding of how memory is managed by the iOS runtime and the basic rules to avoid retain cycles (the single largest source of memory leaks), you can now minimize your app’s memory consumption and lower its average and peak memory requirements.

You can use zombies to keep track of overreleased objects, which are one of the most common sources of app crashes.

The code in this lesson can be used to track memory usage in production, not just in the test lab.