Xcode debugging skills and Xcode debugging skills

Xcode debugging skills and Xcode debugging skills

Programmers spend a lot of time on debugging in daily development, and Xcode is inevitable for iOS development. This blog mainly introduces several methods in Xcode that can greatly improve code debugging efficiency.

"If debugging is the process of removing bugs, then programming must be the process of putting them in ."
-- Edsger W. Dijkstra

Add conditions

Sometimes we may create breakpoints in a loop, but clicking continue again and again until the conditions we want appear is obviously a very inefficient method. Fortunately, Xcode provides us with conditional breakpoints.

Insert a normal breakpoint in the following code

Right-click the Breakpoint, select Edit Breakpoint, and enterI> 50

In this way, the breakpoint is triggered only when the program runs properly.

Symbolic Breakpoint

Symbolic Breakpoint is a very powerful Breakpoint. Find Breakpoint navigator in Xcode (you can use the shortcut key command + 7) and click the plus sign at the bottom to view it.

Enter viewDidLoad in the Symbol column.
In this way, the breakpoint is triggered when all viewDidLoad methods in the program are called.

Of course, we can only add breakpoints for methods of a specific class. Enter [ClassName viewDidLoad] (Objective-C) or ClassName. viewDidLoad (Swift) in the Symbol column.

Monitoring breakpoint

Most of the time we debug the program, it is to monitor the changes of a variable. It is not only tired but may also be missed to add breakpoints where the variable appears in the Code. It is very tired to delete them one by one afterwards.

We can simply add a monitoring breakpoint to the variable.

Find the place where the variable appears for the first time, add a normal breakpoint, right-click the variable in Variables View after entering the debug mode, and select Watch variable name. In this way, every time this variable is changed, a breakpoint is triggered to inform us.

We can see the changes in the Console. (Note: In Xcode 6.1.1, it seems that there are still some problems when monitoring Swift variables and the value of the variables cannot be correctly displayed)

Log information breakpoint

The most common Debug method should be NSLog and println. We usually print out various instance information in this way to check the running status.

However, this debugging method also has obvious defects:

1. Unable to add at runtime

2. When too many lines of sight are added, You need to delete or comment out the lines of sight.

3. Will be compiled into the App, and should be closed in the official version (of course, we can judge whether to compile through macro, but this also requires additional operations, doesn't it)

Fortunately, we have another option in Xcode.

Add a normal Breakpoint in the following code, select Edit Breakpoint, click Add Action, Select Log Message, and enterThe number is: @ number @.

Shows the running effect.

Here, because of the log output, we can select the Automatically continue after evaluating actions at the bottom, so that this breakpoint will only output logs quietly for us.

Audible breakpoint

Similar to log information breakpoint, edit normal breakpoint, and select Sound for Action. A set sound is triggered when a breakpoint is triggered. This Action works with the Automatically continue after evaluating actions Option to achieve cool listening to bugs. :)

Summary

You can add a trigger condition for both the log information breakpoint and the breakpoint. Through these breakpoint operations, you can naturally greatly improve the efficiency of debugging code in daily development.

References

WWDC 2013 Debugging with Xcode

Intermediate Breakpoints

Address: http://www.cocoachina.com/ios/20150225/11190.html