学习笔记:这里只是一些简单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
。