Click on the asynchronous book, the top public account
Every day to share with you IT good books technology dry goods workplace knowledge
Xcode debugging tips
When used correctly, debugging tools built into the IDE can save a lot of time. For example, the simplest setting of breakpoints for single-step debugging is an order of magnitude more efficient than raw manual console printing. And that’s just the tip of the iceberg in the debugging Arsenal. Xcode has a whole set of handy tools designed to speed up the debugging workflow.
The task is automatically executed at the breakpoint
To review a common scenario for breakpoint debugging: after code execution is paused at breakpoints, we typically enter LLDB commands such as Po myVariable on the console to obtain context information before continuing with code execution.
Obviously, the debugging process becomes tedious if the above manual typing of the command line needs to be done multiple times. Ideally, it should be automated as follows:
- Right-click breakpoints to edit them
- Click the Add Action
- Select the Debugger Command
- Enter the LLDB command you want to execute
- Automatically continue after evaluating Actions check Automatically continue after evaluating Actions and continue running the program if you want to execute the command.
This way, every time a breakpoint is triggered, the custom command we set will be executed. During the whole process, you do not need to manually type the LLDB command, saving a lot of development time.
Conditional breakpoints
Sometimes we might want to set breakpoints that will only fire under certain circumstances. A common example is a loop in which we want a breakpoint to be triggered under certain circumstances. This way we can avoid a lot of invalid triggers and free ourselves from the constant continue click.
In the example above, the breakpoint will only be triggered if counter > 20. You can also use more complex BOOL statements, or even perform function calls.
The breakpoint to ignore
In contrast to conditional breakpoints, sometimes we may need to skip breakpoints at specific times. For example, a function is called many times in its lifetime, but we are not interested in the first call. So we can set it to skip triggering breakpoints on the first call:
Exception breakpoints
In each of these cases, we explicitly set breakpoints on a line of code, but sometimes the breakpoints we need cannot be preset in advance. For example, if an exception occurs while the program is running and is not caught, the program will Crash. Although Xcode prints out specific call stack information on the console, and most of the time this information is useful for error location, it doesn’t take us directly to a specific context.
To solve this problem, we need to set breakpoints for specific events rather than specific code. Depending on the type of event you are interested in, you can set it up:
Symbol breakpoint
Exception breakpoints are strictly a specific type of symbolic breakpoints, but we can also define more custom types of generic breakpoints. For example, we can set a generic breakpoint on the call to the viewDidLoad method that fires on each call:
This way, we don’t have to manually set breakpoints at every call.
Variable to track
These breakpoints are for code execution in the program. But apps don’t just contain code, they also contain another very important object: data. So in addition to code execution requiring breakpoints to be set, some data changes may also be events of interest.
To track data changes, we first need to set breakpoints in the variable visibility domain. Then we right click on the console to set the variable view, and finally you can cancel the secondary breakpoint.
Of course, we can also do this from the console with the LLDB command:
watchpoint set variable self.counter
Once the setting is complete, breakpoints are triggered for any changes that occur during the lifetime of the variable.
conclusion
These debugging tips are just a few, but when used properly they can greatly improve the debugging experience and speed.
This article is excerpted from the Asynchronous Community by BigNerdCoding, Advanced Debugging Tips for Xcode
Stretch recommended
New book in February 2018
A blockbuster book for January 2018
Primary school students start learning Python, the closest programming language to AI: A Wave of Python books from Amway
Policy warming: Everyone is learning big data, a wave of good books recommended
Eight new books. Send one you like
AI | classic books (introduction to artificial intelligence which books to read?
Long press the QR code, you can follow us yo
I share IT articles with you every day.
If you reply “follow” in the background of “Asynchronous books”, you can get 2000 online video courses for free. Recommend friends to pay attention to according to the prompts to get a gift book link, free of charge asynchronous books. Come and join us!
Read the original