Objective C memory management (III): Debugging Memory leakage

1) The memory problem is that the earlier the discovery, the lower the cost of solution. So the most important thing is to understand objective.
C Memory Management follows the practices and coding specifications I mentioned earlier. In addition, some stress and memory tests are required in each iteration cycle to detect problems as soon as possible.

 

2) use clang static detection tools. Clang has been integrated in Versions later than xcode 3.2. Build-> build & analyze can be run. It can detect most memory leaks caused by negligence. For example, alloc does not have release. It is the result of a static test. Clang clearly tells you that there is a potential memory leakage in line 1, that is, there is no release for labels with alloc.

Figure 1 static clang Detection

3) if the static detection tool cannot solve the problem, more analysis and instruments tools are required.

A) first, we need to reproduce the problem and find out which operations are prone to memory leakage. It is mainly determined by some tests and reasoning, such as identifying which operations are repeated, and the memory growth is obvious or crash occurs.

B) use the instruments tool. Instruments is inProgramInject someCodeTo dynamically detect memory allocation and leakage issues. Run-> run with perfomance tools-> leaks. Is the result of running leak instrument. If leak is caused by your code, you can also view the leaked Code directly.

Figure 2 leaked Blocks

 

Figure 3 leaked code

C) there is also an instrument named allocation, which can monitor the memory allocated in real time. A) Step inference is often effective. You can use run-> run with perfomance tools-> allocations to start the program, or you can use window-> library-> allocations after instruments is started.

 

4) You can contact your colleague codereview to find problems. Sometimes Memory leakage is caused by some misunderstanding. For example, I always thought
-Viewdidunload is called after this view is unloaded, so I will do some cleanup work in it, such as remove
Eventhandler and so on, later I realized that this function was called only when the memory was insufficient and it was necessary to unload the view. This misunderstanding caused me to spend a week solving a memory leakage bug. In another example, one of my colleagues thought that [nsdate new] was the current generation time and does not need to be released. This is also a relatively low-level misunderstanding.

 

5) some memory problems may be caused by caching and may not always be leaked. For example, in three20 (Facebook iPhone Library), some network images are cached in the memory by default for performance considerations. [uiimage imagenamed:] will also put the image into the system cache. This is not a leak, but sometimes it may cause insufficient memory.