Xcode breakpoint debugging skills

This article is reposted from the broken ship

In the program, whether you want to figure out why the array contains three objects instead of five, or why after a new player starts, games are regressing-debugging is an important part of these processes. Through the study in this article, we will know most of the important debugging functions that can be used in the program, and how to use these debugging functions to help you solve bugs in less time.

This article introduces the following content:

• Use the console to check the program status
• Logging and mastering nslog
• Use of object lifecycle tracking memory

Check using the Console

During program debugging, a small black box at the bottom of xcode may be your best friend. It can output log information, error information, and other useful content-this can help you track errors. In addition to the log output, we can also stop at a broken Point and check the variable information in the program.

Conditional breakpoint

This article assumes that you know how the breakpoint works (even if you don't know it, you don't have to worry about it. After reading this article, you will understand it !).

It is very important to hit a breakpoint at a specific time point. In some breakpoints, sometimes we need to use a painful loop or recursive function to make our object equal to a certain value. Now we can use the conditional breakpoint!

A conditional breakpoint is a type of breakpoint that is hit only when a certain condition is met. Imagine that we only want to hit the breakpoint when the object is in a certain state, or when it is iterated to the nth time. Click 'gutter 'in xcode editor to add a breakpoint. Right-click the breakpoint and select 'edit breakpoint' to set specific conditions.

You can provide a condition (for example, I = 12) or the number of times the breakpoint is ignored. You can also add an action that automatically occurs based on the breakpoint. For example, a debugger command -- prints a value.

Prompt: The keyboard shortcut for adding/deleting breakpoints is command + \

Another important breakpoint technique is to add an exception breakpoint (exception breakpoint ). In case of an exception, xcode will automatically go to The autorelease pool in the main method for 99% times.

Thanks to xcode... It's really useful!

With exception breakpoint, you can easily locate the specific code line that causes the exception. How to add an exception breakpoint: Open the exception breakpoint tab (command + 6 ). Select the "+" button in the lower-left corner of the window and add an 'exception breakpoint'. In this way, when xcode encounters an exception, it will stop at the breakpoint where the Exception Code is caused.

Manually print on the console

Generally, we add breakpoints in the program code to view the variable status through the 'variables view' provided by xcode (this view is next to the console at the bottom of xcode. Theoretically, this window displays the status of all values related to the current context. In fact, this is a small problem. Sometimes, after the breakpoint is over, the window will not be updated.

 

A good feature is that we can use console commands to check a specific object-this is very useful. Enter 'po' in the console to print the real-time information of the specified object ('P' is used when processing the scalar value ').

 

This is useful when you view an existing object (NIL is printed if the object does not exist)-determine the object Value and view the array/dictionary information at runtime, it is even a comparison of two objects (this command can print the memory address of the relevant object, we can print the information of the two objects, and then see if their memory addresses are the same ).

In addition, it is very useful (but hidden commands) to easily check the view-RecursivedescriptionCommand -- call this command on view to print the inheritance relationship of view.

Effective log

 

Sometimes, during a certain period of time during program debugging, we want to print the message to the console. At this time, we can use the nslog function to print any output to the console. This function is useful when no breakpoint is used. The format of nslog compliance and[Nsstring stringwithformat]The method follows the same format.

Prompt: Here we can see the string formatting information in objective-C: String programming guide

Make nslog smarter

Although nslog is very useful, everything printed from nslog will be retained on the real machine, and everyone can see it-just connect the device to the computer, and then open the Organiser in xcode, go to the console to view each log. You may realize that this will have some serious impact! Think about it, if you print some confidential algorithm logic or user password to the console! Therefore, if Apple detects that many content is output to the console in the production build, your application may be rejected by Apple to store.

 

Fortunately, here is the simplest way to perform log-through a macro, nslog only works during debug build. Add this function to the header files that can be accessed globally. In this way, you can use log as much as possible, and the log-related code is not included in the production. The following code:

#ifdef DEBUG#define DMLog(...) NSLog(@"%s %@", __PRETTY_FUNCTION__, [NSString stringWithFormat:__VA_ARGS__])#else#define DMLog(...) do { } while (0)

If dmlog is used, the log is printed only during the debug build. Production build does not have any logs. Pass_ Pretty_function \__You can print out the function for printing the log.

Next step

Although nslog is excellent, it has some limitations:

• Print locally only
• Logs with levels (such as severe logs and warnings) are not supported)
• Nslog efficiency is low. When a large amount of processing is performed, nslog will seriously affect the execution efficiency of the program.

There are also some frameworks on the Internet that can be used to record logs. These frameworks can avoid some nslog restrictions. There are two good ones below:

• Cocoa lumberjack-this is a well-known log framework for cocoa. Although the membership dues are strong at the beginning, they are very powerful.
• An alternative to snlog-nslog.

Lifecycle of a trail object

Although arc can effectively manage the memory, it is still important to track important events within the object lifecycle. After all, arc cannot completely eliminate the possibility of Memory leakage, or ensure that it accesses a release object (arc just tries its best to avoid such a situation ). To this end, we can use some methods and tools to observe and pay attention to what the object is doing.

Log important events

There are two important methods in the life cycle of an objective-C object: init and dealloc. It is a good choice to log the events called by these two methods to the console-you can observe the beginning of the object's life through the console. More importantly, you can ensure that the object is released.

- (id)init{    self = [super init];    if (self)    {        NSLog(@"%@: %@", NSStringFromSelector(_cmd), self);    }    return self;}- (void)dealloc{    NSLog(@"%@: %@", NSStringFromSelector(_cmd), self);}

Static analyzer and Checker

There are two tools in xcode that can be used to clean up the code to reduce the code error rate. The static analyzer tool can provide improvement suggestions for our code, such as detecting unused objects and no release objects (for core Foundation objects, arc still has such problems ). Select 'anlayze' from the product menu to view related suggestions.

 

 

 

The checker is a very powerful set of tools, through which we can not only check the memory usage of our programs from different angles, file System usage (add, delete, modify, etc.), and even provides automatic UI interaction methods. You can select 'profile 'from the product menu to view these checkers.

Selecting 'profile 'opens an instrument window, where you can select a configuration template for running. The most common templates are zombies (which will be discussed later), activity monitor, and leaks. Leaks may be the most useful template for capturing memory leaks when running programs.

Zombies is your friend

Although it is difficult to encounter an uncomfortable exc_bad_access error where there is an arc, this error will still happen under certain conditions. When processing a uipopovercontroller or core Foundation object, we can access an object that has been release. Generally, an object in the release memory will be destroyed. However, when zombies is enabled, only the object is marked as release. In fact, this object remains in the memory. When we access a zombie object, xcode tells us that the object being accessed is an object that should not exist. Because xcode knows what this object is, it allows us to know where it is and when it occurs.

There are two ways to find the zombies object. Use the zombie configuration template in the checker or enable the zombie diagnostic option in the 'run' build option. Click the scheme name next to the stop button, select 'edit Scheme ', click the diagnostic tab, and select 'Enable zombie objects '. Note: zombie can only be used in simulator debugging and cannot be used on a real machine.

Conclusion

I hope the above debugging skills will help you. Using the above techniques, you can reduce the bug modification time and spend more time on the important part-building outstanding programs!

The above is not a complete Debugging Technique. There are also many other technologies not discussed, such as debugging problems in real machines, remote bug reports, and crash reports.

Happy programming!

_________________

This article is translated by the ship: tutsplus
Reprinted please indicate the source:Beyondvincent blog