(reprint) Ios-instruments use leaks to detect memory leaks

Reprint: http://www.zhimengzhe.com/IOSkaifa/255950.html

The previous article I introduced Instruments's tool classification and basic use method, today I come to you to talk about leaks use method.

In the early development of iOS, there was no arc mode, only the MRC mode, the developer must manage the memory, the process is very cumbersome and easy to cause memory leaks, today's iOS development although the basic use of the ARC mode, but in some cases, we need to manage the memory, slightly careless, Can cause a memory leak, so it is necessary to use a memory leak detection tool.

Let's take a look at how the leaks tool is used.

The first step: Create a new project, the name casually.

In MRC mode, we can simply declare the object of the class and not release it, causing a memory leak, but today we'll look at how the memory leaks appear in arc mode.

Build the project, device options Choose your iphone (choose a real machine), then we open instruments (command+i) (you will find a project on your phone, the project name is the project you just created), Select leaks in the instruments tool to open leaks.

Step two: Start Debugging.

Run the project, at which time Xcode may pop up the following

Don't be afraid, it just tells us, please trust this app on your device

Step: Open settings, general-purpose device Management, your developer account, trust this account

OK, trust finished, and then run the project, no problem!

Then started using leaks, the project Command+control+i open it, after a period of time we will find the following picture shows the situation, there are many green background "check". These checkmark means there is no memory leak, because we tightly open a system default first main window.

Then we can manually add some code that can cause a memory leak.

First create the second view controller Secondviewcontroller, then add a button to the first controller interface in storyboard, click to jump into the second view controller (PS: Do not use storyboard? Invite me to dinner I'll tell you)

Add a bug code to the Viewdidload method in the second view controller

Cgcolorspaceref colorspace = Cgcolorspacecreatedevicergb ();
Cgcolorref COLORREF = Cgcolorcreate (ColorSpace, (cgfloat[]) {1, 0, 0, 0.8});
Uicolor *color = [Uicolor colorwithcgcolor:colorref];
Self.view.backgroundColor = color;

Obviously, without releasing COLORREF, let's test it next.

Run the project, then Command+control+i, and leaks will automatically rerun the project on the iphone and start recording data

Click the button to enter the second interface, let the bug code go through, and then click the blank to return to the previous interface, we will see a red background "fork symbol", which represents a memory leak

Click Pause to move the mouse over the cross and click Lock.

Click on the "Tian" box below and select CallTree

Locate the top three icon in the lower right corner of the tool area, select the middle gear "?"

Check the invert call Tree and hide System Libraries in the options

Double-click any line below the left call Tree to see the code location for the memory leak

The problem has arisen!!! No code location displayed! Don't panic, it's because we didn't set an option

Locate the build Settings in the project, enter the options lookup, locate the Debug information Format below the build Options column, and set its properties to DWARF with DSYM File

Why did you do it?

Because the 0X1000EA6CB and 0X1000EA8C7 under the Symbol Name column are memory addresses, this thing is useless to me. After Xcode compiles the project, we see a DSYM file with the same name, DSYM is a transit file that holds the address mapping information for the 16 binary functions, and the symbols we debug will be included in this file, and a new DSYM file will be generated each time the project is compiled. On the way to show 0X1000EA6CB and 0x1000ea8c7 is because of our project build Settings problem, did not generate dsym files, will not be able to parse debug symbols. Once we have set up to generate the dSYM file, we can view the corresponding code location information.

Then rerun the project, rerun the leaks, click the button again to fill in the second controller to execute the bug code, re-determine the memory leak, switch to call Tree, double-click the problem bar to enter the code location

Finally find out why our COLORREF variable is not released, then we add a line of code on it: Cgcolorrelease (COLORREF);

After testing again, we found there is no memory leak problem!

However, not all memory leaks will be detected, the following situation I think can be a typical example to say.

Using a timer, loop through a word and print the information in the Dealloc method to see if the object is actually released.

Sorry to preach again, everybody don't care.

(reprint) Ios-instruments use leaks to detect memory leaks