Objective-C Fundamentals

Bringing memory leaks under control with Instruments
281
Additional schemes can be helpful
Although the Xcode project templates produce a project with one scheme by default,
you can add other schemes to your project.
You could, for instance, create different schemes for “light” and “full” versions of
your application. Using different C preprocessor defines, you could configure your
source code with code similar to the following
#ifdef FULL_VERSION
...
#endif
to alter the behavior of the two application variants without needing to maintain two
completely separate Xcode projects.
other functions that need to be updated. Luckily, Xcode provides support for performing
such tasks in a more efficient manner. From a terminal window, you can navigate
to your project’s folder and use the following command:
tops replace "NSLog" with "LogAlways" *.m
This command replaces all calls to the NSLog function with calls to LogAlways. It performs
this task for all *.m source code files found in the current directory. Tops is
smart enough not to alter other references to NSLog, such as those in comments; it has
built-in knowledge of Objective-C syntax and performs more than a simple search and
replace. For safety purposes, if you want to double check what a call to tops will perform,
add the -dont argument to the command line. This argument causes tops to
perform as normal, except it won’t modify a single file. Instead, it sends to the console
a list of changes it would have performed had the -dont argument not been present.
It’s also possible to perform this task directly from Xcode’s text editor: move the
mouse over a call to NSLog, right-click, and select Refactor. In the dialog box that
appears, type in LogAlways and click the preview button. You’ll get a list of files Xcode
will change, and selecting each one will graphically highlight the changes that will
occur once you click the Apply button.
That sums up improved the NSLog situation—but there’s another problem with the
sample application. If you run the application, it appears to be working correctly, but
with time (and especially on a real device), it will eventually crash. It has a memory
leak, but how do you find it?
14.3 Bringing memory leaks under control with Instruments
In Xcode select Product > Profile. In addition to the iOS Simulator, you’ll see an application
called Instruments. From Instruments’ initial screen, select the Leaks trace
template and click Profile. A screen similar to figure 14.4 will be displayed.
While Instruments is monitoring the execution of your application, select the Allocations
instrument and scroll around the UITableView. Notice that the line labeled All
Allocations (representing all memory allocated in the application) keeps indicating that