Memory Leak Detection

1. Static analysis

With static analysis, we can get the most initial insight into some of the code's non-canonical places or memory leaks, which is our first step in detecting memory leaks. Of course, there are some warnings that we don't care about to skip.

2. Check for memory leaks with instruments

This method can roughly locate where we have a memory leak. The method is to complete a loop operation, if the memory growth of 0 proves that our program does not have a memory leak in the cycle operation, if memory growth is not 0 that proves that there is a possibility of memory leaks, of course, specific problems need to be analyzed.

For iOS dynamic memory detection, Xcode comes with a tool (instruments): Leaks. God horse, you don't know what this word means? Google, translated by means "leaked."

Usage: Click Product->profile, then select the leaky water pipe leaks, enter the interface, click to run, instruments will begin to automatically detect the memory leaks, in this process, you can run on the mobile phone test project to operate, Graphical interface, the above is allocations, the following is leaks, when a small red pillar appears, there is a memory leak; Click the middle divider in the interface, select the Call Tree option, and then turn the right "Invert called Tree" and "Hide System Libraries "option, you can see exactly which method in that class has a memory leak, double-click the class name, it shows that this method is caused by the memory leak code, OK, next is targeted for code optimization, memory optimization.

Because it is now used in Arc mode, the general leak is the self of the block is negligent, did not use the weak type, or there is a circular application between the two classes of such a low-level error caused. However, some third-party frameworks can also cause memory leaks, for example, a third-party customer service system that uses a micro-customer service in a company project has a memory leak problem.

See: http://blog.csdn.net/lifengzhong/article/details/7739507

3. Code Test Memory leaks

Before we do this, we have to notice whether we have freed all objects owned by the object in the Dealloc method. Observe whether the object's generation and destruction are paired. This is exactly how init (the method of creating the object) and Dealloc will be triggered (simply by walking once to create the object and then dealloc the object once).

Here are some of the more secretive cases of memory leaks that you encounter:

1. Two objects are owned by each other: that is, object a Retain/addsubview the B object, and the B object also retain/addsubview a object. Note: Delegate do not use the Retain property, and the Assign attribute will also result in owning each other.

2. Sometimes it is necessary to release with Removefromsuperview: Specifically, maybe my a object has a B object, B object is added to the C object, and in our design the life cycle of the B object should be the same as the A object; this time only one sentence [b release]/ SELF.B = nil is not able to release the B object (in general, release will make its retaincount-1,[super dealloc] will again all Subview retainCount-1, and B is not a subview, All the last time-1 is gone); so we need to add [b Removefromsuperview] before.

Happy new year

Bean electric Rain 20160208 Chinese monkey Lunar

Memory Leak Detection