Android Studio Code Debugging Tips

Android Studio has become the primary tool for Android development, and it’s pretty easy to get used to. As developers, debugging and finding bugs, and then fixing them, is what we do best. Just like other development tools, such as Eclipse and Idea, Android Studio also provides powerful debugging techniques. Today we will take a look at some debugging techniques in Android Studio.

First, let’s take a look at the debug panel provided for us in Android Studio (in standard case) :

Click on the upper right Restore ‘Threads’ View to display the current thread information:

Android Studio provides us with seven functional areas in general:

1. Single step debugging area
2. Breakpoint management area
3. Evaluation expression
4. Thread frame stack area
5. Object variable area
6. Variable observation area

Let’s take a look at each of these seven areas.

Single step debugging area

This section provides the main debugging operations, which you are familiar with: Step over, Step into, Force Step Into, Step Out, and Drop Frame.

Show Execution Point

Write the picture description here

Click this button and the cursor will be positioned to the position where you are currently debugging.

Step Over

Write the picture description here

Step skipped, clicking this button causes the program to move down one line. If the current line is a method call, the method called on this line is executed before the next line. For example, the current code is:

int num=10;
int min=Math.min(num,100);
System.out.println(min);Copy the code

When step over is clicked, math.min (num,100) completes and jumps to line 3 if you are currently debugging line 2.

Step Into

Write the picture description here

A step that causes the program to move down one line. If there is a custom method in the line, it goes inside the method to continue execution. Note that if it is a method in the class library, it does not go inside the method.

Force Step Into

Write the picture description here

Forcing a step jump is similar to step into, except that if there are any methods on the current line, they can jump inside the method and continue execution, whether they are self-defined or provided by the library

Drop Frame

Write the picture description here

Interrupt execution and return to the original point of execution of the method, during which the corresponding stack frame is removed from the stack. In other words, if the method is called, it is returned to where the current method was called, and the values of all context variables are restored to their state when the method was not executed. To give a simple example:

public class DebugDemo { private String name = "default"; public void alertName() { System.out.println(name); debug(); } public void debug() { this.name = "debug"; } public static void main(String[] args) { new DebugDemo().alertName(); }}Copy the code

When you debug debug (), perform this action to call back to where debug () was called, which is the alertName() method. If you continue to drop Frame at this point, you will be called back to where alertName () was called, which is main ().

Force Run to Cursor

Write the picture description here

A very useful feature, you can ignore the existing breakpoint, jump to the cursor. Here’s a simple example:

For example, if I want to debug 18 lines and I don’t want to debug them step by step, can I debug them all at once? Move the Cursor to the appropriate position and execute Force Run to Cursor:

Evaluate expression

Write the picture description here

Clicking this button will embed an interactive interpreter at the current debugging statement, in which you can evaluate any expression you want. For example, we execute the following code during debugging:

Implementing Evaluate Expression at this point is equivalent to embedding an interactive interpreter before tuning, so what can we do in that interpreter? Here, we can evaluate result by right clicking on the position you want to value and selecting Evaluate Expression. The following information is displayed:

Enter the evaluation expression in the input box that pops up, such as math.min (result,50), as shown below

When we hit execute, we find that the Result has been output as follows:

Breakpoint management area

Return

Write the picture description here

Clicking this button will stop the current application and restart it. In other words, when you want to debug again, you can use this action.

Pause Program

Write the picture description here

Clicking this button will suspend application execution. If you want to Resume, you can use the Resume Program mentioned below.

Resume Program

Write the picture description here

This operation has the meaning of restoring the application, but has two kinds of behavior:

1. If the application is in the suspended state, click this button to resume the application.
2. In many cases, we set multiple breakpoints for debugging. In some cases, we need to move from the current breakpoint to the next breakpoint, and the code between the two breakpoints is automatically executed so that we don’t have to debug to the next breakpoint step by step, saving time and effort. For example:

public void test(){ test1(); . test2(); }Copy the code

Suppose we add breakpoints at line 2 and line 4, respectively. If we debug on line 2 and click execute, the current debug position will be automatically executed on line 4, so the code between lines 2 and 4 will be executed automatically.

Stop

Write the picture description here

Clicking this button terminates the current process with the associated close script. In other words, there may be different stop behaviors for different types of projects. For example, for normal Java projects, clicking this button means exiting debug mode, but the application will still execute. In an Android project, clicking this button means the app is finished running.

Let’s take a common JAVA project as an example:

If we stop the program and find that the program exits the debugging mode, the Console output is as follows:

View Breakpoints

Write the picture description here

Click this button to enter the breakpoint Management interface, where you can view all breakpoints, manage or configure breakpoint behaviors, such as: delete, modify property information, etc.

Mute Breakpoints

Write the picture description here

Use this button to toggle the status of breakpoints: enable or disable. During debugging, you can disable and temporarily disable all breakpoints to achieve normal application operation. This feature is useful for temporarily disabling breakpoints when, for example, you don’t want them to interfere with the process you’re interested in during debugging.

Get thread dump

Write the picture description here

Get thread Dump, click this button to enter the thread Dump interface:

Here’s a quick introduction to the dump interface: the most commonly used thread tool area is

Can be used to filter threads, the rest is not explained

Let’s recognize the types of threads, represented by different ICONS:

Thread state description	icon
Thread is suspended.	Write the picture description here
Thread is waiting on a monitor lock.	Write the picture description here
Thread is running.	Write the picture description here
Thread is executing network operation, and is waiting for data to be passed.	Write the picture description here
Thread is idle.	Write the picture description here
Event Dispatch Thread that is busy.	Write the picture description here
Thread is executing disk operation.	Write the picture description here

Settings

Write the picture description here

Clicking this button opens a list of Settings:

Let’s illustrate a few of them:

Show Values Inline

When this function is enabled during debugging, variable values will be displayed on the right side of the code, as shown in the red box below:

Show Method Return Values

Enabling this feature during debugging displays the return value of the last executed method in the variable area. For example, first, to turn this function off, let’s debug the code and observe the variable area:

After this function is enabled, observe the changes in the variable area again:

Continue debugging:

Continue debugging:

This is a great feature to use when debugging a piece of code and wanting to see the end result of the last method called in that code.

Auto-Variables Mode

With this function enabled, the IDEA Debugger automatically evaluates some variables. When you execute at a breakpoint, the Debugger checks the state of the variables before and after the current debug, and optionally outputs the variables in the variable area. For example, before this function is enabled, the variables section outputs all variable information:

After this function is enabled, when you reach line 13, the Debugger detects that the num variable has not been used since then, so the variable will not be printed in the variables area.

Sort values alphabetically

If this function is enabled, the output in the variable area will be sorted alphabetically. It is very simple, not often used, and it is better to keep the default order.

Help

Write the picture description here

This goes without saying. If you don’t understand anything, you can check out the official help document, which is one of the best documents I’ve seen. The other operations :Settings,Pin, and Close are left to you.

Modifying variable values

During debugging, we can easily change the value of a variable as follows:

In the figure above, the current Value of result is calculated to be 10. Here, we change the calculation result to 100 by using Set Value.

Variable observation area

This field will display the value of the variable you are interested in. In debug mode, you can Add a variable to Watches and the value change will be displayed in the watch area. The operation is as follows:

Here we are interested in name and want to see how its value changes, so we give it “special care”. Note that since name is a member variable, it is also visible in the object view area. If it’s a local variable, this is definitely the way to go.

Classification of breakpoints

So far, we have briefly introduced the debugging area, breakpoint management area, evaluation expressions, these three areas of functionality. We mentioned breakpoints again and again above, but what is a breakpoint? As most of you already know, here’s a brief explanation:

A breakpoint is one of the functions of the debugger. It allows the program to pause where it is needed to help analyze the program.

In Android Studio, breakpoints are categorized into the following five categories:

Method breakpoints are the most familiar type of breakpoint. Let’s focus on the other four types of breakpoints.

Conditional breakpoints

Conditional breakpoints are breakpoints that occur under certain conditions, that is, we can set a breakpoint to be only interested in certain events. The most typical use is in a list loop where we want to pause the program when a particular element is present. For example, if we have a list of elements q, 1q, 2q, and 3q and we want to pause the program at 2q, we need to do the following:

Left-click at the breakpoint and fill in the filter Condition. Here we only care about 2q, so s.quals (“2q”)

Log breakpoint

This type of breakpoint does not stop the program, but prints the log message we want it to print, and then continues. The operations are as follows: Also click on the breakpoint and deselect Suspend in the dialog box that is displayed.

In the pop-up control panel, select Log Profile Expression, and then fill in the Log information you want to output as follows:

When the debugging process encounters this breakpoint, the output is as follows:

Exception breakpoints

An exception breakpoint is an exception that occurs during debugging (you can specify a certain type of exception) and is immediately located at the point where the exception was thrown. For example, in debugging exceptions, we are very concerned about runtime exceptions and hope to locate them in time when any running exceptions are generated, so this type of exception can be used at this time. Before going online, debugging of abnormal breakpoints is very helpful to reduce the probability of crash in the formal environment. Do as follows: From the Run menu item, select View Breakpoints (you can also click in the Breakpoints Management panel

), as follows:

In the Manage Breakpoints panel, click +

In the drop-down list that pops up, we select Java Exception Breakpoints

Here we select Search By Name and enter the type of exception we care about in the input box below. Here we are concerned with NullPointerException, and whenever a NullPointerException occurs during debugging, the debugger locates the exception.

Methods the breakpoint

Write the picture description here

(Skip it, I think everyone knows)

Filed WatchPoint

Write the picture description here

Filed WatchPoint is essentially a special breakpoint, also known as a property breakpoint: when a field value is changed, the program is suspended at the change. Usually in the debugging of multithreading is particularly useful, can help us locate the problem of concurrent errors in time. The breakpoint icon is slightly different from adding regular breakpoints

There are two ways to debug

So far, we’ve covered the basics of debugging, but there are quite a few children’s shoes on Android Studio

The two buttons are confused: Debug and Attach Process. Here is a brief introduction of the differences between the two:

• Debug: Install and run in Debug mode. Breakpoints can be set before or after running
• Attach Process: Allows you to Attach the debugger to any running process, compared to Debug. For example, we can attach the process to the process we want to debug. Then, set the relevant breakpoints where necessary.

In the specific debugging process, their own discretion can be selected. Later, I will take you step by step debugging Android Framework related source code, see: diy compile the latest Android source code and SDK and diy debugging Android source code