Summary of common debugging Techniques for iOS development Xcode

Two of the most common methods:
1, NSLog, the simplest way to view the knot
Whether there is a value, what value, is not the value that you need, and then find the bug.
2, Po command, in the program into the breakpoint, enter the PO variable name in the console, you can also look like NSLog the variable has a value, what value.

Today the main introduction point on the Tall method.

First, Memory Graph

Xcode8 added: Memory Graph solves closure reference loop problems

This time to enter the breakpoint mode, you can view the issue panel, note the right to choose Runtime:

There are a lot of exclamation points stating that there is a problem. Look at the name of the object in memory, there is a closure captures leaked. Expand and click to see this issue corresponding memory graphics displayed in the middle of the panel. Of course, we are looking at the debug page more often:

So, this is a reference loop. Clicking on the purple exclamation mark will show the memory reference graph that Xcode analyzed:

With this diagram it's easy to see: There's a reference loop here.

By the way, by setting parameters in arguments, you print out the length of the app load, including the overall load duration, the dynamic library load duration, and so on.

Add the Dyld_print_statistics field to environment variables and set it to Yes, and the load duration will be printed in the console.

Second, the Xcode debugging skills: LLDB

1. The abbreviation of Po:print object, which represents the text description of the display objects, and prints nil if the object does not exist.
Simply print an object we won't talk about it, let's talk about special application scenarios!
Scenario: You want to know which sub-views a view contains. Of course you can cycle through the sub-view, but only one command is needed to resolve it.
Output view-level relationships (this is a hidden command):

po [[self view] recursiveDescription]

There is also a common debugging scenario, such as you want to print a model. The result of your direct use of the NSLog or PO object is the model address, which is not what we want. What to do? Is there a way out?
The answer is yes. You can rewrite the description method inside the model. However, if the model has a lot of attributes, it doesn't work. You cannot say that the concatenation property is returned in the description method. This is not only cumbersome, but also very poor readability. Here, we can use runtime to dynamically get properties and return. But I do not recommend you to rewrite the description method, I recommend you rewrite the Debugdescription method (as for the detailed introduction and how to rewrite click here), because the Debugdescription method and description method effect, The difference is that the Debugdescription method is called when you use the PO command, and the description method is actually called.
2, P: can be used to print the basic data type.
3. Call: Execute a section of code

call NSLog(@"%@"@"yang")

4, Expr: Dynamic execution of the specified expression

101输出：(int)$0101

5. BT: Print the current thread stack information
If you want to print the thread stack information, use: BT all.
6, Image: Often used to find the stack address corresponding code location:
Give me a chestnut:
Application scenario (array out of bounds) analog code:

NSArray *array = @[@"yang",@"she",@"bing"];NSLog(@"%@",array[3]);

The error message is as follows:

Terminating app Due toUncaughtException' Nsrangeexception ', Reason:'-[nsarrayi objectatindex:]: Index 3 beyond bounds [0.. 2] '* Firstthrowcall Stack: (0Corefoundation0x000000010579734bExceptionpreprocess +1711LIBOBJC. A.dylib0x00000001051f821eObjc_exception_throw + -2Corefoundation0x00000001056d1eeb-[__nsarrayi Objectatindex:] +1553Bgmultimediademo0x0000000104c25550-[viewcontroller Viewdidload] +1924UIKit0x0000000105d5c06d-[uiviewcontroller Loadviewifrequired] +1258.................. +Bgmultimediademo0X0000000104C25ADFMain +111 ALibdyld.dylib0x000000010857268dStart +1 at???0x0000000000000001 0x0+1) libc++abi.dylib:terminating withUncaughtException  of  type nsexception 

If we suspect that the wrong address is 0x0000000104c25550, then we can use the following command to find out where the error code is:

imagelookup--address0x0000000104c25550

After executing the command, the output is as follows:

Address: BGMultimediaDemo[0x0000000100001550] (BGMultimediaDemo.TEXT.text192)Summary:192 at ViewController.m:30

As you can see from the output above, the error location should be 30 lines in the viewcontroller.m file. Isn't it super easy to use? Anyway, I think it works.

Third, Xcode debugging skills: Breakpoints (breakpoint)

Breakpoint, one of the programmer debug Essentials.
1. Conditional breakpoint
After you hit the breakpoint, edit the breakpoint and set the appropriate filter criteria. Here's a quick introduction to the conditional settings:
Condition: Returns a Boolean value that, when the Boolean value is a true trigger breakpoint, normally we can write an expression.
Ignore: Ignores the first n breakpoints, and then triggers the breakpoint to n+1 times.
Action: Breakpoint trigger event, divided into six kinds:
AppleScript: Executes the script.

Capture GPU frame: used for OpenGL ES debugging, capturing the current drawing frame at the breakpoint at the GPU.

Debugger command: Matches the input lldb Debug command in the console.

Log message: Output custom format information to the console.

Shell command: Receive the command file and the corresponding parameter list, the shell command is executed asynchronously, only check "wait until done" will wait for the shell to finish executing debugging.

Sound: Sounds are played when a breakpoint is triggered.

These functions can be tried in the process of debugging the program, to be honest, I use the settings condition more.
Options (automatically continue after evaluating actions option): When selected, indicates that the breakpoint does not terminate the run of the program.

2. Abnormal Breakpoint
An exception breakpoint can quickly locate an exception that does not meet a particular condition, such as a common array out-of-bounds, which makes it difficult to navigate to the wrong location with exception information. At this point, an abnormal breakpoint can work.
To add an exception breakpoint:

To edit an exception breakpoint:

Exception: You can choose to throw exception object types: OC or C + +.
Break: The source of the thrown exception received by the Select breakpoint is the throw or catch statement.

3. Symbol Breakpoint
Symbolic breakpoints are created in the same way as an exception breakpoint, and you can specify a method to break execution in a symbolic breakpoint:
For example, in a common scenario, I want it to execute to the Viewwillappear method in the Viewcontroller class to break execution:

Symbol:[viewcontroller Viewwillappear:] That is, [class name Method name] can be executed into the specified method of the specified class to start the breakpoint. If only viewwillappear: that is, the method name, it executes to the viewwillappear in the class: The breakpoint is started in the method.

4. Monitoring breakpoints
Most of our debugging program is to monitor the change of a variable, in the code where the variable appears to add a breakpoint is not only tired and may also miss, after the next one to delete, it is very tired.
We can do this simply by adding a monitoring breakpoint to the variable. Locate the first occurrence of the variable, add a normal breakpoint, enter debug mode, right-click the variable in Variables View, and select the Watch variable name. In this way, each time the variable is changed, a breakpoint will be triggered to inform us.

Four, Xcode debugging skills: exc_bad_access

1. Turn on Zombie objects
Turning on Zombie mode causes memory to rise, because objects that have been freed (reference count 0) are replaced by zombie objects and are not really released. This time again to send a message to the zombie object, will throw an exception, and print out the exception information, you can easily find the error code location, the end of Zombies will be released. Its main function is to detect wild pointer calls.
How to use:
"Edit Scheme ...", "Run", "diagnostics", "Zombie Objects"
Open the "Edit Scheme ..." window:

To turn on Zombie mode:

Note: The zombie mode can no longer be used on a real machine and can only be used on the emulator.
2. Address Sanitizer (disinfectant)
The addition of the Addresssanitizer tool after Xcode7 provides the convenience of debugging exc_bad_access errors. When the program creates a variable to allocate a piece of memory, the memory behind this memory is also frozen, identified as poisoned memory. When the program accesses the poisoned memory (access is out of bounds), it immediately interrupts the program, throws an exception, and prints the exception information. You can resolve the error based on the location of the interrupt and the log information of the output. Of course, if the variable has been freed, the memory it consumes will also be identified as poisoned memory, and this time access to the memory space will also throw an exception.
How to use:
"Edit Scheme ...", "Run", "diagnostics", "Address sanitizer"

After the Addresssanitizer is turned on, the program will automatically terminal and throw an exception if it encounters a exc_bad_access error during debugging.

3.Analyze Analyzer
The Analyze parser is a static tool that can analyze our programs to find out what variables we haven't used, or some dead storage. The execution Analyze is as follows: Product–>analyze. The following blue marks are the result of static analysis.

Of course, we can set the analyze when compiling the program, and set the following options to Yes.

Five, view debugging

There are many ways in which iOS has developed a UI design, such as Storyboard,xib and code implementations. For the Stoayboard,xib visualization implementation is relatively simple, but for some "old iOS programmers," like to use code to implement the UI, and perhaps the UI hierarchy is more complex. This will bring a lot of trouble to the developers of our new project. The quickest way to quickly see the interface hierarchy and layout of a complex UI is to use view debugging.
When the project runs to an interface (which can be an emulator or a real machine), turn on view debugging, click the button

This will enter the attempt to debug, you can easily view the interface. Here you can see the hierarchical relationship between controls.

Six, reference blog address:

Instruments do not introduce here, please refer to:
Instruments to test your app
Memory Graph
IOS Development Debugging Tips

Use clang Address sanitizer directly on Xcode 7

Xcode Debugging Tips

Xcode Debug Tips

Summary of common debugging Techniques for iOS development Xcode