If you don’t follow us, please subscribe to 😝 and if you find these articles interesting, please share, retweet, comment and like 😝!
1. Log filtering and folding
Sometimes the log information in Logcat is very long, and some unnecessary information is also printed, such as [time + thread ID] in the figure below.
In daily development, we also encounter another situation. For example, according to the current UI rendering situation, we need to print a certain value of the UI at any time to help us observe the UI, and when certain conditions are reached, enter a [result log] we get. That is to say, there will be a lot of useless logs that have to be printed before we get our result log, which will be very troublesome when we need to find the result log.
2. Customize breakpoint execution conditions
This is a method that executes a click event. After the click occurs, the NavController jumps from the current HomeFragment to the EmailFragment. Then we put a breakpoint on the first line. We already know that the code will crash if the email subject contains the keyword [Bonjour], and not if it doesn’t, so we don’t need the breakpoint to work every time.
Here we can right-click the breakpoint and enter our Condition statement in Condition. The breakpoint will only take effect when the Condition allows. The code for conditional statements can be written in both Kotlin and Java, as shown below.
Then, if we want to trace the problem further after jumping to the EmailFragment, I make a breakpoint in the EmailFragment onCreate method (as shown below), and then we get the same problem we were talking about earlier: The breakpoint also works when the condition is not met, so what do we do?
We can right-click on this breakpoint and click more.
After selecting the current breakpoint on the left, click Disable until breakpoint hit on the right to select the conditional breakpoint. The new breakpoint will not take effect until the breakpoint it follows takes effect.
3. Suspend the thread
When you right-click on any breakpoint, there is a Suspend option. All means that when you debug a problem in a multithreaded application, once the breakpoint is in effect, All threads are suspended. Thread means that only the current Thread is suspended. So when we debug a problem in a background Thread, we can select Thread so that we don’t block the main Thread during debugging.
There is also a shortcut for opening and closing breakpoints: Alt + Click for Windows users, Mac Option + Click.
4. Dynamic printing
In detail, when many people including me used to debug, they would add print to the place where they needed to debug to output information for troubleshooting. This provides a fast and convenient method, which can not only pollute our code, but also output any information at any time.
Add a breakpoint where you want to print, unsuspend all threads, and select Evaluate and log. When the code reaches the breakpoint, it will not pause, but will print the log based on the information we set.
5. Breakpoint grouping
Step on the breakpoint
It really hurts to say this. I often miss the key line of the problem because I click the next step too fast when I am debugging, so I have to run the code again, re-debug and click the next step again and again.
On devices running Android 10, there is a Drop Frame button in the debug interface that lets you jump out of the current method stack and go back to the previous step, which prevents you from having to re-run the code if you miss a breakpoint.
7. Observe objects
When we debug, we can view the object in the current scope and its properties from the debug window. Sometimes we can see if it is the same object in different pages. Find a piece of paper, write down the ID of the object, and debug it on another page to see if the ID is the same 😂
This allows you to create a custom Label by right-clicking on the Object and selecting Mark Object. During debug, the same Object will appear as the name of the Label you set, helping us to easily determine if it is a unified Object.
By the way, on any piece of code, clicking on the line number allows you to quickly execute from the current breakpoint to the target line and pause. This is the first time I’ve seen this, and it feels like Android Studio used 😭 for nothing
In addition, during debugging, we can select the “Evaluate Expression” button in the Debug window to dynamically observe the object. After clicking it, a calculation box will pop up, and we can enter any object and attribute observation in the current scope.
I have to say that this is really handy. The only way I had to do this before was to print 😂. Of course, instead of just observing the object, we can write any code to observe the value we want, as shown in the following figure.
8. Incremental updates
9. Error stack analysis
Usually in our App, we will inherit the SDK of online bug feedback, such as Bugly. In Bugly, we will get the exception stack information of crash, similar to the following figure.
To copy all, open our Android Studio, select Analyze → Analyze Stack Trace or Thread Dump, paste the exception Stack information, and click OK.
Android Studio displays this stack exception information on the console, and with the existing code linked, we can click to jump to the line of problem.
Well, that’s all I’m going to share today. For more details, you can click on [Read the original article] and check it out on YouTube. I really hope there is a “walkthrough” for Android Studio. 😂
I’m Wanbo, come on!
If you don’t follow us, please subscribe to 😝 and if you find these articles interesting, please share, retweet, comment and like 😝!
