Writing code inevitably has bugs. In general, the most direct means of debugging in addition to logging is debug. So where do you stay with your debugging techniques? Just step at the next breakpoint? Or you know Evaluate Expression, conditional breakpoint; But have you heard of log breakpoints, Method Breakpoint, Exception Breakpoint? And the lofty Field Watchpoint?
Have you noticed the difference between breakpoints next to Android Studio? For example, what is the difference between the three breakpoints above? Let me tell you all about it.
Debugging based
Generally speaking, there are two ways to debug a debuggable APK; One is to set a breakpoint, and then use debug mode to compile and install the app; The second is attach process, which is a dialog box in Android Studio:
The second method is more common, we can start apK, directly under the breakpoint, and attach the process to the development process, after the condition trigger can directly enter the debugging mode.
Other steps, step into, step out, force step into, etc. Basic tracking tools.
Again, the easiest way to set a breakpoint is to click on the left side of the code editor and to the right of the line number.
Evaluate Expression
This is very useful because you can go directly to an evaluation environment at the breakpoint, where you can execute any expression you are interested in; The diagram below:
For example, there is an object at a breakpoint, and if you want to view one of its properties, you can see it in the Debug window, but what if you want to execute one of its methods and see what the result is? You can do that with this. It does much more than that, of course, and is a very useful step straight into a REPL environment. I forgot to mention the shortcut Alt + F8 😛
Conditional breakpoints
Suppose your break point is in a loop over a list, but you are only interested in one element of the list and only want to break when that element is encountered. Are you a human F9 until you meet the criteria? Conditional breakpoints meet this requirement and, as the name implies, breakpoints under certain conditions. It’s also very easy to use. Right-click on your breakpoint and a small window will appear.
Log breakpoint
Most of the time when we debug more is to print logs to locate abnormal code, narrow down the scope and then use breakpoints to solve the problem; So the usual thing to do is to add log information to the code, output function parameters, return information, output variables that we are interested in, etc.
But one problem with this is that we added logging code that needs to be recompiled; In the dark ages before Instant Run, this was painful, with compilations ranging from tens of seconds to minutes; Such pointless waiting is torture; In addition to hot deployment tools, we can use logging breakpoints to solve this problem.
First we make a breakpoint where we want to output information; Right-click the breakpoint and set the suspend property of the breakpoint to False in the Settings box that appears. This is called a “breakpoint” but does not actually break. Then, we fill the log message with the log information we want to output. As shown below (note the red position) :
This way, every time the code hits the breakpoint, the lovely breakpoint does not stop our program, but prints the log message we told it to, and continues execution; It’s very convenient.
Methods the breakpoint
The traditional debugging method is based on the behavior unit, so called single step debugging; But a lot of times we care about the parameters of a function, the return value; (Recall that when we use logging, the most printed information isn’t function arguments and return values?) Using method breakpoints, we can debug at the function level; This type of breakpoint is useful if you often jump into and out of functions or are only interested in the arguments of a function. There are two specific methods of use; The easiest way to do this is to put a breakpoint on the first line of the method you are interested in. You will notice that the breakpoint icon is a little different. This is the method breakpoint, as shown below:
Another way is through the breakpoint setting window, described below.
Exception breakpoints
In some cases, we are only interested in certain exceptions, or we are only interested in exceptions; We want our program to break if something goes wrong; This is like preserving the scene, as long as there is a murder case (abnormal), the first time to save the scene, so that what fingerprints and other clues will be a lot of clear, even if the bad guys want to escape is difficult to fly ah.
Android Studio gives us this capability! That’s an exception breakpoint! You can simply shut down the entire program when a specific exception occurs; If you’re interested in all the exceptions, just Throwable.
To do this, go to Run -> View BreakPoints or use shortcut keys to open the breakpoint setting window. The diagram below:
Click âž• in the upper left corner and a selection box will appear; Select Exception Breakpoint; A dialog box will then appear to select the exception you are interested in:
Field WatchPoint
When we added the exception breakpoint above, when we clicked the plus sign, there were four options; The first is the way to add breakpoints to the second method. The third is the exception breakpoint.
Is there a situation where you find that a value has been changed by someone, and when, and by whom? Java is value passing, but references can also be values; Objects are all on the heap, and the heap is shared by all threads, so in very complex scenarios, you don’t know who is modifying these shared variables, which can be very dangerous; Immutability is an important feature in multi-threaded environments, and we see that highly concurrent languages such as Erlang and Scala have some degree of support for this immutability.
Okay, digress; So how do we find out who’s changing our values? That’s what this Field WatchPoint does; It allows us to break the program when a Field is accessed or modified; Perfect solution to this problem.
The way to set breakpoints is similar to method breakpoints, there are two kinds; The first is to create a breakpoint directly at the declaration of a field. The breakpoint icon changes as shown in the following figure:
By right-clicking the breakpoint, you can set it to break every time it is changed, or you can change it to break every time you access the field.
Another way is to Run -> View BreakPoint to turn on Settings, similar to exception breakpoints.
Much more than that
With all the awesome features mentioned above, there’s a lot more detail; Open Breakpoint setup window (Run -> View Breakpoint ‘):
We can break on the class that we’re interested in, on a particular object that we’re interested in, we can set the number of breakpoints, and we can make the breakpoints break on a particular thread. These details will not be introduced in detail, we go to discover!