iOS Performance Tuning series: Dynamically analyze memory leaks with instruments

Hard Canton: "iOS Performance Tuning Series", the second, continuously updated, welcome attention.

The first article introduces the static analysis of analyze to the app, can find out the memory leak problem in the application, for some memory leaks can not be solved by static analysis, it could be discovered by dynamic analysis, and the analysis is more targeted.

From the beginning of this article, we introduce the powerful analysis tools provided by Xcode instruments, memory analysis is just one feature in instruments, and other features follow up.

Dynamic analysis of memory leaks using instruments

The leaks feature in instruments is primarily used to analyze memory leaks or to experiment with memory leaks in the iOS Performance Tuning series: Analyze Static Analysis:

1//Intercept some images 2 + (uiimage*) Getsubimage: (unsigned long) Uluserheader 3 {4     UIImage * sourceimage = [UIImage imagenamed:@] He Ader.png "]; 5     cgfloat height = sourceImage.size.height; 6     cgrect rect = CGRectMake (0 + uluserheader*height, 0, height, height) ; 7       8     cgimageref imageref = Cgimagecreatewithimageinrect ([sourceimage cgimage], rect); 9     uiimage* Smallimage = [UIImage imagewithcgimage:imageref];10     //cgimagerelease (imageref);     return Smallimage ; 13}

Commenting out the line Cgimagerelease (IMAGEREF), even in an arc-enabled environment, will still cause a memory leak (arc is-only for nsobject).

To start dynamic analysis using leaks, click the Xcode Product menu profile to start instruments:

Selecting leaks will automatically start the leaks tool and the iOS emulator:

Leaks starts recording when it starts, and you can see the memory footprint in leaks as you work with the app running on the emulator.

Note: If your project uses arc and as you work, the view is constantly turned on or off, the memory may continue to rise, but this does not necessarily mean there is a memory leak, and the timing of the ARC release is not fixed.

The top of the leaks is divided into two columns: allocations and leaks, and the curve on the right represents memory allocation and memory leak curves.

Click on the second column leaks, for memory leak analysis, the lower left corner will appear leaks debugging options:

It is recommended that the snapshot interval interval be set to 10 seconds, and the automatic Snapshotting,leaks will automatically perform a memory capture analysis.

Before and after you suspect a memory leak, you can click Snapshot now to manually capture it.

The following is a view that switches to the call of the + (uiimage*) Getsubimage: (unsigned long) Uluserheader function in my app to discover a memory leak:

The leaked object table shows the type, number, and memory space of the memory leak.

Clicking on a specific memory leak object in the right detail window will cause the leak to appear where the black avatar represents the most likely location.

Leaks has successfully identified [Cmtool getsubimage:] This function:

Memory leak Dynamic Analysis tips

Skilled use of leaks will be more accurate in the memory leak judgment, in the operation that can lead to leakage, more use snapshot now manual capture.

You can set the auto capture interval to 5 seconds if the device performs well at the beginning.

With ARC projects, general memory leaks are caused by malloc, custom structures, and resources, paying more attention to these areas for analysis.

Causes of memory leaks after arc is turned on

There is no memory problem with open arc, and Apple has a famous saying: Arc is just for nsobject.

Using the memory allocated by malloc in iOS, ARC is not processed and needs to be handled by itself.

The cgimageref in the example is also a pointer to an image, and arc will not be processed.

Excerpted from http://www.cnblogs.com/ym123/p/4311670.html

Record, for the better of myself!

Bean Electric Rain

iOS Performance Tuning series: Dynamically analyze memory leaks with instruments