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<char, std::__1::char_traits<char> >&, 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<char, std::__1::char_traits<char> >&, 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<char, std::__1::char_traits<char> >&, bool)+280) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #05 pc 00000000006fc844  /apex/com.android.art/lib64/libart.so (art::ThreadList::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+292) (BuildId: 56e704c544e6c624201be2ab4933e853)
  native: #06 pc 00000000006d5914  /apex/com.android.art/lib64/libart.so (art::Runtime::DumpForSigQuit(std::__1::basic_ostream<char, std::__1::char_traits<char> >&)+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<char, std::__1::char_traits<char>>&, 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<char, std::__1::char_traits<char>>&, 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 日志如何分析

三、分析

热门文章

最新文章

相关电子书

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

ANR分析总结

ANR类型

一、导出并查看 ANR 日志

二、ANR 日志如何分析

三、分析

热门文章

最新文章

相关电子书