IOS Development notes (5) phone memory leakage: leaks Tool Guide

Find iPhone Memory leakage: leaks Tool Guide Original address: http://www.mobileorchard.com/find-iphone-memory-leaks-a-leaks-tool-tutorial/
See also: http://www.iposei.com /? P = 127

My game development is coming to an end. Recently, I often use the instruments tool. I found it very helpful for tracking memory leaks in the game. Since I discovered that instruments are so useful, I think writing an article about how to use it to track memory leaks can also help others.

What is memory leakage? Why do I need to care about memory leakage?

... This section is omitted...
Visit Wikipedia to obtain more information about memory leakage.

How do I know that the memory has been leaked?

Some memory leaks can be easily discovered by reading the code, and others are difficult. This is why instruments is needed. Instruments has a "leaks" tool that accurately tells you where memory leaks have occurred so that you can locate and fix leaks.

Example Program

I wrote an example program, which may leak memory in two places, one in objective-C View Controller and the other in C ++ class. The routine can be obtained from here. The following code is extracted from the routine and contains the code for tracking memory leaks.

// Leaky excerpts-see GitHub for complete source

-(Void) viewdidload {
[Super viewdidload];

Leakyclass * myleakyinstance = new leakyclass ();
Delete myleakyinstance;

Mmyleakystring = [[nsstring alloc] initwithuf8string: "I'm a leaky string."];

[Self dosomethingnow];
}

-(Void) dosomethingnow
{
Mmyleakystring = [[nsstring alloc] initwithuf8string:
"Look, another alloc, but no release for first one!"];
}

// Leaky excerpts-see GitHub for complete source

Leakyclass: leakyclass ()
{
Mleakedobject = new leakedobject ();
}

Leakyclass ::~ Leakyclass ()
{
}

I will first compile instrumentstest in debug mode and run it on the iPhone. After completing this step, I will start instruments.

When you start instruments, you can select what you need from a bunch of instruments tools. Select the iPhone on the left side and double-click "leaks" in the icon on the right side:

Then you will see the following window:

Make sure that your iPhone is connected to your computer. in the upper left corner of the window, you will see a drop-down menu that says "launch executable ". Click it and make sure that your iPhone (not your computer) is selected as the active device. Move to "launch executable" and you will see a list of all installed iPhone programs. Find the program that you want to use the "leaks" tool (in this example, instrumentstest) and click it.

You are ready. Click the red "record" button to start the program and start recording each memory allocation operation in the program. It automatically detects memory leaks every 10 seconds.

You can change the time for automatic detection. You can also perform manual detection. (when detecting memory leaks, the program will pause for about 3-5 seconds. If you want to perform a test and a memory check, this pause will disturb you ). I usually set it to manual control and click the "check for leaks" button when I need it (for example, check it after loading the new game mode, when you exit the game and return mm, check ). Click "leaks" and use the view-> detail button in the upper right corner to set and view the option value. In this example, I set it to auto.

After the program runs for a period of time, the automatic memory detection will detect two memory leaks. Great! What should I do now?

Extended Detail View

Instruments is very lazy and does not clearly point out what to do next. Note the row of buttons at the bottom of the window. Have you seen the button consisting of two rectangles? When you move your mouse over it, the system prompts "extended Detail View ".

Click this button, and a window will pop up on the right, which provides a variety of details about memory leakage. Click a memory leak. The extended Detail View displays the complete call stack of the leaked Memory code. In the above example, click the first memory leak prompt, which occurs in [nsstring initwithuf8string]. If you select the highlighted step in the call stack, you will see that the last call of the program is [instrumentstestviewcontroller viewdidload].

Double-click a line in the extend Detail View. It opens the xcode window and displays the problematic code. This is a great feature.

In this example, the first nsstring allocation is leaked, and you need to do some processing. This is a very simple example, but it is more difficult to find out why a leak occurs. Let's take a closer look at the example. In viewdidload, we allocate the string to the memory, as shown below:

Mmyleakystring = [[nsstring alloc] initwithuf8string: "I'm a leaky string."];

In dealloc, we use the following method to release

[Mmyleakystring release];

Your intuition may be that this will not leak, but the search code is useful to the location of mmyleakystring. In dosomethingnow, it is used like this:

Mmyleakystring = [[nsstring alloc] initwithuf8string:
"Look, another alloc, but no release for first one!"];

Note that we declare a new string and point the mmyleakystring to it. The problem here is that we are not changing the mmyleakystring to release the memory it originally pointed. So the original string is still in the heap, and we cannot release this part of memory. The release operation in dealloc actually releases the memory occupied by the string we declare in dosomethingnow, because this is what the pointer refers.
To fix this problem, we can change dosomethingnow to the following code:

-(Void) dosomethingnow
{
[Mmyleakystring release];
Mmyleakystring = [[nsstring alloc] initwithuf8string:
"Look, another alloc, but released first one!"];
}

In this Code, the memory occupied by the first string is released before mmyleakystring is specified to the new string. Re-compile and run the program, and you will see only one memory leak. Of course, there may be a better way to handle nsstring in the project, but if you do so, you can fix this leakage problem.
Let's take a look at the second leak. Click the leak prompt to see what causes memory leakage. This leak was discovered by the leakyclass: leakyclass () constructor:

Double-click it in the call stack, and the problematic code will appear again in xcode.

We can see that a new leakedobject object is declared in the constructor, but the Destructor is not deleted, which is not good. Each new operation requires a corresponding delete operation. So we change the destructor to the following:

Leakyclass ::~ Leakyclass ()
{
If (mleakedobject! = NULL)
{
Delete mleakedobject;
Mleakedobject = NULL;
}
}

Re-compile and run without memory leakage!
These two examples are simple, but they show that instruments can be used to track memory leaks in object-C and C ++.
Fix your memory leakage. Remember, a program without memory leakage is a good one. Http://www.cnblogs.com/mobiledevelop/tag/memory management/