Android Studio debugging steps
1. Set breakpoints
Double-click the blank area to the left of the code to set a breakpoint
2. Press the debug shortcut key to enter the debug mode to start the app
3. Trigger a breakpoint
After the application starts, when the execution reaches a breakpoint, the AS will automatically pop up the debug panel and start the debug mode. Next, analyze the function of each shortcut key.
4. Functional analysis
debug button
Look at the function of each shortcut key from left to right:
1. Show Execution Point :
When this button is clicked, the cursor will be positioned at the current debugging position. Using this function after we have traced the code can quickly continue to the next step of debugging.
2. Step Over:
Step over, clicking this button will cause the program to execute one line down. If the current line is a method call, the method called by this line will be executed before going to the next line without entering the method.
3. Step Into:
Step Into, executing this operation will cause the program to execute one line down. If the line has a custom method, it will enter the method to continue execution, if it is a method in the class library, it will not enter the method.
4. Force Step Into:
Force step into, similar to step into function, the main difference is: if the current line has any method, no matter whether the method is defined by us or provided by the class library, it can jump into the method continue to execute
5. Drop Frame:
Interrupt execution and return to the place where the method was called. During this process, the stack frame corresponding to the method will be removed from the stack without changing the context.
6. Force Run to Cursor:
Ignore the existing breakpoint, position the cursor to the corresponding position, and then execute Force Run to Cursor to execute to the specified place.
7. Evaluate expression:
You can get a certain variable in the program, and then input the operation to be performed, and the result can be displayed after evaluating, as shown in the figure below, when you want to know the length of the message, you can calculate the message variable and enter messageg .length to get the result.
Breakpoint management and view display
1. View Breakpoints :
Display the number and position of various current views, manage each breakpoint, and set enable and other attributes
2.Mute Breakpoints:
Use this button to switch the state of the breakpoint: enabled or disabled. During the debugging process, you can disable and temporarily disable all the breakpoints, so that the application can run normally. This function is very useful, for example, when you are in During the debugging process, when you suddenly don't want the breakpoint to interfere with the process you care about, you can temporarily disable the breakpoint.
3. Get thread dump:
Get thread dump , click this button to enter the thread dump interface, you can see the activity status of each thread in the system, the following one is the various status icons of Thread for online reference.
4. Restore Layout:
You can view the method currently pushed into the method stack, helping us return to the position where the method was called before.
5. Settings:
The Auto-Variables Mode here means that after this function is turned on, the Debugger of idea will automatically evaluate certain variables. When you execute at a breakpoint, the Debugger will detect the state of the variables before or after the current debugging point. Then selectively output in the variable area. Before this function is enabled, the variable area outputs all variable information:
In the Android Studio debugging process, we can also easily use the setvalue function to dynamically change the value of a variable to meet the debugging needs.
type of breakpoint
In Android Studio, breakpoints are divided into the following five types.
- Conditional breakpoints
- Logging breakpoints
- Exception breakpoints
- Method breakpoints
- Property breakpoints
Here we focus on understanding the following exception breakpoints and property breakpoints
The exception breakpoint is during the debugging process, once an exception occurs (you can specify a certain type of exception), it will immediately locate the place where the exception is thrown. For example, in debugging exceptions, we are very concerned about runtime exceptions, and hope to locate any runtime exceptions in time, then we can use this type of exception at this time
Filed WatchPoint is essentially a special kind of breakpoint, also known as attribute breakpoint: when a field value is modified, the program pauses at the modification. This is especially useful when debugging multiple threads.
performance optimization tool
The memory analysis tool Memory that comes with Android Studio can easily view the application memory and display the memory usage in real time. When a memory leak occurs, the main performance is memory jitter, and the available memory is gradually decreasing. We can check the actual situation. Analysis, so as to use tools such as leakCanary to further analyze problems such as memory leaks and OOM.
Several function buttons are provided in Memory to help us operate and view the memory.
1. Initial GC :
This command will make the APP perform a Full GC. Generally, it is executed once before Dump Heap, which will reduce many used objects.
2. Dump Java Heap:
Java Heap is a runtime data area allocated by all class instances and array objects, during which all Java VM threads share the data in Heap during execution. Then a Java heap dump is equivalent to a snapshot generated at a specific point in time.
We can select the heap type to view in the upper left corner
App heap - the heap used by the current app
Image heap - the memory map of the current app on the hard disk
Zygote heap - the library, runtime class, and constant data set inherited when zygote is copied. The zygote space is created when the device starts, and the space here is never allocated.
The following steps are a typical workflow:
- Select a class name in the HPROF file viewing tool;
- select an instance of the class;
- View reference tree;
- When needed, you can right-click the entry that references the tree species to jump to the source code or example.
3. Start Allocation Tracking:
This function can record the memory allocation of each thread and each method in a certain interval, and is mainly used to debug the case of frequent GC caused by a short-term memory explosion in a complex system. How to use: Click once first, then you will see the Memory Recorder start to rotate, and then start to do corresponding operations on the APP. Click again at the right time to end the recording. A .alloc file can be generated
By analyzing the alloc data, we can know the heap size allocated by all the called methods in a certain thread. Through these data, we can optimize the method-level heap program.
LeakCanary
LeakCanary is an automatic memory leak detection artifact open sourced by Square. It is a memory leak detection library for Android and Java, which can greatly reduce OOM problems encountered in development.
The method of use is also very simple, just initialize in the Application, and then watch where memory leaks need to be detected
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
}
public class ExampleApplication extends Application {
@Override public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
// Normal app init code...
}
}
LeakCanary Chinese user manual
If there is a memory exception in the application, it can help us locate where the problem occurs:
TraceView
TraceView analyzes the performance of the application from the perspective of the running time of each method.
Let’s take a look at the entire TraceView interface. The entire interface includes upper and lower parts. The above is the execution status of each thread in the process you are testing. Each Threads occupy one line; below are the values for each metric executed by each method.
The upper part is the timeline of each thread running in your test process. As you can see in the figure below, only one main thread is executing.
There are two main ways to use TraceView:
The easiest way is to open DDMS directly, select a process, and then press the "Start Method Profiling" button above. When the red dot turns black, it means that TraceView has started working. Then I can swipe the list (the operation on the mobile phone will definitely be very stuck now, because the Android system is detecting the call of each Java method in the Dalvik virtual machine, which is my guess). It is best not to operate for more than 5s, because it is best to conduct a small-scale performance test. Then press the button you just pressed again, and the above picture will appear after a while, and then you can start the analysis.
The second way is to use the android.os.Debug.startMethodTracing(); and android.os.Debug.stopMethodTracing(); method, when this code is run, a trace file will be generated in the /sdcard directory , you can also call startMethodTracing(String traceName) to set the file name of the trace file, and finally you can use the adb pull /sdcard/test.trace /tmp command to copy the trace file to your computer, and then use the DDMS tool to open it and the above will appear Figured it out.
There is a number in front of each method, which may be the sequence number of all methods according to Incl CPU Time. After clicking a method, you can see that there are two parts, one is Parents, and the other is Children.
Parent indicates the method that calls this method, which can be called the parent method
Children represent other methods called in this method, which can be called sub-methods
The horizontal axis in the above figure indicates the various time taken by each method execution, the number of calls, etc. Let’s look at it in turn
- Incl Cpu Time: This indicator indicates the total execution time of this method and its sub-methods
- Excl Cpu Time: It is the time taken by other operations after the method itself removes the sub-method.
- Incl Real Time: It should be the actual running time of this method. It may be because the actual execution time of the method is slightly longer than the CPU Time due to CPU context switching, blocking, GC and other reasons. .
- Excl Real Time: After the method itself removes sub-methods, the actual time taken by other operations.
- Calls + Recur Calls / Total: A Call indicates the number of times this method is called, and Recur Call indicates the number of recursive calls
- Cpu Time / Call: As the name can tell. . . . .
Reference article:
Android Studio debugging skills you don't know
Reprinted: https://blog.csdn.net/zoky_ze/article/details/65958628