original link: http://www.cocoachina.com/newbie/basic/2013/0517/6225.html
Why does your array contain 3 items instead of 5? Why your game is running slowly. These are related to debugging, debugging is an essential part of the development process. This article lists some of the important debugging features (which, of course, are not comprehensive) can help you solve the bug problem in less time. The content of this article mainly includes 3 aspects:
use console to check app status Logging and mastering NSLog Use the life cycle of an object to track memory usage.
use console to check app status
The small black box at the bottom of the Xcode is our good friend when we debug, it can output log information, error messages, and other useful things to help you track errors, in addition to seeing the log directly output information, we can also in the programming process to stop at some breakpoints, to check many aspects of the app.
Conditional Breakpoint
I assume you know how breakpoints works (if you don't know, hehe, maybe you'll know after reading this article.) It is very valuable to have a program at a particular point in time, but it is a painful thing to make an object equal to a certain value through a loop or recursive function. At this point we can use conditional breakpoints. A conditional breakpoint is a breakpoint with a conditional expression, and the program pauses only if the condition is met. Suppose we just want to break the breakpoint when the object is in a certain state, or at the nth iteration loop. Click Xcode Editor's ' gutter ' to add a breakpoint, right-click the breakpoint, and choose Edit Breakpoint to set specific conditions. Conditional breakpoints are interrupted only when a particular situation is encountered, and you can provide a condition (such as I = = 12) or the number of times the breakpoint should be ignored. Alternatively, you can add actions that can occur automatically based on a breakpoint, such as a debugger command---print a value. Tip: Keyboard shortcuts for adding/removing breakpoints are command+\ Another important breakpoint tip is to add an exception breakpoint (Exception breakpoint). When an exception is encountered, Xcode will basically automatically go to the Autorelease pool in the main method. By setting an exception breakpoint, you can navigate to the specific line of code that caused the exception breakpoint. How to add an exception breakpoint. 1. Open the Exception Breakpoint tab (COMMAND+6); 2. Select the "+" button in the lower-left corner of the window; 3. Select the button and add ' Exception breakpoint '. Thus, when Xcode encounters an exception, a breakpoint occurs where the exception code is generated.
Manual printing from the console
In theory, it shows the state of all the values in the current environment; in fact, there are sometimes bugs that do not list values or do not update when you step through the test. In general, we add a specific breakpoint in the app code to view the state of the object through the ' Variables view ' provided by Xcode, next to the console at Xcode bottom. Theoretically, it can display the state of all values associated with the current context. In fact, there are sometimes small problems that do not list related values or do not update related. However, we can use some useful console commands to check for specific objects. Enter ' PO ' in the console to get instant information for a breakpoint. (We can use ' P ' when dealing with scalar values, which is useful when we look at an existing object (if the object does not exist, it prints out nil), determines the object's value, finds the array/dictionary run-time information, and even compares two objects. Because this command prints out the memory address of the associated object, you can print two objects that you think should be the same, to see if their memory addresses are the same. Another useful, but hidden instruction is recursivedescription, and you can simply check the view with it. Call recursivedescription in view to print its inheritance relationship.
effective logging.
Sometimes, at a certain time in the debugger, we want to print the message to the console, at which point the ' NSLog ' function allows us to print any output to the console. You can then use the NSLog function, which allows you to print any output to the console. This feature is useful when you are not using breakpoints. NSLog conforms to the same format as the [NSString stringWithFormat] method. (You can see from the screenshot below) Tip: Here you can see Apple's information about string formatting in objective-c:
String Programming GuideNSLog
NSLog is very useful and we need to be smart about implementing it. Anything printed from the NSLog becomes code that anyone can see. Connect the device to the computer, open the Xcode in the organiser, you can see from the console look at each log information, this will have a great impact. Think about it, you want to print some secret algorithm logic or user password to the console. Because of this, if Apple finds that there is too much content output to console in the production build, your app could be rejected by Apple. Fortunately, there is an easy way to log--through a macro so that NSLog only works on the debug build. Add this feature to a header file that can be accessed globally. So you can use the log as you like, and when you do production, you don't include log-related code. The following code: 1. #ifdef DEBUG 2. #define DMLOG (...) NSLog (@ "%s%@", __pretty_function__, [NSString stringwithformat:__va_args__]) 3. #else 4. #define DMLOG (...) do {} (0 If you use Dmlog, it can only be printed during the debug build. __PRETTY_FUNCTION__ can also help print out the name of the function where the log is located.
Next NSLog is powerful, but there are many limitations:
1. Only 2 can be printed locally. Do not support split-level log (for example, danger or warning) 3. NSLog is very slow, and a lot of processing will obviously reduce the operation efficiency of the program. Two frames are recommended to avoid NSLog limitations: Cocoa lumberjack– is one of the well-known common Cocoa log frameworks that is a bit difficult to learn, but very powerful. A substitute for snlog–nslog.
tracking the life cycle of an object
Although automatic Reference counting (ARC) has made memory management simple, time-saving, and efficient, it is still important to track important events in the Life-cycles of object. After all, arc does not completely exclude the possibility of a memory leak or attempt to access an object being released. For this purpose, we can use some processing methods and tools to help us stare at what the object is doing.
Log Important Events
There are two important methods in the life-cycle of the Objective-c object: Init and Dealloc, the event log to the console called by the two methods is a good choice-you can see the beginning of the object's life through the console, and more importantly, You can ensure that the object is released. 1.-(ID) init 2. {3. self = [super init]; 4. if (self) 5. {6. NSLog (@ "%@:%@", Nsstringfromselector (_cmd), self); 7.} 8. return self; 9.} 10.-(void) Dealloc 11. {NSLog (@ "%@:%@", Nsstringfromselector (_cmd), self); 13.}
Static Analyzer and Inspector (inspector)
There are two more tools in Xcode that can help us clean up the code and reduce the chance of code error. For Xcode, the Static Analyzer tool is a great tool for improving code. For example, if you detect an object that has not been used, there is no release object (for the core Foundation object, ARC still has this problem). You can view the recommendations by selecting ' Anlayze ' in the Product menu. The Checker is a powerful set of tools that check the memory usage of the program from different angles, file system usage (add, delete, modify, and so on), and even provide an automatic UI interaction method. You can view these inspectors by selecting ' profile ' in the Product menu. Selecting ' profile ' opens a instrument window where you can select a configuration template to run. The most commonly used templates are zombies (discussed later), Activity monitor and leaks. Leaks may be one of the most useful templates when a memory leak is captured while the program is running.