Memory leakage during xcode debugging.

Before you start: If you use arc, ignore this article.

The performance problems of these two projects have been put on the table. Due to the absence of memory check for a long time, the current iPad version is a little too slow.

 

Then, I checked the memory for several consecutive days. Today, I am free to write about how to check memory Leakage Based on my own usage.

 

The main memory leakage methods I have encountered:

1. The most common one is to apply for a reference and forget to release it. Specifically, alloc, retain, copy, new, C's malloc, realloc, C ++'s new, etc. of OC are used, and there is no corresponding release, free, and delete. This is a one-way leak.

2. Retain cycle. For the oc-based counting method, there may be a retain cycle. Two conditions: 1. In a, B retakes B, and B retakes A. Each of them increases the Count of each other. This ring can be changed to multiple layers, that is, a-> B, b-> C, C-> D ,.... z-> A. Of course, the more intermediate layers, the more difficult to detect. 2. The count reduction operation is performed in dealloc, while dealloc needs to be counted as 0 if it is called. These two conditions are added, leading to counting locking and Memory leakage.

 

First, let's talk about how to find it.

1. First, use analyze build to view the memory warning in the category.

In general, we can find that the local variables forget the release, or the release is interrupted midway through.

2. Use the leak monitoring in instruments directly.

After applying for the memory, there is no pointer pointing to this memory, which can be considered as a leak. This check usually detects this status.

3. Use mark heap of allocation in instruments.

Perform repeated operations and mark the memory after each scenario ends. If the operation scenario is not leaked, the increase in memory should be 0. This check is used to detect which objects are added between mark points. In addition, it takes several times for the mark to be accurate. If you do not see the memory increase twice, you can find the problem.

In instruments, you can see what objects exist, call history, and call stack. At this time, it is roughly determined that the object in the class has been leaked.

4. Heavy Load Method.

Although I know which class has been leaked, I sometimes don't know what the problem is. My own method is to reload the retain and release methods and add breakpoints if it is a self-compiled class. In this way, we can monitor where this object is retained, but it is not released.

 

Then, make the following changes.

1. What do you need. If release is missing, add release. If release is missing, add free.

2. Use autorelease properly. For upper-layer events that are returned, or when there is a return or other interruption between the alloc object and the release. We recommend that you use autorelease.

3. Use assign properly. Retain cycle is essentially a redundant two-way retain. For example, you should determine which object is the root and which one is the branches and leaves. You do not need to manage the roots, but you only need to know where the root is. Therefore, the variables that are purely for positioning and attributes are changed to the assign method, such as delegate.

 

Over

 

PS:

1, if the use of instruments is not very clear, you can watch this video https://developer.apple.com/videos/wwdc/2010? Id = 311. But it seems that you want to log on. Of course, you can use almost omnipotent Google and extremely powerful stackoverflow for search tutorials.

2. The new automatic reference counting method, arc, has not been carefully touched, but it is no longer possible to write retain and release on its own. The leakage estimation of non-corresponding methods is gone. However, according to my own rough understanding, arc only adds retain and release to the appropriate place by the system. Therefore, the retain cycle problem should still exist. Then, because retain and release cannot be reloaded, the reload method is invalid.

So, if you use the arc, it will directly float.

3. The system library itself will also leak the memory, so. If you cannot find the memory, you should first put it aside.

4. It's time to learn about arc and convert it to arc. Otherwise, memory problems will keep bothering you...

PS over