Instrument Debug Memory leak-leaks

Original blog, reprint please indicate the source
Blog.csdn.net/hello_hwc

Welcome to my iOS SDK detailed column
Blog.csdn.net/column/manage.html?alias=huangwenchen-ios-sdk

Foreword: The plan is July update instrument and debug related blog, but today just encountered a memory leak problem. The May data Persistence section still has three or so not updated, June focused on multi-threaded development. So here is a simple write instrument leaks use it. How to open leaks

Xcode-open Development tool-instruments

You'll see a lot of tools when you open

Select Leaks Open
Allocations records memory allocations, which are used to optimize the use of memory leaks to analyze memory leaks. The memory leak caused by arc is the reference loop.

Then we run the next small project, this project is next to update an asynchronous network download TableView image of the early prototype.

Here to mention is that my blog has written so many articles, or did not involve a good open source library, this part of the follow-up I will write. After all, the actual development of the open Source Library is also important to choose, and will greatly improve efficiency. But what I want to do is to master the basics first, which determines the depth of understanding.

Project Downloads for memory leaks
Look at the effect chart

At first glance it's good, TableView is very fluent, the image can be lazy to download (the cell screen to download again), this is what I want to prototype. However, the curious use of leaks analysis

I Rub

Then we open the leaks and see where the error occurred.

First select leaks and leaks by backtrace. Here you can see the memory leaks of those objects, the number of leaks, this is a simple look, not too much debugging significance.

Then look at the call tree, because it gives us a ballpark position, sometimes it gives us a precise position, but it depends on luck.

Then, again, select invert call tree and hide System Library

Then we know that the location of the memory leak is here in the Nsoperation subclass.

Then double-click any row in the picture above to jump to the place where the memory leaks (in fact, many of the memory leaks will be found at this point).

Then we choose a part of circles & Roots that is useful for arc debugging, and we can see the detailed ARC reference counting process.
Click the leaks icon to select

Then we see the details of the reference count (ARC is the automatic reference count, the count is 0, and the object will be released) as shown in the small red circle click the large red circle can draw the graph of the object reference loop, but unfortunately there is no intuitive drawing.

Then, first we find our custom object, we found the object of Downloadimageoperation, this object is inherited from Nsoperation, normal after the task is completed should be released. There seems to be no release. To confirm, add the log code at the end of the downloadimageoperation to see if it is released

-(void) dealloc{
    NSLog (@ "Dealloc");
}

Run the program again, sure enough not to be released, there must be a problem here.

Finally, we click on the cut in the small red circle similar to the above figure, in detail, the reference count of this object changes as shown
Here all indicates that all reference count changes unpaired represents those pairs of changes (pairs are leaks recognize the corresponding +1,-1) by group, the related changes are grouped, and bytime will list the reference count changes in order.

We chose unpaired and Bygroup, and saw as pictured

Look in order (leftmost label)

4 here, the reference count is one, which is correct, because to be here normal is supposed to be operationqueue save a operation reference.
So, we crossed off the normal

To continue to see, download start label 6 and 8 are corresponding, continue to exclude problems here (of course, the problem can not appear here, this is the system's API, will be released, is simply to teach people how to see)

Again, +1 of the remaining label 7 and 11,7 is normal for operation allocation thread, should be +1, and 11 is our problem (most delegate will not make reference + 1).
Let's look at the document again.

@property (ReadOnly, retain) id< nsurlsessiondelegate > Delegate

The original agent is retain Ah, not assign or weak. So the reference ring is formed.

So what to do. There are questions to look at the document, we see the picture in which the reference count plus one is

+ (Nsurlsession *) Sessionwithconfiguration: (nsurlsessionconfiguration *) configuration delegate: (id< nsurlsessiondelegate>) Delegate Delegatequeue: (Nsoperationqueue *) Queue:

Look at the file and find this place.

So, we have to manually disconnect the strong reference, so we manually to disconnect

-(void) setoperationfinished{
    [self.session invalidateandcancel];
    [Self willchangevalueforkey:@ "isfinished"];
    [Self willchangevalueforkey:@ "isexecuting"];

    executing = NO;
    finished = YES;

    [Self didchangevalueforkey:@ "isexecuting"];
    [Self didchangevalueforkey:@ ' isfinished];

}

Then run the next look, can be normal dealloc.

2015-06-05 10:28:36.814 asyncimagetableviewdemo[1245:83664] dealloc
2015-06-05 10:28:36.954 ASYNCIMAGETABLEVIEWDEMO[1245:83664] Dealloc

With leaks analysis, there is no memory leak.

Summary: In fact, most of the problems in the double click on the code section above can be solved, a few problems need detailed analysis of the arc reference process.