This is an article I previously wrote about breakpoint debugging techniques in AS, which received a good response. I have since continued to improve and update some content, so I am publishing it again.

Debugging with breakpoints is an important method for analyzing code and solving bugs during software development. The use of debugging tools varies across different IDEs, but the debugging features provided are certainly comprehensive. Many programmers’ debugging skills remain at the basic level of single-step execution and breakpoint jumping, unaware of the many lesser-known but very convenient debugging techniques. This article takes Android Studio as an example and showcases some debugging techniques that most people do not know about. Mastering these will make you a debugging master.

There are two ways to debug an app. The first is to directly click the small bug icon next to the run button in the image below to run and debug the current project, which I believe everyone knows.

The second method is to debug an app that is already running, which is a more commonly used debugging method, namely Attach debugger to Android process. Click the third button next to the run button, which will pop up the Choose Process window. Select the corresponding process and click the OK button to enter debugging mode. At this point, we can directly set breakpoints in the necessary places to debug the code:

Next, we have common debugging methods. There are a row of operation buttons on the toolbar at the top of the Debug window, such as Step Over (single-step execution), Step Into (enter method), etc., as shown in the image:

The most straightforward way to set and remove breakpoints is to click in the blank space to the right of the line number of the target code line. Then, in the Debug window on the left side, there is a breakpoint browsing button View Breakpoints, located just below the stop button. You can browse all breakpoints in the project and can also add or delete breakpoints:

Sometimes, we set breakpoints inside a loop but only want to observe the execution at a specific iteration. Do we have to use the Run to Cursor function to keep jumping to the next breakpoint until we meet our requirements?

If you know about conditional breakpoints, you will wish you had known earlier. A conditional breakpoint allows developers to input conditions, for example, entering i == 5 in a fori loop will let the program run directly to the sixth iteration, allowing for debugging a breakpoint on a specific element in a for each loop. Simply right-click on the breakpoint, input the condition in the pop-up window, click the Done button, and when the program executes to the loop, it will stop at the iteration that meets the condition for debugging:

Printing logs is also a very effective way to track and analyze problems in the program. However, if our program is already running and in debug mode, and we want to print logs for a more intuitive analysis of the code, do we really have to stop debugging, add log code, and recompile and run it?

If you know about log breakpoints, you won’t have to go through all that trouble. Again, right-click on the breakpoint, uncheck the Suspeng checkbox (which means the program will not stop at this breakpoint for debugging), then check Log evaluated expression: and input the print statement. This way, when the program in debug mode reaches this point, it will not stop but will print the corresponding information in the console, such as:

For example, if there is a variable in our code, the value of this variable will affect the execution result of the program. If we want to observe how this variable affects the program’s execution under different assignments, do we have to modify the variable value in the code repeatedly and then rerun the program? This is obviously a very cumbersome operation. In fact, if you use the variable assignment feature in debug mode (Set Value), you only need to run once to achieve the desired observation effect. Set a breakpoint where the variable is used, then find the corresponding variable in the Variables window, modify the variable value, and execute:

In the Variables area and the Watches area, you can view the variable values or the properties of objects at the breakpoint in debug mode. However, it can still be somewhat inconvenient to view. In fact, you can view property values through a pop-up window. Just position the cursor over the variable used in the breakpoint code line, and the IDE will automatically pop up a small window. At this point, you can use the corresponding shortcut key or click on the variable in this small window to pop up the variable property value window. The shortcut key on Mac is command + F1, as shown in the image:

At breakpoints, if there are variable objects, the system provides an expression evaluation feature. For variable objects in the Variables view, we can input any calculation statement and view the real-time calculation results. The specific operation is to right-click on the variable object in the Variables view, select Evaluate Expression, a pop-up expression window will appear. Input any calculation statement you want, click the Evaluate button, and the Result will be displayed:

Typically, we add breakpoints for code inside methods, and rarely debug the methods themselves. However, if we just want to see the method’s parameters and return results, we can set a breakpoint on the first line of the method definition to debug the method itself. The icon style of the breakpoint will also be different:

Sometimes, we want to know when and where a custom variable changes. We can use variable breakpoints. The icon style of variable breakpoints is also different. Set a breakpoint on the line where the variable is defined, enable debug mode, and during the program execution, if the value of that variable changes, the program will automatically stop and locate the place where the variable value changed for the developer to debug:

During execution, the program may encounter various unknown exceptions. If we can make the program stop immediately when an exception occurs and locate the place where the exception occurred for debugging, that would be excellent. Fortunately, Android Studio provides such a feature.

Open the breakpoint manager, which can be accessed in two ways: click the menu Run and select View Breakpoints; or directly click the View Breakpoints icon in the Debug window. Click the plus button in the upper left corner to add various breakpoints, including the Method Breakpoints and Field Watchpoints mentioned earlier. Here, we select Exception Breakpoints. In the pop-up Enter Exception Class window, input the exception type to monitor:

The above are some very practical but rarely seen debugging techniques using Android Studio. Of course, all these operations can be opened using shortcut keys. When you move the mouse cursor over the corresponding icon, the corresponding shortcut key combination will be displayed for you to use as needed.

Of course, if you have better debugging techniques, feel free to leave a comment to share, so we can learn together and progress through communication.

Recent HighlightsGitHub Compilation | Those Excellent Open Source Date and Time Picker, There’s Always One for YouWarning | I Worked at a Company in Beijing for Two Months and Slept on the Street Last Night

Outstanding talents are not short of job opportunities, but they lack good opportunities that suit themselves. However, they often do not have the energy to find the most suitable one among a vast number of opportunities.

100offer will strictly screen the talents and companies on the platform, allowing the best talents to meet the best companies.

Scan the QR code below, register at 100offer, and talk about your expectations for the next job. Within a week, receive 5-10 good opportunities that meet your requirements!