Xcode code debugging with shortcut key blocks

Why does your array contain 3 items instead of 5? Why is your game running slowly? These are all related to debugging and debugging is an essential part of the development process. Some of the important debugging features listed here (of course not exhaustive) can help you with less time to fix bugs.

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 statusXcode at the bottom of the small black box is our good friend debugging, it can output log information, error messages and other useful things to help you track errors, in addition to see the log directly output information, we can also be programmed in the process of stopping at some breakpoints to check the app's many aspects. Conditional BreakpointI assume you know how breakpoints works (if you don't know, hehe, you may know that after reading this article!) It is very valuable to have the program hit a breakpoint at a specific point in time, but it is painful to pass a loop or recursive function to make the object equal to a certain value. At this point we can use conditional breakpoints! A conditional breakpoint is a breakpoint with a conditional expression, and the program pauses only if this condition is met. Suppose we want to break a breakpoint when the object is in a certain state, or at the nth iteration of the loop.  Click the ' gutter ' in the Xcode editor to add a breakpoint, right-click the breakpoint, and select "Edit Breakpoint" to set a specific condition. 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 a breakpoint should be ignored. In addition, you can add actions that can occur automatically based on breakpoints, such as a debugger command---print a value. Tip: The keyboard shortcut for adding/removing breakpoints is command+\ Another important breakpoint trick is to add an exception breakpoint (Exception breakpoint). When an exception is encountered, Xcode will essentially automatically go to the main method's Autorelease pool. By setting an exception breakpoint, you can navigate to the specific line of code that caused the exception breakpoint. How do I 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 '. This way, when Xcode encounters an exception, a breakpoint occurs where the exception code is generated. Manual printing from the consoleIn theory, it shows the state of all the values in the current environment; in fact, bugs sometimes occur, and values are not listed or are not updated when you step into debugging. In general, we add a specific breakpoint in the app code to see the state of the object through the ' Variables view ' provided by Xcode, which is next to the console of the Xcode bottom. Theoretically, it can show the state of all the values associated with the current context. In fact, sometimes a little bit of a problem, not listing the relevant values or not making the relevant updates. However, we can use some useful console commands to check for specific objects. Enter ' PO ' in the console to get instant information about a breakpoint. (when dealing with scalar values, we can use ' P ') when we look at an existing object, this is very useful (if the object does not exist, it will print nil), determine the object's value, find out the array/dictionary runtime information, or even compare two objects. Because this command prints out the memory address of the related object, you can print two objects that you think should be the same, and see if they have the same memory address. Another useful, but hidden instruction is recursivedescription, and you can simply use it to check the view. Call recursivedescription in view to print its inheritance relationship. the effective loggingSometimes, at a certain time in the debugger, we want to print the message to the console, when the ' NSLog ' function allows us to print any output to the console. You can now 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 bottom) Tip: Here you can see Apple's information about string formatting in objective-c: String Programming Guide NSLogNSLog is very useful and we need to implement it intelligently. Anything printed from NSLog becomes code and can be seen by anyone. By connecting the device to your computer and opening the organiser in Xcode, you can look at each log message from the console, which has a big impact. Think about it, you want to print some secret algorithmic logic or user passwords to the console.  Because of this, if Apple finds that there is too much content output to the console in the production build, then your app may be rejected by Apple. Fortunately, here's one of the simplest ways to log--through a macro, so that NSLog only works when the debug build. Add this feature to a header file that can be accessed globally. This allows you to use log as you like, and does not include the log-related code when you are production. The following code: 1. #ifdef DEBUG2. #define Dmlog (...) NSLog (@ "%s%@", __pretty_function__, [NSString stringwithformat:__va_args__]) 3. #else4. #define DMLOG (...) do {} while (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 log is located. Next Step NSLog is powerful, but there are a number of limitations:1.can only be printed locally2.sub-level log (for example, danger or warning) is not supported3.NSLog is very slow and can significantly reduce the operating efficiency of the program when processed in large quantities. Two frames are recommended to avoid nslog some limitations: •Cocoa lumberjack– is one of the well-known universal Cocoa log frameworks, which is a bit difficult to learn, but very powerful. •alternative to Snlog–nslog. tracking the life cycle of an objectAlthough automatic Reference counting (ARC) has made memory management simple, time-saving, and efficient, it is still important to keep track of important events in the Life-cycles of object. After all, arc does not completely exclude the possibility of a memory leak, or attempts to access a release object. For this purpose, we can use some processing methods and tools to help us keep an eye on what the object is doing. Log Important EventsThere are two very important methods in the life-cycle of the Objective-c object: Init and Dealloc, and the log of the events that are called by these two methods to the console is a good choice-you can observe the beginning of the object's life through the console, and more importantly, You can ensure that the object is disposed. 1.-(ID) init2.    {3. Self = [Super init];4.    if (self) 5.    {6. NSLog (@ "%@:%@", Nsstringfromselector (_cmd), self); 7.    }8. Return self;9.} 10.-(void) dealloc11. {NSLog (@ "%@:%@", Nsstringfromselector (_cmd), self); 13.} Static analyzers and Inspector (checker)There are also two tools in Xcode that can help us clean up the code and reduce the chance of a code error. For Xcode, the static Profiler tool is a great tool for improving your code. For example, detects objects that have not been used, and there are no release objects (ARC still has a problem with the core Foundation object).  You can view the recommendations by selecting ' Anlayze ' in the Product menu. Inspectors are a very powerful set of tools that can be used not only to check the memory usage of the program from different angles, but also to use the file system (add, delete, modify, etc.), and even provide a way to automate UI interaction. You can view these inspectors by selecting ' profile ' in the Product menu. Select ' Profile ' to open 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 is probably the most useful template for capturing memory leaks while the program is running. Zombies is your friend.Although it is difficult to encounter exc_bad_access errors in places where there is an arc, the error will still occur in certain situations. When working with Uipopovercontroller or core foundation objects, we can access an object that has been removed. In general, when we release an object in memory, the object is destroyed. However, when zombies is turned on, it simply marks the object as release, and the object is actually stuck in memory. When we visit a zombie object, Xcode can tell 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 the object is and when it happened. Here are two ways to find out the Zombies object. Use the zombie configuration template in the inspector, or turn on the Zombie diagnostics option in the ' Run ' build option. Next to the Stop button, click the Scheme name, then select ' Edit Scheme ', click Diagnostic tab, and Tick ' Enable Zombie Objects '. Note that zombie can only be used in simulator debugging, not on the real machine. Note that zombie mode debugging is only available for simulators and cannot be used on real devices. SummaryHopefully, this will help you debug your app more efficiently, all in order to save time on bug fixes, so developers can spend time on more important things or build a great app. The list above is definitely not a comprehensive listing, and there are a lot of ways we haven't discussed it, such as remote control bug reports, crash reports, and more. And I hope you can share more.

Xcode code debugging with shortcut key blocks