Remember adb to find Android App crash error record

Remember adb to find Android App crash error record

First of all, let me talk about the conclusion, because this kind of problem will occur when the memory is insufficient.
There is such a setting on the Xiaomi mobile phone
insert image description here
that can simulate this abnormality in many ways.
Then we will set the size of the logcat log.
If you have a lot of operations, it is best Well, set it up. If your operation can be reproduced in a short time, there is no need to adjust it. 256k is enough.
insert image description here
Then connect the mobile phone to the computer
and open the command line tool to clear the logcat log.

adb logcat -c

Then check the log

#需要打印时间和级别是Error的信息
adb logcat -v time *:E

This is just to print the log on cmd. Soon, you may not have time, then download the log. Haven’t the previous log been cleaned up? Let’s execute the command again

adb logcat -v time >C:/Users/EDY/Desktop/work/logcat.txt

At this time, the logcat log will be transmitted to the local, but pay attention, after you finish the operation, you can close the adb window, otherwise it will always write the log to the local file in windows, and it will not be written after closing. Then
search The "FATAL" keyword
insert image description here
can locate the error message. As for the real cause of the error, you have to let the development see it.

If you encounter ANR
, you have to look at the trace log.
Taking Xiaomi mobile phones as an example,
you may encounter two problems.
One is that everyone says adb pull /data/anr/traces.txt
but when you pull it yourself,
insert image description here
it reports an error because of different mobile phones. The manufacturer’s file name may be different
insert image description here
, but we don’t know which file we want, so we try to pull one first, and found the second problem, insufficient permissions, then we can use it

adb bugreport

insert image description here
He will tell you where to put the file
and then unzip it, and then all the things in the anr directory will be in the unzipped file

insert image description here

How to determine which file is what we need? We can look at the time of the log to see which one is near the time of your operation After
opening it, see if it is an error reported by your package
insert image description here
How to determine where the error message is
The following content is mine First of
all, we can determine the location of the ANR log according to the app package name and time when the ANR occurred, usually at the top of the traces content.
insert image description here

Then ANR must be the main thread exception, we can find the "main" thread part and check the main thread related status.
insert image description here

You can clearly see that the main thread is sleeping. Usually in multi-threaded development, it is easier to encounter ANR caused by the blocked state.

Secondly, we can continue to find the following thread call stack information
insert image description here

We are more familiar with this area. Just like looking at ordinary exceptions, we can clearly know that ANR occurred at line 28 of MainActivity. The reason is Thread.sleep(). At this time, we return to our own code level above, and the result is very clear.

Of course, ANR in actual development is usually not so simple, and some are not so easy to analyze. This requires everyone to learn from this article, combine actual development with more analysis, and optimize to increase your own capabilities.

Thread state
For the above thread state, compared with the java thread state, Linux refines many states, which makes it easier to analyze the current state.

Threads in java are not equivalent to threads in the operating system kernel. There is a mapping relationship between them. For Android, there is a one-to-one relationship between threads in java and threads in the kernel.
insert image description here

Guess you like

Origin blog.csdn.net/qq13933506749/article/details/130284313