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