Android—ANR日志分析

已于 2024-09-27 19:00:34 修改
阅读量327 收藏 10
点赞数 12
文章标签： 开发语言
于 2024-09-27 18:59:03 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_41939525/article/details/141886457
版权
获取ANR日志：
  1. ANR路径：/data/anr
  2. ADB指令：adb bugreport D:\bugrep.zip
ANR日志分析步骤：
  1. “main” prio=：主线程状态
  2. beginning of crash：搜索 crash 相关信息
  3. CPU usage from：搜索 cpu 使用信息
主线程状态：
  1. RUNNABLE：线程正在运行或准备运行。
  2. BLOCKED：线程被阻塞，等待获取一个锁。
  3. WAITING：线程在等待某个条件发生（如等待其他线程的通知）。
  4. TIMED_WAITING：线程在等待某个条件发生，但有时间限制（如使用Thread.sleep()或Object.wait(long timeout)）。
  5. TERMINATED：线程已经完成执行并终止。
  6. NATIVE：线程正在执行本地代码（JNI调用）。

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

案例分析：
5.1 主线程无卡顿，处于正常状态堆栈
“main” prio=5 tid=1 Native
| group=“main” sCount=1 dsCount=0 flags=1 obj=0x74b38080 self=0x7ad9014c00
| sysTid=23081 nice=0 cgrp=default sched=0/0 handle=0x7b5fdc5548
| state=S schedstat=( 284838633 166738594 505 ) utm=21 stm=7 core=1 HZ=100
| stack=0x7fc95da000-0x7fc95dc000 stackSize=8MB
| held mutexes=
kernel: __switch_to+0xb0/0xbc
kernel: SyS_epoll_wait+0x288/0x364
kernel: SyS_epoll_pwait+0xb0/0x124
kernel: cpu_switch_to+0x38c/0x2258
native: #00 pc 000000000007cd8c /system/lib64/libc.so (__epoll_pwait+8)
native: #01 pc 0000000000014d48 /system/lib64/libutils.so (android::Looper::pollInner(int)+148)
native: #02 pc 0000000000014c18 /system/lib64/libutils.so (android::Looper::pollOnce(int, int*, int*, void**)+60)
native: #03 pc 00000000001275f4 /system/lib64/libandroid_runtime.so (android::android_os_MessageQueue_nativePollOnce(_JNIEnv*, _jobject*, long, int)+44)
at android.os.MessageQueue.nativePollOnce(Native method)
at android.os.MessageQueue.next(MessageQueue.java:330)
at android.os.Looper.loop(Looper.java:169)
at android.app.ActivityThread.main(ActivityThread.java:7073)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:536)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:876)

上述主线程堆栈就是一个很正常的空闲堆栈，表明主线程正在等待新的消息。

如果ANR日志里主线程是这样一个状态，那可能有两个原因：

  1. 该ANR是CPU抢占或内存紧张等其他因素引起
  2. 这份ANR日志抓取的时候，主线程已经恢复正常

遇到这种空闲堆栈，可以分析CPU、内存的情况。其次可以关注抓取日志的时间和ANR发生的时间是否相隔过久，时间过久这个堆栈就没有分析意义了。

5.2 主线程执行耗时操作
“main” prio=5 tid=1 Runnable
| group=“main” sCount=0 dsCount=0 flags=0 obj=0x72deb848 self=0x7748c10800
| sysTid=8968 nice=-10 cgrp=default sched=0/0 handle=0x77cfa75ed0
| state=R schedstat=( 24783612979 48520902 756 ) utm=2473 stm=5 core=5 HZ=100
| stack=0x7fce68b000-0x7fce68d000 stackSize=8192KB
| held mutexes= “mutator lock”(shared held)
at com.example.test.MainActivity$onCreate$2.onClick(MainActivity.kt:20)——关键行！！！
at android.view.View.performClick(View.java:7187)
at android.view.View.performClickInternal(View.java:7164)
at android.view.View.access3500 ( V i e w . j a v a : 813 ) a t a n d r o i d . v i e w . V i e w 3500(View.java:813) at android.view.View3500(View.java:813)atandroid.view.ViewPerformClick.run(View.java:27640)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:230)
at android.app.ActivityThread.main(ActivityThread.java:7725)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:526)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1034)

上述日志表明，主线程正处于执行状态，看堆栈信息可知不是处于空闲状态，发生ANR是因为一处click监听函数里执行了耗时操作。

5.3 主线程被锁阻塞
“main” prio=5 tid=1 Blocked
| group=“main” sCount=1 dsCount=0 flags=1 obj=0x72deb848 self=0x7748c10800
| sysTid=22838 nice=-10 cgrp=default sched=0/0 handle=0x77cfa75ed0
| state=S schedstat=( 390366023 28399376 279 ) utm=34 stm=5 core=1 HZ=100
| stack=0x7fce68b000-0x7fce68d000 stackSize=8192KB
| held mutexes=
at com.example.test.MainActivity$onCreate$1.onClick(MainActivity.kt:15)

waiting to lock <0x01aed1da> (a java.lang.Object) held by thread 3 ——————关键行！！！
at android.view.View.performClick(View.java:7187)
at android.view.View.performClickInternal(View.java:7164)
at android.view.View.access3500 ( V i e w . j a v a : 813 ) a t a n d r o i d . v i e w . V i e w 3500(View.java:813) at android.view.View3500(View.java:813)atandroid.view.ViewPerformClick.run(View.java:27640)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:230)
at android.app.ActivityThread.main(ActivityThread.java:7725)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:526)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1034)

…省略N行…

“WQW TEST” prio=5 tid=3 TimeWating
| group=“main” sCount=1 dsCount=0 flags=1 obj=0x12c44230 self=0x772f0ec000
| sysTid=22938 nice=0 cgrp=default sched=0/0 handle=0x77391fbd50
| state=S schedstat=( 274896 0 1 ) utm=0 stm=0 core=1 HZ=100
| stack=0x77390f9000-0x77390fb000 stackSize=1039KB
| held mutexes=
at java.lang.Thread.sleep(Native method)

sleeping on <0x043831a6> (a java.lang.Object)
at java.lang.Thread.sleep(Thread.java:440)
locked <0x043831a6> (a java.lang.Object)
at java.lang.Thread.sleep(Thread.java:356)
at com.example.test.MainActivity$onCreate2 22thread$1.run(MainActivity.kt:22)
locked <0x01aed1da> (a java.lang.Object)————————————————————关键行！！！
at java.lang.Thread.run(Thread.java:919)

这是一个典型的主线程被锁阻塞的例子；

waiting to lock <0x01aed1da> (a java.lang.Object) held by thread 3

其中等待的锁是<0x01aed1da>，这个锁的持有者是线程 3。进一步搜索 “tid=3” 找到线程3， 发现它正在TimeWating。

那么ANR的原因找到了：线程3持有了一把锁，并且自身长时间不释放，主线程等待这把锁发生超时。在线上环境中，常见因锁而ANR的场景是SharePreference写入。

5.4 CPU被抢占

这个日志一般在 bugreport.txt 文件中可以查看。

CPU usage from 0ms to 10625ms later (2020-03-09 14:38:31.633 to 2020-03-09 14:38:42.257):
543% 2045/com.alibaba.android.rimet: 54% user + 89% kernel / faults: 4608 minor 1 major ————关键行！！！
99% 674/android.hardware.camera.provider@2.4-service: 81% user + 18% kernel / faults: 403 minor
24% 32589/com.wang.test: 22% user + 1.4% kernel / faults: 7432 minor 1 major
…省略N行…

如上日志，第二行是其他应用进程，占据CPU高达543%，抢占了大部分CPU资源，因而导致发生ANR。

5.5 内存紧张导致ANR

如果有一份日志，CPU和堆栈都很正常（不贴出来了），仍旧发生ANR，考虑是内存紧张。

从CPU第一行信息可以发现，ANR的时间点是2020-10-31 22:38:58.468—CPU usage from 0ms to 21752ms later (2020-10-31 22:38:58.468 to 2020-10-31 22:39:20.220)

接着去系统日志里搜索am_meminfo， 这个没有搜索到。再次搜索onTrimMemory。

10-31 22:37:19.749 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:37:33.458 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:38:00.153 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:38:58.731 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0
10-31 22:39:02.816 20733 20733 E Runtime : onTrimMemory level:80,pid:com.xxx.xxx:Launcher0

5.6 系统服务超时导致ANR

系统服务超时一般会包含BinderProxy.transactNative关键字，请看如下日志：

"main" prio=5 tid=1 Native
 | group="main" sCount=1 dsCount=0 flags=1 obj=0x727851e8 self=0x78d7060e00
 | sysTid=4894 nice=0 cgrp=default sched=0/0 handle=0x795cc1e9a8
 | state=S schedstat=( 8292806752 1621087524 7167 ) utm=707 stm=122 core=5 HZ=100
 | stack=0x7febb64000-0x7febb66000 stackSize=8MB
 | held mutexes=
 kernel: __switch_to+0x90/0xc4
 kernel: binder_thread_read+0xbd8/0x144c
 kernel: binder_ioctl_write_read.constprop.58+0x20c/0x348
 kernel: binder_ioctl+0x5d4/0x88c
 kernel: do_vfs_ioctl+0xb8/0xb1c
 kernel: SyS_ioctl+0x84/0x98
 kernel: cpu_switch_to+0x34c/0x22c0
 native: #00 pc 000000000007a2ac /system/lib64/libc.so (__ioctl+4)
 native: #01 pc 00000000000276ec /system/lib64/libc.so (ioctl+132)
 native: #02 pc 00000000000557d4 /system/lib64/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+252)
 native: #03 pc 0000000000056494 /system/lib64/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*, int*)+60)
 native: #04 pc 00000000000562d0 /system/lib64/libbinder.so (android::IPCThreadState::transact(int, unsigned int, android::Parcel const&,
 native: #05 pc 000000000004ce1c /system/lib64/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::P
 native: #06 pc 00000000001281c8 /system/lib64/libandroid_runtime.so (???)
 native: #07 pc 0000000000947ed4 /system/framework/arm64/boot-framework.oat (Java_android_os_BinderProxy_transactNative__ILandroid_os_Par
 at android.os.BinderProxy.transactNative(Native method) ————————————————关键行！！！
 at android.os.BinderProxy.transact(Binder.java:804)
 at android.net.IConnectivityManager$Stub$Proxy.getActiveNetworkInfo(IConnectivityManager.java:1204)—关键行！
 at android.net.ConnectivityManager.getActiveNetworkInfo(ConnectivityManager.java:800)
 at com.xiaomi.NetworkUtils.getNetworkInfo(NetworkUtils.java:2)
 at com.xiaomi.frameworkbase.utils.NetworkUtils.getNetWorkType(NetworkUtils.java:1)
 at com.xiaomi.frameworkbase.utils.NetworkUtils.isWifiConnected(NetworkUtils.java:1)

#全家桶
关注
Android ANR日志分析指南，android模拟器中文输入法
m0_64603776的博客
12-29 568
一、 查看events_log 查看mobilelog文件夹下的events_log,从日志中搜索关键字：am_anr，找到出现ANR的时间点、进程PID、ANR类型。 如日志： 07-20 15:36:36.472 1000 1520 1597 I am_anr : [0,1480,com.xxxx.moblie,952680005,Input dispatching timed out (AppWindowToken{da8f666 token=Token{5501f51 ActivityRec
Android ANR日志分析指南
特立独行的博客
06-25 2408
当你的项目越做越复杂，或者你的用户达到某个数量级的时候，你的代码不小心出现细小的问题，你会收到各种各样的bug,其中ANR的问题你一定不会陌生。本文将详细讲解ANR的类型、出现的原因、ANR案例详细分析、经典的案例。
Android ANR日志分析
a546036242的博客
09-23 1601
举个例子，进程A短时间内发送很多Binder 请求给进程B，这种情况下就有可能会导致在短时间内，接收端进程B的 Binder 线程池中的16个Binder线程，都用来响应进程A的Binder请求，也就是我们常说的Binder线程池耗尽的情况，此时进程B无法处理进程A发过来的新的Binder请求。（这种问题一般属于严重三方问题）另外发生ANR的时候，线程并没有暂停掉，有可能等到我们去抓这个进程的trace的时候，这个进程的主线程都恢复正常了，比如经常性出现下面的nativePollOnce状态的堆栈。
Android ANR 日志分析定位
简单记录工作和学习
03-01 1152
/data/anr/ 路径只有 root 权限才能够进行访问，在非 root 权限的情况下需要 adb 命令导出相关的日志文件后筛选查看 ANR 的日志信息
【Android】ANR日志分析
qq_35770839的博客
03-06 1675
很多开发者认为，ANR就是耗时操作导致，全部是app应用层的问题。实际上，线上环境大部分ANR由系统原因导致。
Android 分析anr日志,Android ANR 分析与解决
weixin_35523579的博客
05-26 679
今天解决了一个ANR异常问题，心情愉悦，原来ANR分析解决很简单(可能问题本来比较简单吧~~暂做参考)三个步骤搞定：步骤一：重现ANR 异常对着界面一顿操作...直至弹出anr提示步骤二：拉取anr log文件adb shell //进入shell命令模式cp data/anr/traces.txt sdcard/tr...
Android ANR日志分析总结
wq892373445的博客
05-01 4100
定义 ANR(Application Not Responding) 应用程序无响应。如果你应用程序在UI线程被阻塞太长时间，就会出现ANR，通常出现ANR，系统会弹出一个提示提示框，让用户知道，该程序正在被阻塞，是否继续等待还是关闭。 ANR类型 出现ANR的一般有以下几种类型： 1:KeyDispatchTimeout（常见） input事件在5S内没有处理完成发生了ANR。 logcat日志...
2024年Android最全Android ANR日志分析指南(3)，2024年最新斗鱼直播Android开发二面被刷
2401_84558314的博客
05-13 894
好了，今天的分享就到这里，如果你对在面试中遇到的问题，或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己，对于自己的未来还不够了解不知道给如何规划，可以来看看同行们都是如何突破现状，怎么学习的，来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。这里只是整理出来的部分面试题，后续会持续更新，希望通过这些高级面试题能够降低面试Android岗位的门槛，让更多的Android工程师理解Android系统，掌握Android系统。假如你的CPU是4核，那么上限是400%，以此类推。
【Android】如何分析 ANR 日志
热门推荐
yang553566463的博客
06-17 1万+
应用层导致的ANR（耗时操作）系统层导致的ANR方法一当系统出现 ANR 时，设备会自动将 ANR 日志输出到 目录下，如下所示：对于这些文件，我们直接双击在 Android Studio 上打开即可。方法二执行命令：可以导出设备所有 bug 日志，执行命令后，在指定文件夹内得到一个 zip 文件，将文件解压后打开，文件目录如下所示：其中，设备的 anr 日志会保存在该路径下：，如图：另外，该文件 内也有有 anr 日志的打印，我们可以通过以下关键词搜索该文件的一些异常信息，如：一个 ANR 日志，会包
Android ANR 日志导出及分析
月小水长
04-23 559
adb shelllsexit然后尝试尝试导出，发现权限不足，这是因为需要手机 root。退而求其次，使用bugreport最终在导出一个 zip 压缩文件，解压后 anr 在下述路径中其中的 anr 日志文件没有后缀名，其实是普通文本文件，可以用记事本打开。
干货！ANR日志分析全面解析.docx
08-26
ANR（Application Not Responding）日志分析是 Android 开发者需要掌握的重要技巧之一。ANR 的产生机制可以分为四类：输入事件超时、广播类型超时、服务超时和 ContentProvider 类型超时。ANR 的原因也可以分为两类...
Android ANR日志分析指南，android查看网络请求和响应
m0_66145114的博客
03-04 2351
既然不是CPU负载的原因，那么到底是什么原因呢？ 这时就要看我们的终极大杀器——traces.txt。 二、 traces.txt 日志分析 当APP不响应、响应慢了、或者WatchDog的监视没有得到回应时，系统就会dump出一个traces.txt文件，存放在文件目录:/data/anr/traces.txt，通过traces文件,我们可以拿到线程名、堆栈信息、线程当前状态、binder call等信息。 通过adb命令拿到该文件：adb pull /data/anr/traces.txt trace:
Android ANR日志分析指南，android小游戏开发源码
m0_66144992的博客
01-31 518
5:service binder的连接达到上线无法和和System Server通信 6:系统资源已耗尽（管道、CPU、IO） ANR案例分析过程 我们将一步一步分析ANR,这个过程更加理解如何找到问题、分析问题以及解决问题。 一、 查看events_log 查看mobilelog文件夹下的events_log,从日志中搜索关键字：am_anr，找到出现ANR的时间点、进程PID、ANR类型。 如日志： 07-20 15:36:36.472 1000 1520 1597 I am_anr : [0
网站建设中常见的网站后台开发语言有哪几种，各自优缺点都是什么？
2301_80154636的博客
09-24 1198
总的来说，每种语言都有其特定的优势和局限，选择哪种语言取决于项目需求、团队技能和预期的维护成本等多种因素。理解这些语言的核心特性和适用场景可以帮助开发者做出更明智的选择，从而有效提升项目的成功率和开发效率。这些语言各有其独特的优缺点，适用于不同的开发场景和需求。市场上常见的网站后台开发语言有。
基于asp.net的教师授课系统设计与实现.docx
最新发布
09-27
基于asp.net的教师授课系统设计与实现.docx
基于Springboot和Vue的精简博客系统源码 精简博客系统代码（程序，中文注释）
09-27
精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统-精简博客系统 1、资源说明：精简博客系统源码，本资源内项目代码都经过测试运行成功，功能ok的情况下才上传的。 2、适用人群：计算机相关专业(如计算计、信息安全、大数据、人工智能、通信、物联网、自动化、电子信息等)在校学生、专业老师或者企业员工等学习者，作为参考资料，进行参考学习使用。 3、资源用途：本资源具有较高的学习借鉴价值，可以作为“参考资料”，注意不是“定制需求”，代码只能作为学习参考，不能完全复制照搬。需要有一定的基础，能够看懂代码，能够自行调试代码，能够自行添加功能修改代码。 4. 最新计算机软件毕业设计选题大全(文章底部有博主联系方式): https://blog.csdn.net/2301_79206800/article/details/135931154 技术栈、环境、工具、软件： ① 系统环境:Windows ② 开发语言：Java ③ 框架：SpringBoot ④ 架构:B/S、MVC ⑤ 开发环境:IDE
基于asp.net的客户资源管理系统设计与实现.docx
09-27
基于asp.net的客户资源管理系统设计与实现.docx
嵌入式开发入门指南：硬件基础与软件实践
09-27
嵌入式系统是集成了计算机硬件和软件的专用计算系统，广泛应用于各种设备和行业，如家电、汽车、医疗设备和工业自动化等。嵌入式开发涉及
基于若依3.8.7版本的Java+Vue全栈框架设计源码
09-27
该项目是一款基于若依3.8.7版本的Java+Vue全栈框架设计源码，包含609个文件，涵盖259个Java源文件、95个Vue组件、87个SVG文件、76个JavaScript文件、28个XML配置文件、13个Vue模板文件、9个SCSS样式文件、7个批处理文件、5个YAML配置文件、4个PNG图片文件。该源码集成了lombok、knife4j、mybatis-plus等实用库，并需自行掌握具体实现细节。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值