Android Studio debugging tips you don't know

Bugs are inevitable when writing code. Usually, besides logging, the most direct debugging method is debugging. So what stage is your debugging technology at? Is it just stepping through the next breakpoint? Or you know Evaluate Expression and conditional breakpoints, but have you heard of log breakpoints, method breakpoints, exception breakpoints, and the high-end Field Watchpoint?

Several different breakpoints

Have you ever paid attention to the differences between the breakpoints in Android Studio? For example, what are the differences between the three breakpoints in the picture above? Let me explain them one by one.

Debugging Basics

Generally speaking, there are two ways to debug a debuggable apk. One is to set breakpoints and then compile and install the app in debug mode. The other is the attach process, which is a dialog box like this in Android Studio:

Attach Process

The second method is more commonly used. After starting the apk, we can directly set a breakpoint, and then attach process to the specified process. After the condition is triggered, we can directly enter the debugging mode.

Some other single-step executions, step into, step out, force step into, etc. will not be mentioned; basic tracking methods.

I would like to mention that the easiest way to set a breakpoint is to click the mouse to the right of the line number on the left side of the code editor.

Evaluate Expression

This feature is very practical. You can directly enter an evaluation environment at the breakpoint, where you can execute any expression you are interested in; as shown below:

Evaluate Expression

For example, if there is an object at a breakpoint, it is very simple to view a certain property of it, you can see it in the Debug window, but if you want to execute a certain method of it to see what the result is? With the help of this, you can achieve it. Of course, its functions are far more than that, it is equivalent to directly entering a REPL environment, which is very practical. I forgot to mention the shortcut key Alt + F8 :P

Conditional breakpoints

Suppose your breakpoint is in a loop of a list, but you are only interested in a certain element of the list and want to break only when you encounter this element; do you keep pressing F9 until the condition is met? Conditional breakpoints meet this need. As the name suggests, they are breakpoints under specific conditions. It is also very simple to use. Right-click on your breakpoint and a small window will appear, where you can write the condition.

Conditional breakpoints

Log breakpoints

Many times when we debug, we print logs to locate abnormal codes, narrow the scope, and then use breakpoints to solve the problem; so what we often do is to add log information in the code, output function parameters, return information, output variable information we are interested in, etc.

But one problem with this is that we need to recompile the logging code after adding it; this was very painful in the dark ages before Instant Run, with each compilation taking anywhere from tens of seconds to several minutes; such meaningless waiting was simply torture; in fact, in addition to hot deployment tools, we can also use logging breakpoints to solve this problem.

First, we set a breakpoint where we want to output information; then right-click the breakpoint and set the suspend property of the breakpoint to False in the settings box that appears. Although it is called a "breakpoint", it will not actually break; then, we fill in the log message we want to output. As shown in the figure below (note the red position):

Log breakpoints

In this way, every time the code executes to this breakpoint, this lovely breakpoint will not stop our program, but will output the log information we told it and then continue executing; very convenient.

Method breakpoints

The traditional debugging method is based on lines, so-called single-step debugging; but many times we are concerned about the parameters and return values ​​of a function; (Think back to when we use logs, aren't the most printed information the parameters and return values ​​of the function?) Using method breakpoints, we can debug at the function level; if you often jump in and out of functions or are only interested in the parameters of a function, this type of breakpoint is very practical. There are two specific ways to use it; the simplest is to set a breakpoint on the line at the beginning of the method you are interested in. At this time, you will find that the breakpoint icon is a little different, this is the method breakpoint, as shown below:

Method breakpoints

Another way is through the breakpoint setting window, which will be introduced later.

Exception breakpoint

In some cases, we are only interested in certain specific exceptions, or we are only interested in exceptions; we hope that the program can be interrupted as long as an exception occurs; this is like preserving the scene, as long as a murder occurs (abnormality), the scene is preserved as soon as possible, so that clues such as fingerprints will be much clearer, and the bad guys will be unable to escape even if they want to.

Android Studio gives us this ability! That is exception breakpoint! When a specific exception occurs, the entire program can be directly stopped; if you are interested in all exceptions, just Throwable.

To do this, go to Run -> View BreakPoints or use the shortcut key to open the breakpoint setting window; as shown below:

Breakpoint Settings Window

Click the ➕ in the upper left corner and a selection box will appear; select Exception Breakpoint; then a dialog box will appear, select the exception you are interested in:

Exception breakpoint

Field WatchPoint

When we add an exception breakpoint above, when we click the plus sign, there are four options; the first one is the second method of adding breakpoints we mentioned earlier, and the third one is the exception breakpoint. So what is the second Field WatchPoint for?

Have you ever had such a scenario: you find that a certain value is inexplicably modified by someone and you don’t know when and who is the culprit? Although Java is passed by value, references can also be values; all objects are stored on the heap, and the heap is shared by all threads. Therefore, in very complex scenarios, you have no idea who has modified these shared variables, which is very dangerous; in a multi-threaded environment, immutability is a very important feature. We see that highly concurrent languages ​​​​such as Erlang and Scala have some degree of support for this kind of immutability.

Ok, that's a little off topic; so how do we find out the troublemaker who modified our value? That's the function of Field WatchPoint; using it, we can stop the program when a certain Field is accessed or modified, thus solving this problem.

There are two ways to set a breakpoint, similar to method breakpoints. The first is to set a breakpoint directly at the declaration of a field. At this time, the breakpoint icon will change, as shown below:

Field WatchPoint

By right clicking on this breakpoint, we can make some settings. For example, the default is to break when it is modified. You can also change it to break every time this field is accessed.

Another way is to open the settings by going to Run -> View BreakPoint, which is similar to exception breakpoints.

There is much more

So many powerful features are introduced above, but there are still many details; open the breakpoint setting window (Run -> View Breakpoint`):

We can set breakpoints on classes of interest or specific objects of interest, set the number of breakpoints, and set breakpoints to occur only on specific threads; I won't go into detail about these details, so you can explore them yourself!