Memory debugging tool description-demo, memory debugging tool demo

Memory debugging tool description-demo, memory debugging tool demo

In the development process, we sometimes encounter Memory leakage. Apple provides a powerful Instruments tool to detect iOS app memory leaks.

The following describes the Instruments tool and demonstrates how to detect memory leakage through instances.

• Instruments Tool

Instruments is a performance analysis and testing tool used to dynamically track and analyze OS X and iOS code. It supports multithreading, recording and playback, and graphic user interface operations. Although there are many Instruments, they are not all used in the actual development process. Below are some commonly used analysis tools.

• Leaks)

Leaks mainly checks memory usage, leaked memory, and provides statistics on Class Object allocation and Memory Address history of all activity allocation and leakage modules;

Change the project ARC to MRC, for example:

Create a class and declare an object:

#import <Foundation/Foundation.h>@interface Person : NSObject@property(nonatomic, assign) NSString *str;@end

Simulate Memory leakage:

-(void)clickEvent{    Person *person = [[Person alloc] init];    [person retain];    person.str = @"test";}

• Run the project, switch to the iOS simulator, and click the test button to "button" several times"
• Switch to Instruments and you will find that if there is no leakage

• Of course, this is a leak. There is a red X in the "Leaks" column. 6. Memory leakage.

　　

• Click pause, and then click the "Leaks" column.

• Click "navigation bar" to switch to "call tree" mode.

• The list shows the calling logic for Memory leakage:

 

• After the check box is selected, double-click it to find the memory leak location.

• Separate By Thread: Separate threads. Only in this way can the threads with the largest CPU usage be clearly seen in the call path. Each Thread should be considered separately. Only in this way can you find the "heavy" threads that occupy a lot of CPU and separate them by thread for analysis. This makes it easier to find the problematic threads that consume resources. Especially for the main thread, it must process and render all interface data. Once blocked, the program will be stuck or stop responding.

• Invert Call Tree: trace stack information from top to bottom. this option allows you to quickly see the method call path, which is the most time consuming by the method CPU (this means that the method in the table you see will have been sampled from 0th frames, which is usually what you want, only in this way can you see the method with the deepest CPU call fees), such as FuncA {FunB {FunC }}, after the check box is selected, the stack displays the outermost C of the deepest call level with C-> B->. reverse output call tree. Display the method with the deepest invocation level at the top, making it easier to find the most time-consuming operation.

• Hide Missing Symbols: If dSYM cannot find your APP or call the system framework, the call method name can only be seen in the table as a hexadecimal value, by selecting this option, you can hide these symbols to simplify data analysis.

• Hide System Libraries: Indicates hiding System functions. It is more useful to call this function. After you select this option, the time-consuming call path will only display the code that is consumed by the app, performance analysis is generally related to the time consumption of our own code rather than the system. basic is required. note that some code time consumption will also be included in the system level. It is very useful to compare the execution path before and after the check. because generally, you only care that the time spent by the cpu on your code is not on the system, and the system library files are hidden. Filter out various system calls and only display your own code calls. Hide missing symbols. If the dSYM file or other system architecture is missing, many strange hexadecimal values will appear in the list. Use this option to block these interference elements, so that the list can be restored.

• Show Obj-C Only: Only Show oc code. If your program is a program like OpenGl, do not select the lateral check because it may be C ++

• Flatten Recursion: a recursive function. Each stack traces an entry and is combined for Recursion. Merge multiple stacks produced by the same recursive function (because the recursive function calls itself) into one.

• Top Functions: Find the most time-consuming function or method. The sum of the time a function spends in the function and the total time it takes to call the function. Therefore, if function A calls function B, the Time Report of function A is added to the time spent by function. the time spent is very useful because it allows you to pick up the maximum time number each time you go down to the call stack and return to zero in your most time-consuming method.

• To add other tools:

• Some other additions to the interface:

• Show the CPU Data on the left to view the consumption of each CPU
• Show the Instruments Data in the middle shows the overall consumption
• Show the Thread Data on the right shows the CPU consumption of each Thread.