Learn Debug for Android Studio

preface

As the saying goes, to do good work must first sharpen its tools, for a programmer, IDE is our tools. The more familiar an IDE is, the more productive it is (more time spent paddling), so to be effective (more fish), learn how to use the IDE.

Being an Android developer is bliss, thanks to Google dad and JetBrain’s support, so you have the perfect IDE — Android Studio (AS for short), which is a bit of a memory drain, 😁, Of course, none of this matters on the 16GB MBP. Although I have been working on Android development for 3 years, I have only used some basic operations for AS, and many convenient skills have not been used, far from giving full play to its biggest advantages, so I decided to learn from scratch how to maximize the use of AS.

I plan to study AS in modules and summarize the article. In the first chapter, I will start from the most important Debug for programmers.

To the chase

AS a programmer, debugging skills are essential, and AS also provides us with powerful debugging capabilities. So today we will take a good look at the debugging function provided by AS.

Learn from Android Studio 3.6.2.

Open the debug

Let’s start with the toolbar icon:

Note that 123568 is not a debug button.

  1. The Run button:AppAlready run, display the icon, click re-runApp;AppWithout running, the picture appears as a green triangle.
  2. Apply Change and Restart Activity button:Through the restartActivityResource and code changes are applied without restarting the application. Usually used to modify code or resource files.
  3. Apply Code Changes button: Attempts to Apply only Code Changes without rebooting anything. Usually used to modify only the code without modifying any resources.
  4. The Debug button:openDebugMode.
  5. Coverage button: To be explored (tell me if you know).
  6. Profile button: There will be a separate article explaining this feature later.
  7. Attach debugger to Android Process button: AppIt is running. Click the button and select the process to be debugged.
  8. Stop button:Stop runningApp.

Start debugging

When you enter the Debug mode, the Debug window is displayed at the bottom of the AS. If the Debug window is not opened, choose View > Tool Windows > Debug. Let’s start with an overview of the Debug window:

  • Menu displays control area
  • Area 1 Breakpoint management area
  • Area 2 Single step debugging area
  • 3 area stack frame thread area
  • Area 4 Object variable observation area

Here are the explanations.

Menu displays control area

First of all, let’s talk about the menu on the left to display the control area, click the button, the menu will pop up, tick means that the menu to display, the picture tick all the menu, so you can see the corresponding menu on the right, if you cancel the menu, the corresponding menu on the right will also be hidden. This menu shows that you can choose according to your own needs.

Here we go!!

Area 1 Breakpoint management area

In vertical order:

  1. Return Android Debugger:Back into thedebugMode (App will not run again)
  2. Resume Program: Skip to the next breakpoint.
  3. Pause Program: pauses the operation
  4. Stop Debugger: Stops the breakpoint mode
  5. View Breadpoints: View all breakpoints (explained separately later)
  6. Mute Breadpoints: Enable/disable all breakpoints
  7. Get Thread Dump: Get Thread Dump.
  8. Setting: Controls the display of some menus
  9. Pin Tab: Fixed Tab when debugging multiple programs. Function grope for ing

Here to find the key to explain:

The View Breadpoints:

So let’s start with the picture above

Breakpoint display area:

Shows all breakpoints where we can quickly remove unnecessary breakpoints and speed up the program. Of course, we can also add exceptions that we care about, such as NullPointerException. Click ➕ in the upper left corner, and the menu pops up (as shown below). You can choose different types according to your own needs. Then type NullPointerException in the search box to blur the match, and select NullPointerException to add the breakpoint display.

Menu setting area:

This menu can be used by clicking on View Breakpoints in the breakpoint management area on the left, or by right-clicking on the red dot of the breakpoint.

  1. Enable: indicates whether to Enable the breakpoint.

  2. Suspend: By default, The Android system suspends the application process when it accesses a chunk of memory that you have allocated to the watch point. “All” means to suspend All threads, and “Thread” means to suspend the current Thread. You can deselect this option, and the red breakpoint turns yellow when you deselect it, as you can see in the image above.

  3. Condition: This is very useful. It is called a conditional break point. It’s used in loops, like a for loop, when I is equal to 8, to do something, do you want to loop over and over again? (I’ve done this before 😂), you can actually set conditions directly in the condition, as shown below

    You can see usconditionWhen I add a condition, there’s a little question mark under the red breakpoint,numI’m going to go straight to 8 instead of going all the way to 8.

  4. ‘Breakpoint hit’ message: The check box will output Breakpoint hit.

  5. Stack Trace: Displays Stack information.

  6. Evaluate and log: Evaluate and log: Evaluate and log: Evaluate and log: Evaluate and log This is a hassle, and if you forget it, it will affect the aesthetics of the code. At this point, you need log breakpoints, as shown below

    So we can print the variables that we want to see.

  7. Remove once hit: Remove once hit, so that we do not forget to cancel the breakpoint.

Heavy emphasis is coming!!

Area 2 Single step debugging area

There are only a few single step buttons at the top of the Debug window, but that’s enough for normal use. To show all of the AS single-step buttons, I describe the single-step buttons under the Run menu, AS shown below

Step Over(F8): skip to the next line of code (without entering the method) and pause if there is a breakpoint inside the method.

Force Step Over: Execute the next Step on the method line without pausing at the breakpoint, regardless of whether there is a breakpoint or not

Step Into(F7): Step Into a method if the breakpoint contains a submethod (not a method in the official library).

Force Step Into: Forces a single Step Into any method based on Step Info.

Smart Step Info: The breakpoint contains two or more method chain calls that you can optionally enter, including anonymous inner classes and lambda expressions, as shown in the figure below.

get
getAccessToken

When registering a Step Out(⇧F8), as opposed to a Step leap, advance to the next line outside the current method.

Run to Cursor: Execute until the Cursor exits (there is no breakpoint).

Force Run to Cursor: Forces the Cursor to exit (whether there is a breakpoint or not).

Drop Frame: Clicking this button will return you to the call of the current method and re-execute it, with the values of all context variables returning to that time. As long as there are parent methods in the call chain, you can jump to any of them.

Evaluate Expression: You can enter any syntactic evaluation Expression, including variable, method, and other calls.

  • Computed expression

  • The method call

3 area stack frame thread area

Zone 3 contains Frames and Threads. Frames can examine the stack frame that caused the current breakpoint to be encountered, and is associated with the following four view variables. Threads displays all Threads of the current process. This is an area I use very little, more functions for me to explore, for this area to play 6 masters, you can share in the comments section.

Area 4 Object variable observation area

And this is the area that we use a lot, and the values of the variables that we need to observe, are all observed in this area. I believe we have all encountered that when we write code, we need to perform different operations according to the state returned by the interface, but there is only one state forever. How can we debug each state and our code business logic is right? I used to force a line of code to change the state and then delete it (really low😂). Now we can use the setValue function to change the value of a variable, similar to Evaluate.

Sometimes there are too many variables, and we only need to observe the value of a certain variable, we can use Add Watches.

The Google website also provides us with a lot of more detailed debugging tips, you can take a look at the time.

conclusion

Android Studio debugging here most of our learning, I hope you had better do your own debugging every feature, deepen the impression. Later, if I find more tips, I’ll add them. Of course, if you have your own debugging tips, please share them in the comments section.

This is the end of the first article about Android Studio. The next article is about Logcat. If you want to learn about Android Studio, please feel free to post in the comments section.