Use Xcode instruments leak to troubleshoot memory leaks _ tool usage

Written in the previous: There are a lot of writing leak tutorial articles, at that time in use has been stuck in Step4, can not locate memory leaks code location, and finally found this article Step5 said dSYM file. No other articles were mentioned.

--->xcode compile the project, we will see a dsym file with the same name, dSYM is a staging file that holds the 16-in-function address mapping information

There is a problem, before running their own demo when Cmd+i, has been flashing back, the specific reasons did not find out. Then Cmd+r first, and then through the entrance of the following will not flash back ~

After the long-winded, look at the text reproduced below ~

----

After IOS 5.0 Apple introduced the Xcode compiler feature arc (Automatic Reference counting, automatic reference count) to help developers manage memory, but in order to pursue the high performance of the app and reduce the size of the installation package, There are many times in the job that require us to manually manage memory. Cattle developers can not guarantee that they write code 100% No memory leaks, the memory leak is not terrible, terrible is our time and energy spent a lot, but the memory leak is still unresolved, that is, affect the efficiency of their own mood.

The following explains the memory debugging artifact in Xcode---instruments leak, either a rookie of iOS development or an experienced developer, using instruments leak debug A memory leak is one of the essential skills.

Less nonsense, the next start to the pancake pie ...!

Step1:

To create an arc based test demo, part of the test code is as follows:

The above lines of code as app Agent Portal Method,ios developers should be the most familiar, because the creation of a manual memory engineering, the memory leak code line can be positioned at a glance.

Step2:

Using leaks to start dynamic analysis, click Xcode's Product menu profile to start instruments:

　　

Click the profile button to compile, oh, the error, if you encounter this situation also don't be nervous, first look at the error message:

　　

Myviewcontroller and Mynavigationcontroller are the macros I defined in the. PCH precompiled file:

　　

Why normal compilation is no problem, in the profile of the compiler pass, in fact, here is not your code to write a problem, the problem is a compilation of profiles on the option:

Open the Project Edit Scheme option

Select profile to set the build configuration to DEBUG, so that in the. pch file, the macros defined #ifdef DEBUG compilation conditions take effect.

Choose Profile Building,ok again, Success ...

Step3:

Enter Instruments homepage, choose Leak Logo

　　

STEP4:

The demo program is also running, the tool display effect is as follows:

The red pillar indicates that the memory is leaking. 　　 How did you see the leak through this tool? Press the Red round button on the toolbar to stop the activity monitoring the memory. Select leak, then point the Middle cross that, select Call Tree

At this point the lower right corner of the call tree can be selected options. Select Invert call tree and hide System libraries, as shown below:

　　

See here, what you most want to know is the project where the code memory leak, OK, below we will locate the memory leak code line.

STEP5:

Looking at the symbol Name column in the red box in the picture, if you guess that 0xedc00 and 0XEDBDA are memory addresses, then it's close to the correct answer, but it's an egg for me. In fact, the mystery is hidden here, Xcode after compiling the project, we will see a dsym file with the same name, dSYM is to save the address mapping information of 16 into the transfer file, we debug the symbols will be included in this file, and every time we compile the project will generate a new dsym File, more details about dSYM, I'll explain in the blog later. Back to the problem above, show 0xedc00 and 0xedbda is because of our project build settings problem, without generating dsym files, can not resolve the debug symbols. Here we will set the DSYM option correctly:

　　

Once you've set it up, re-build it again, and the specific code for the memory leak is found, and the following red box specifies that the method has a memory leak. (I note: The start card here, always locate the memory leak code, and then run the program again, open the instrument after the OK) you just double-click on these methods, you will jump to the specific code, is not very cow fork.

STEP6:

Solve the memory leak problem, will create the VC object release off on OK, and then use instruments leak tool analysis to see, then how to operate, there is no memory leak. Indicates that the memory leak is blocked.

The author through instrument check to be due to afnetworking this library caused by the memory leak, through the access to information learned that the solution is:

The instance of Afhttpsessionmanager is obtained using singleton mode.

The original acquisition of Afhttpsessionmanager in the network request class is done by the following methods

Afhttpsessionmanager *manager = [[Afhttpsessionmanageralloc]initwithbaseurl:[nsurlurlwithstring:urlhead]];

This method is the culprit for the memory leak, so a single instance is needed to get the Afhttpsessionmanager object.

To add a single example to the Afhttpsessionmanager class:

[OBJC] View plain copy static Afhttpsessionmanager *manager;       + (Afhttpsessionmanager *) Sharedhttpsessionmanager {static dispatch_once_t oncetoken;           Dispatch_once (&oncetoken, ^{manager = [Afhttpsessionmanager manager];       Manager.requestSerializer.timeoutInterval = 10.0;              });   Return manager; Use the following methods:

Afhttpsessionmanager *manager = [[Afhttpsessionmanager Sharedhttpsessionmanager] Initwithbaseurl:[nsurl Urlwithstring:urlhead]];

To observe the memory footprint of the instrument, we will find

All small green hooks, no memory leaks, hehe ~

RELATED Links: http://www.cnblogs.com/qiutangfengmian/p/6117856.html