ANR分析总结

学习笔记：这里只是一些简单ANR问题，还在学习中。

ANR(Application Not Responding)应用程序无响应。如果你应用程序在 UI 线程被阻塞太长时间，就会出现 ANR，通常出现 ANR，系统会弹出一个提示提示框，让用户知道，该程序正在被阻塞，是否继续等待还是关闭。

ANR类型

出现ANR的一般有以下几种类型：

1:KeyDispatchTimeout（常见）

input事件在5S内没有处理完成发生了ANR。
logcat日志关键字：Input event dispatching timed out

2:BroadcastTimeout

前台Broadcast：onReceiver在10S内没有处理完成发生ANR。

后台Broadcast：onReceiver在60s内没有处理完成发生ANR。
logcat日志关键字：Timeout of broadcast BroadcastRecord

3:ServiceTimeout

前台Service：onCreate，onStart，onBind等生命周期在20s内没有处理完成发生ANR。

后台Service：onCreate，onStart，onBind等生命周期在200s内没有处理完成发生ANR
logcat日志关键字：Timeout executing service

4：ContentProviderTimeout

ContentProvider 在10S内没有处理完成发生ANR。
logcat日志关键字：timeout publishing content providers

一、导出并查看 ANR 日志

执行命令：

adb bugreport bugreport.zip
adb pull /data/debuglogger/mobilelog

可以导出设备所有 bug 日志，执行命令后，在指定文件夹内得到一个 zip 文件，将文件解压后打开，文件目录如下所示：

其中，设备的 anr 日志会保存在该路径下：C:\Users\xxx\Desktop\bugreport\FS\data\anr，如图：

另外，该文件 C:\Users\xxx\Desktop\bugreport\bugreport-100110603-TP1A.220624.014-2022-10-12-09-49-59.txt 内也有有 anr 日志的打印，我们可以通过以下关键词搜索该文件的一些异常信息，如：

"main" prio= 搜索 anr 相关信息

beginning of crash 搜索 crash 相关信息

CPU usage from 搜索 cpu 使用信息

二、ANR 日志如何分析

一个 ANR 日志，会包含当前设备中所有进程的使用情况，每个进程开头都会

以----- pid 17376 at date ----- 来开头，

以 ----- end 17376 ----- 来结尾，
如下所示：

----- pid 17376 at 2022-10-11 09:52:04.264664750+0800 -----
Cmd line: com.android.vending
...
...
...
----- end 17376 -----

另外，每个进程日志中都会有一些进程内存相关的信息，如：

----- pid 17376 at 2022-06-16 16:56:04 -----
Cmd line: com.android.vending
...
...
Total number of allocations 274640   // 进程创建到现在一共创建了多少对象
Total bytes allocated 13MB   // 进程创建到现在一共申请了多少内存
Total bytes freed 5821KB   // 进程创建到现在一共释放了多少内存
Free memory 4562KB   // 空闲内存（可用内存）
Free memory until GC 4562KB   // GC前的空闲内存
Free memory until OOME 248MB   // OOM之前的可用内存，当这个值很小的时候，已经处于内存紧张状态，应用可能占用了过多的内存
Total memory11MB  // 当前总内存（已用+可用）
Max memory 256MB  // 进程最多能申请的内存 
...
----- end 17376 -----

另外，每个进程日志中都会有进程堆栈信息，堆栈信息非常重要，它展示了发生 ANR 的进程当前的所有线程状态。如下所示：

----- pid 17376 at 2022-06-16 16:56:04 -----
Cmd line: com.android.vending
...
suspend all histogram:  Sum: 141.888ms 99% C.I. 0.012ms-91.709ms Avg: 4.892ms Max: 100.514ms
DALVIK THREADS (56):
"Signal Catcher" daemon prio=10 tid=6 Runnable
  | group="system" sCount=0 ucsCount=0 flags=0 obj=0x132c08e0 self=0xb400007dceb186f0
  | sysTid=17386 nice=-20 cgrp=default sched=0/0 handle=0x7c47bdbcb0
  | state=R schedstat=( 44080464 23366075 22 ) utm=3 stm=0 core=2 HZ=100
  | stack=0x7c47ae4000-0x7c47ae6000 stackSize=991KB
  | held mutexes= "mutator lock"(shared held)
  native: #00 pc 00000000005376cc  /apex/com.android.art/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream >&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+128) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #01 pc 00000000006f0e24  /apex/com.android.art/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream >&, bool, BacktraceMap*, bool) const+236) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #02 pc 00000000006fe6b0  /apex/com.android.art/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+208) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #03 pc 0000000000364174  /apex/com.android.art/lib64/libart.so (art::ThreadList::RunCheckpoint(art::Closure*, art::Closure*)+440) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #04 pc 00000000006fce50  /apex/com.android.art/lib64/libart.so (art::ThreadList::Dump(std::__1::basic_ostream >&, bool)+280) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #05 pc 00000000006fc844  /apex/com.android.art/lib64/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream >&)+292) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #06 pc 00000000006d5914  /apex/com.android.art/lib64/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream >&)+184) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #07 pc 00000000006e19c0  /apex/com.android.art/lib64/libart.so (art::SignalCatcher::HandleSigQuit()+468) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #08 pc 0000000000573e40  /apex/com.android.art/lib64/libart.so (art::SignalCatcher::Run(void*)+264) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #09 pc 00000000000c1e40  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 037ccd4f6c32456866be69c5a0a56591)
  native: #10 pc 0000000000054b50  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 037ccd4f6c32456866be69c5a0a56591)
  (no managed stack frames)

"main" prio=5 tid=1 Waiting
  | group="main" sCount=1 ucsCount=0 flags=1 obj=0x720c41e8 self=0xb400007dceb13380
  | sysTid=17376 nice=0 cgrp=default sched=0/0 handle=0x7f1ae4f4f8
  | state=S schedstat=( 520024534 625550234 691 ) utm=28 stm=23 core=5 HZ=100
  | stack=0x7fea717000-0x7fea719000 stackSize=8188KB
  | held mutexes=
  at jdk.internal.misc.Unsafe.park(Native method)
  - waiting on an unknown object
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:194)
  at aidy.get(PG:5)
  at aihp.c(PG:1)
  at gdu.az(PG:2)
  at gge.j(PG:33)
  - locked <0x07048dde> (a com.google.android.finsky.application.classic.ClassicApplication)
  at gge.onCreate(PG:3)
  at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1266)
  at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6826)
  at android.app.ActivityThread.-$$Nest$mhandleBindApplication(unavailable:0)
  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2171)
  at android.os.Handler.dispatchMessage(Handler.java:106)
  at android.os.Looper.loopOnce(Looper.java:201)
  at android.os.Looper.loop(Looper.java:288)
  at android.app.ActivityThread.main(ActivityThread.java:7941)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:569)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1015)

 ...

"Jit thread pool worker thread 0" daemon prio=5 tid=8 Native
  | group="system" sCount=1 ucsCount=0 flags=1 obj=0x132c09d0 self=0xb400007dceb43e40
  | sysTid=17389 nice=9 cgrp=default sched=0/0 handle=0x7c478e1cb0
  | state=S schedstat=( 46231998 254143847 68 ) utm=3 stm=0 core=7 HZ=100
  | stack=0x7c477e2000-0x7c477e4000 stackSize=1023KB
  | held mutexes=
  native: #00 pc 000000000004f66c  /apex/com.android.runtime/lib64/bionic/libc.so (syscall+28) (BuildId: 037ccd4f6c32456866be69c5a0a56591)
  native: #01 pc 000000000047cc80  /apex/com.android.art/lib64/libart.so (art::ConditionVariable::WaitHoldingLocks(art::Thread*)+140) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #02 pc 000000000047cb18  /apex/com.android.art/lib64/libart.so (art::ThreadPool::GetTask(art::Thread*)+120) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #03 pc 0000000000619810  /apex/com.android.art/lib64/libart.so (art::ThreadPoolWorker::Run()+136) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #04 pc 00000000006196f0  /apex/com.android.art/lib64/libart.so (art::ThreadPoolWorker::Callback(void*)+160) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #05 pc 00000000000c1e40  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+208) (BuildId: 037ccd4f6c32456866be69c5a0a56591)
  native: #06 pc 0000000000054b50  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64) (BuildId: 037ccd4f6c32456866be69c5a0a56591)
  (no managed stack frames)
...
----- end 17376 -----

如上截图中，有三个线程，一个是 Signal Catcher 线程，一个是 main 线程，一个是 Jit thread pool worker thread 0，他们的线程状态分别是 Runnable 、 blocked 和 native 状态。

而在 Java 中，线程状态有6种，如下所示：

NEW - 创建状态：当我们new一个Thread的时候，线程就处于创建状态；
RUNNABLE - 就绪或运行状态：当我们调用线程的 start() 方法，线程就会进入该状态；

另外，还有两种情况也会使线程进入就绪状态：

线程之前处于阻塞状态，如果阻塞解除了，也会进入就绪状态

线程之前处于运行状态，如果执行了 Thread.yield() 方法，则线程会进入就绪状态

BLOCKED - 阻塞状态：该状态下，线程正在阻塞等待某个锁。
WATING - 等待状态：当调用了以下某一个方法，线程就会处于等待状态：

Object.wait
Thread.join
LockSupport.park

处于等待状态的线程正在等待另一个线程执行特定操作，例如：

在一个对象上调用了 Object.wait() 的线程正在等待另一个线程调用 Object.notify() 或 Object.notifyAll() 。

已调用 Thread.join() 的线程正在等待指定线程终止。

TIMED_WAITING - 定时等待状态：指定等待时间的等待状态，当调用以下具有指定正等待时间的方法之一，线程就会处于定时等待状态：

Thread.sleep(long millis)
Object.wait(long timeout)
Thread.join(long millis)
LockSupport.parkNanos(long nanos)
LockSupport .parkUntil(long deadline)

TERMINATED - 终止状态：终止状态，线程已完成执行就会进入此状态。

那么，上述日志中的 native 状态是什么呢？

其实该状态是 cpp 代码中定义的线程状态，他跟 java 定义的线程状态关系如下：

由上可知，native 状态对应的 java 线程状态是 runnable 状态。

堆栈信息是我们分析 ANR 的第一个重要的信息，一般来说：

主线程处于 BLOCK / WAITING / TIMEWAITING 状态，基本上是函数阻塞导致的 anr

若主线程无异常，则应该排查 CPU 负载和内存环境等其他因素

另外，在 anr 日志中，还有一些常见参数，他们的含义如下：
main：main标识是主线程，如果是线程，那么命名成“Thread-X”的格式,x表示线程id,逐步递增。
prio：线程优先级,默认是5
tid：tid不是线程的id，是线程唯一标识ID
group：是线程组名称
sCount：该线程被挂起的次数
dsCount：是线程被调试器挂起的次数
obj：对象地址
self：该线程Native的地址
sysTid：是线程号(主线程的线程号和进程号相同)
nice：是线程的调度优先级
sched：分别标志了线程的调度策略和优先级
cgrp：调度归属组
handle：线程处理函数的地址。
state：是调度状态
schedstat：从 /proc/[pid]/task/[tid]/schedstat读出，三个值分别表示线程在cpu上执行的时间、线程的等待时间和线程执行的时间片长度，不支持这项信息的三个值都是0；
utm：是线程用户态下使用的时间值(单位是jiffies）
stm：是内核态下的调度时间值
core：是最后执行这个线程的cpu核的序号。

三、分析

1、通过在 events_log 中检索 am_anr 关键字，就可以找到发生ANR的进程，譬如以下日志：

10-16 00:48:27 820 907 I am_anr: [0,29533,com.android.systemui,1082670605,Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000114 (has extras) }]

表示在 10-16 00:48:27 这个时刻，PID 为 29533 进程发生了 ANR，进程名是 com.android.systemui。

接下来可以在 sys_log 检索 ANR in 关键字，找到发生 ANR 前后的 CPU 使用情况：

10-16 00:50:10 820 907 E ActivityManager: ANR in com.android.systemui, time=130090695
10-16 00:50:10 820 907 E ActivityManager: Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x50000114 (has extras) }
10-16 00:50:10 820 907 E ActivityManager: Load: 30.4 / 22.34 / 19.94
10-16 00:50:10 820 907 E ActivityManager: Android time :[2015-10-16 00:50:05.76] [130191,266]
10-16 00:50:10 820 907 E ActivityManager: CPU usage from 6753ms to -4ms ago:
10-16 00:50:10 820 907 E ActivityManager:   47% 320/netd: 3.1% user + 44% kernel / faults: 14886 minor 3 major
10-16 00:50:10 820 907 E ActivityManager:   15% 10007/com.sohu.sohuvideo: 2.8% user + 12% kernel / faults: 1144 minor
10-16 00:50:10 820 907 E ActivityManager:   13% 10654/hif_thread: 0% user + 13% kernel
10-16 00:50:10 820 907 E ActivityManager:   11% 175/mmcqd/0: 0% user + 11% kernel
10-16 00:50:10 820 907 E ActivityManager:   5.1% 12165/app_process: 1.6% user + 3.5% kernel / faults: 9703 minor 540 major
10-16 00:50:10 820 907 E ActivityManager:   3.3% 29533/com.android.systemui: 2.6% user + 0.7% kernel / faults: 8402 minor 343 major
10-16 00:50:10 820 907 E ActivityManager:   3.2% 820/system_server: 0.8% user + 2.3% kernel / faults: 5120 minor 523 major
10-16 00:50:10 820 907 E ActivityManager:   2.5% 11817/com.netease.pomelo.push.l.messageservice_V2: 0.7% user + 1.7% kernel / faults: 7728 minor 687 major
10-16 00:50:10 820 907 E ActivityManager:   1.6% 11887/com.android.email: 0.5% user + 1% kernel / faults: 6259 minor 587 major
10-16 00:50:10 820 907 E ActivityManager:   1.4% 11854/com.android.settings: 0.7% user + 0.7% kernel / faults: 5404 minor 471 major
10-16 00:50:10 820 907 E ActivityManager:   1.4% 11869/android.process.acore: 0.7% user + 0.7% kernel / faults: 6131 minor 561 major
10-16 00:50:10 820 907 E ActivityManager:   1.3% 11860/com.tencent.mobileqq: 0.1% user + 1.1% kernel / faults: 5542 minor 470 major
...
10-16 00:50:10 820 907 E ActivityManager:  +0% 12832/cat: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager:  +0% 13211/zygote64: 0% user + 0% kernel
10-16 00:50:10 820 907 E ActivityManager: 87% TOTAL: 3% user + 18% kernel + 64% iowait + 0.5% softirq

这一段日志它包含的信息量非常多：

发生 ANR 的时间：events_log 中，ANR 的时间是 00：48：27，因为 AMS.appNotResponding() 首先会打印 events_log，然后再打印 syst_log，所以，在 syst_log 中，找到ANR的时间是 00:50:10。可以从这个时间点之前的日志中，还原ANR出现时系统的运行状态。
打印ANR日志的进程：ANR日志都是在 system_server 进程的AMS线程打印的，在events_log和sys_log中，都能看到 820 和 907，所以system_server的PID是 802，AMS 线程的 TID 是 907。ANR的监测机制实现在 AMS线程，分析一些受系统影响的ANR，需要知道system_server进程的运行状态。
发生ANR的进程：ANR in关键字就表明了当前ANR的进程是com.android.system.ui，通过events_log，知道进程的PID是 29533。
CPU使用统计时间段：CPU usage from XX to XX ago关键字表明了这是在ANR发生之前一段时间内的CPU统计。类似的还有CPU usage from XX to XX after关键字，表明是ANR发生之后一段时间内的CPU统计。
发生ANR的原因：Reason关键字表明了当前发生ANR的原因是，处理TIME_TICK广播消息超时。隐含的意思是TIME_TICK是一个串行广播消息，在 29533 的主线程中，执行BroadcastReceiver.onReceive()方法已经超过10秒。（也有可能时其他原因，导致systemui进程分配不到CPU时间，从而主线程处理广播消息超时，发生了ANR。）

注：这里不谈具体原因，只说怎么看日志，太深奥了不晓得。

2、Blocked——ANR

Blocked关键字，在 ANR 日志里可以直接搜索 Blocked，看个例子：


"main" prio=5 tid=1 Blocked
  | group="main" sCount=1 dsCount=0 obj=0x75bd5818 self=0x7f8549a000
  | sysTid=29533 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x7f894bbe58
  | state=S schedstat=( 289080040422 93461978317 904874 ) utm=20599 stm=8309 core=0 HZ=100
  | stack=0x7fdffda000-0x7fdffdc000 stackSize=8MB
  | held mutexes=
  at com.mediatek.anrappmanager.MessageLogger.println(SourceFile:77)
  - waiting to lock <0x26b337a3> (a com.mediatek.anrappmanager.MessageLogger) held by thread 49
  at android.os.Looper.loop(Looper.java:195)
  at android.app.ActivityThread.main(ActivityThread.java:5718)
  at java.lang.reflect.Method.invoke!(Native method)
  at java.lang.reflect.Method.invoke(Method.java:372)
  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:975)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:770)

可以发现主线程 Blocked，并且这里有一行：

  - waiting to lock <0x26b337a3> (a com.mediatek.anrappmanager.MessageLogger) held by thread 49

其含义就是，主线程正在被 block，其正在等待线程49 释放锁，最终因此导致出现了 ANR。
可以接着搜关键字 tid=49，如果简单的话一般会是：

"xxxThread" prio=5 tid=49 Sleeping

基本也可以定位到问题，复杂的不晓得。

3、Slepping——ANR
Slepping关键字，在 ANR 日志里可以直接搜索 Slepping，看个例子：
MainActivity 代码如下：

class MainActivity : AppCompatActivity() {   
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }

    /**
     * 点击睡眠 10s
     */
    fun clickToSleep(view: View) {
        Thread.sleep(10_000)
    }
}

当点击按钮睡眠 10s 后，我们左滑或者点击返回键退出 MainActivity（由于主线程正在睡眠，所以此时是无法退出成功的），等待一段时间，系统将会弹出 ANR 弹窗。

"main" prio=5 tid=1 Sleeping
  | group="main" sCount=1 dsCount=0 flags=1 obj=0x72e0ee78 self=0x79aafbcc00
  | sysTid=16356 nice=-10 cgrp=default sched=0/0 handle=0x79ac524ed0
  | state=S schedstat=( 1075827038 33414740 291 ) utm=93 stm=14 core=2 HZ=100
  | stack=0x7fe35ed000-0x7fe35ef000 stackSize=8192KB
  | held mutexes=
  at java.lang.Thread.sleep(Native method)
  - sleeping on <0x04fbafa5> (a java.lang.Object)
  at java.lang.Thread.sleep(Thread.java:440)
  - locked <0x04fbafa5> (a java.lang.Object)
  at java.lang.Thread.sleep(Thread.java:356)
  at com.example.demoproject.view.MainActivity.clickToSleep(MainActivity.kt:57)
  at java.lang.reflect.Method.invoke(Native method)
  at androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:441)
  at android.view.View.performClick(View.java:7259)
  at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1194)
  at android.view.View.performClickInternal(View.java:7236)
  at android.view.View.access$3600(View.java:801)
  at android.view.View$PerformClick.run(View.java:27896)
  at android.os.Handler.handleCallback(Handler.java:883)
  at android.os.Handler.dispatchMessage(Handler.java:100)
  at android.os.Looper.loop(Looper.java:214)
  at android.app.ActivityThread.main(ActivityThread.java:7397)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:935)

从堆栈信息中也很容易发现，在执行到 MainActivity.clickToSleep 方法时，线程进行了睡眠，最终导致 ANR。

4、耗时或死循环方法
例子如下：

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
    }
   
    fun click(view: View) {
        doSomething()
    }

    private fun doSomething() {
        // 注意这里死循环
        while (true) {
            Log.i("testLog", "doSomething.. 当前线程名称=${Thread.currentThread().name} 线程id=${Thread.currentThread().id}")
        }
    }
}

当我们点击按钮时，会在主线程通过一个死循环不断打印 log，因此 doSomething() 方法我们可以认为是一个耗时方法，点击按钮后，我们左滑或者点击返回键退出 MainActivity（由于主线程正在忙碌中，所以此时是无法退出成功的），等待一段时间，系统将会弹出 ANR 弹窗。
ANR日志如下：

----- pid 13231 at 2022-06-17 14:23:41 -----
Cmd line: com.example.demoproject
...
"main" prio=5 tid=1 Runnable
  | group="main" sCount=0 dsCount=0 flags=0 obj=0x72b20e78 self=0x77fe5a6c00
  | sysTid=13231 nice=-10 cgrp=default sched=0/0 handle=0x77ffb0eed0
  | state=R schedstat=( 31694533124 58819622 723 ) utm=1310 stm=1859 core=5 HZ=100
  | stack=0x7fdc2b7000-0x7fdc2b9000 stackSize=8192KB
  | held mutexes= "mutator lock"(shared held)
  native: #00 pc 00000000004108e8  /apex/com.android.runtime/lib64/libart.so (art::DumpNativeStack(std::__1::basic_ostream>&, int, BacktraceMap*, char const*, art::ArtMethod*, void*, bool)+140)
  native: #01 pc 00000000004f8040  /apex/com.android.runtime/lib64/libart.so (art::Thread::DumpStack(std::__1::basic_ostream>&, bool, BacktraceMap*, bool) const+512)
  native: #02 pc 000000000051297c  /apex/com.android.runtime/lib64/libart.so (art::DumpCheckpoint::Run(art::Thread*)+828)
  native: #03 pc 00000000004f8d4c  /apex/com.android.runtime/lib64/libart.so (art::Thread::RunCheckpointFunction()+176)
  native: #04 pc 00000000003713fc  /apex/com.android.runtime/lib64/libart.so (art::(anonymous namespace)::CheckJNI::ReleaseStringCharsInternal(char const*, _JNIEnv*, _jstring*, void const*, bool, bool)+1356)
  native: #05 pc 00000000001507cc  /system/lib64/libandroid_runtime.so (android::android_util_Log_println_native(_JNIEnv*, _jobject*, int, int, _jstring*, _jstring*)+232)
  at android.util.Log.println_native(Native method)
  at android.util.Log.i(Log.java:176)
  at com.example.demoproject.view.MainActivity.doSomething(MainActivity.kt:52)
  at com.example.demoproject.view.MainActivity.click2(MainActivity.kt:36)
  at java.lang.reflect.Method.invoke(Native method)
  at androidx.appcompat.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:441)
  at android.view.View.performClick(View.java:7259)
  at com.google.android.material.button.MaterialButton.performClick(MaterialButton.java:1194)
  at android.view.View.performClickInternal(View.java:7236)
  at android.view.View.access$3600(View.java:801)
  at android.view.View$PerformClick.run(View.java:27896)
  at android.os.Handler.handleCallback(Handler.java:883)
  at android.os.Handler.dispatchMessage(Handler.java:100)
  at android.os.Looper.loop(Looper.java:214)
  at android.app.ActivityThread.main(ActivityThread.java:7397)
  at java.lang.reflect.Method.invoke(Native method)
  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:935)
...
----- end 16808 -----

发现主线程正处于 Runnable 状态，并不是处于空闲状态，堆栈信息中有一行关键日志：

at com.example.demoproject.view.MainActivity.doSomething(MainActivity.kt:52)

各关键字：am_anr、ANR in、Reason、Blocked、Slepping。

ANR分析总结

ANR类型

一、导出并查看 ANR 日志

二、ANR 日志如何分析

三、分析

你可能感兴趣的:(ANR分析总结)