ANR问题分析

68 阅读 0 评论 45 点赞

我是靠谱客的博主高兴奇迹，最近开发中收集的这篇文章主要介绍ANR问题分析，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

线程关键字解读

- main：main标识是主线程，如果是线程，那么命名成Thread-X的格式，x表示线程，id逐步递增；
- prio：线程优先级,默认是5；
- tid：tid不是线程的id是线程唯一标识ID；
- Runnable：线程状态；
- 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核的序号。

线程状态对应的定义：
libcore/ojluni/src/main/java/java/lang/Thread.java文件中的State枚举类；
art/runtime/thread_state.h文件中的ThreadState枚举类；

java中定义的状态 c中定义的状态说明
TERMINATED ZOMBIE 线程死亡终止运行
RUNNABLE RUNNING/RUNNABLE 线程可运行或正在运行
TIMED_WAITING TIMED_WAIT 执行了带有超时参数的wait，sleep，join函数
BLOCKED MONITOR 线程阻塞，等待获取对象锁
WAITING WAIT 执行了无超时参数的wait函数
NEW INITIALZING 新建，正在初始化，为其分配资源
NEW STARTING 新建，正在启动
RUNNABLE NATIVE 正在执行JNI本地函数
WAITING VMWAIT 正在等待VM资源
RUNNABLE SUSPENDED 线程暂停，通常是由于GC或者debug暂停
UNKNOW 未知状态

java中定义的状态	c中定义的状态	说明
TERMINATED	ZOMBIE	线程死亡终止运行
RUNNABLE	RUNNING/RUNNABLE	线程可运行或正在运行
TIMED_WAITING	TIMED_WAIT	执行了带有超时参数的wait，sleep，join函数
BLOCKED	MONITOR	线程阻塞，等待获取对象锁
WAITING	WAIT	执行了无超时参数的wait函数
NEW	INITIALZING	新建，正在初始化，为其分配资源
NEW	STARTING	新建，正在启动
RUNNABLE	NATIVE	正在执行JNI本地函数
WAITING	VMWAIT	正在等待VM资源
RUNNABLE	SUSPENDED	线程暂停，通常是由于GC或者debug暂停
	UNKNOW	未知状态

ANR问题

查看ANR日志，分析主线程日志

启动搜索页面时，主线程等待ContentResolver回调超时导致的anr

"main" prio=5 tid=1 TimedWaiting
| group="main" sCount=1 dsCount=0 flags=1 obj=0x747053a8 self=0xb400007719fcac00
| sysTid=3075 nice=-10 cgrp=default sched=1073741825/2 handle=0x771b61c4f8
| state=S schedstat=( 21664594948 3272425081 21985 ) utm=1820 stm=345 core=3 HZ=100
| stack=0x7fdc288000-0x7fdc28a000 stackSize=8192KB
| held mutexes=
at java.lang.Object.wait(Native method)
- waiting on <0x0aff4f3f> (a android.content.ContentResolver$StringResultListener)
at java.lang.Object.wait(Object.java:442)
at android.content.ContentResolver$ResultListener.waitForResult(ContentResolver.java:990)
- locked <0x0aff4f3f> (a android.content.ContentResolver$StringResultListener)

main线程 TimedWaiting状态，waiting on an unknown object，wait信息unknow，无法继续分析

"main" prio=5 tid=1 TimedWaiting
| group="main" sCount=1 dsCount=0 flags=1 obj=0x74d143a8 self=0xb400007de93a4c00
| sysTid=24688 nice=-10 cgrp=default sched=1073741825/2 handle=0x7dea9f54f8
| state=S schedstat=( 6341907401 2039832562 4718 ) utm=498 stm=135 core=6 HZ=100
| stack=0x7fed42e000-0x7fed430000 stackSize=8192KB
| held mutexes=
at sun.misc.Unsafe.park(Native method)
- waiting on an unknown object
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:230)
at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:447)
at java.util.concurrent.FutureTask.get(FutureTask.java:205)
at com.huawei.hvi.foundation.proxy.InvocationPolicyInMain.invokeMethodReturn(InvocationPolicyInMain.java:134)
at com.huawei.hvi.foundation.proxy.InvocationPolicyInSingle.invokePolicyInSingle(InvocationPolicyInSingle.java:118)
at com.huawei.hvi.foundation.proxy.InvocationPolicyInSingle.invokeByPolicy(InvocationPolicyInSingle.java:77)
at com.huawei.hvi.foundation.proxy.InvocationPolicy.invoke(InvocationPolicy.java:135)
at java.lang.reflect.Proxy.invoke(Proxy.java:1006)
at com.huawei.himovie.components.stats.api.maintenance.intf.IMonitor.getShowTime(IMonitor.java:-2)

概念

ANR（Application Not Responding）：即应用无响应。主线程在超时时间内没有做完特定的事情，就会发生ANR；

发生场景分类

KeyDispatch Timeout:主要类型按键或按键触摸，在规定时间内5s没有处理完成所做的操作，
- log表现
```
Reason :inpupt dispatching timed out xxxx
```
Service Timeout : ServiceTimed-bind,cread,start,unbind等在主线程处理耗时，前台服务在20s内，后天服务在200s内没有处理完所作的操作，
- log表现
```
Timeout executing service:/executing service XXX
```
Broadcast Receiver: BroadcastReceiver onReceiver处理事务时前台广播在10s，后台广播在60s内没有完成所作的操作
- Log表现
```
Timeout of broadcast XXX/Receiver during timeout:XXX/Broadcast of XXX
```
ContentProvider Timedout : ProcessContentProviderPublishTimedLocked-ContentProvider publish在10s内没有做完所作的操作，
- Log表现
```
timeout publishing content providers
```


以上时间的定义如下：
ActivityTaskManagerService.java
*// How long we wait until we timeout on key dispatching.*
**public** static final int KEY_DISPATCHING_TIMEOUT_MS = 5 * 1000;
*// How long we wait until we timeout on key dispatching during instrumentation.*
static final int INSTRUMENTATION_KEY_DISPATCHING_TIMEOUT_MS = 60 * 1000;
ActivityManagerService.java
*// How long we allow a receiver to run before giving up on it.*
static final int BROADCAST_FG_TIMEOUT = 10*1000;
static final int BROADCAST_BG_TIMEOUT = 60*1000;
*// How long we wait for an attached process to publish its content providers*
*// before we decide it must be hung.*
static final int CONTENT_PROVIDER_PUBLISH_TIMEOUT = 10*1000;
ActiveServices.java
*// How long we wait for a service to finish executing.*
static final int SERVICE_TIMEOUT = 20*1000;
*// How long we wait for a service to finish executing.*
static final int SERVICE_BACKGROUND_TIMEOUT = SERVICE_TIMEOUT * 10;

进程角度分类

问题出在当前进程：

主线程本身耗时，或则主线程的消息队列存在耗时操作；
主线程被本进程的其他子线程所blocked；

2.问题出在远端进程：

一般是binder call 或者socker等通信方式。

发生原因分类

造成ANR的原因有很多，无论是在Activity或者BroadcastReceiver还是在Service，我们看到都是在主线程中操作引起的ANR，因此我们应该避免在主线程做太多耗时的操作

主线程频繁进行IO操作，如读写文件或者数据库，复杂的layout、庞大的for循环等；
硬件操作如进行调用照相机或者录音等操作；
多线程操作的死锁，导致主线程等待超时，如被子线程同步锁block、主线程被Binder对端block；
主线程操作调用join()方法、sleep()方法或者wait()方法；
system server中发生WatchDog ANR；
service binder的数量达到上限；
lowmemorykill；
CPU超负荷工作；

内存

内存不足

DALVIK THREADS:
"main"prio=5 tid=3 VMWAIT
|group="main" sCount=1 dsCount=0 s=N obj=0x40026240self=0xbda8
| sysTid=1815 nice=0 sched=0/0 cgrp=unknownhandle=-1344001376
atdalvik.system.VMRuntime.trackExternalAllocation(NativeMethod) ---VMRuntime.trackExternalAllocation 内存不足
atandroid.graphics.Bitmap.nativeCreate(Native Method)
atandroid.graphics.Bitmap.createBitmap(Bitmap.java:468)
atandroid.view.View.buildDrawingCache(View.java:6324)
atandroid.view.View.getDrawingCache(View.java:6178)
atandroid.view.ViewGroup.drawChild(ViewGroup.java:1541)

数据库读写

主线程耗时操作，数据库读写

 kernel: (couldn't read /proc/self/task/11003/stack)
**native**: #00 pc 000492a4 /system/lib/libc.so (nanosleep+12)
**native**: #01 pc 0002dc21 /system/lib/libc.so (usleep+52)
**native**: #02 pc 00009cab /system/lib/libsqlite.so (???)
**native**: #03 pc 00011119 /system/lib/libsqlite.so (???)
**native**: #04 pc 00016455 /system/lib/libsqlite.so (???)
**native**: #16 pc 0000fa29 /system/lib/libsqlite.so (???)
**native**: #17 pc 0000fad7 /system/lib/libsqlite.so (sqlite3_prepare16_v2+14)
**native**: #18 pc 0007f671 /system/lib/libandroid_runtime.so (???)
**native**: #19 pc 002b4721 /system/framework/arm/boot-framework.oat (Java_android_database_sqlite_SQLiteConnection_nativePrepareStatement__JLjava_lang_String_2+116)
at android.database.sqlite.SQLiteConnection.setWalModeFromConfiguration(SQLiteConnection.java:294)
at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:215)
at android.database.sqlite.SQLiteConnection.open(SQLiteConnection.java:193)
at android.database.sqlite.SQLiteConnectionPool.openConnectionLocked(SQLiteConnectionPool.java:463)
at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:185)
at android.database.sqlite.SQLiteConnectionPool.open(SQLiteConnectionPool.java:177)
at android.database.sqlite.SQLiteDatabase.openInner(SQLiteDatabase.java:808)
locked <0x0db193bf> (a java.lang.Object)
at android.database.sqlite.SQLiteDatabase.open(SQLiteDatabase.java:793)
at android.database.sqlite.SQLiteDatabase.openDatabase(SQLiteDatabase.java:696)
at android.app.ContextImpl.openOrCreateDatabase(ContextImpl.java:690)
at android.content.ContextWrapper.openOrCreateDatabase(ContextWrapper.java:299)
at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:223)
at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:163)
locked <0x045a4a8c> (a com.xxxx.video.common.data.DataBaseHelper)
at com.xxxx.video.common.data.DataBaseORM.<init>(DataBaseORM.java:46)
at com.xxxx.video.common.data.DataBaseORM.getInstance(DataBaseORM.java:53)
locked <0x017095d5> (a java.lang.Class<com.xxxx.video.common.data.DataBaseORM>)

非应用类型ANR常见原因：

等锁

线程状态为“Blocked”，通过关键字“held by”进一步确认哪个线程拿住了锁，如有死锁检查code逻辑进行解锁；线程状态为“Waiting”，表示当前线程需要另外一个线程来notify()，需要根据callstack结合code来做分析，以找到是另外的某个线程拿住了锁。如果很多线程在等同一把锁，可能产生资源竞争问题，导致某些线程可能拿不到锁。

#### 主线程被**lock**，等待超时


DALVIK THREADS:
"main" prio=5 tid=3 TIMED_WAIT
| group="main" sCount=1 dsCount=0 s=0 obj=0x400143a8
| sysTid=691 nice=0 sched=0/0 handle=-1091117924
at java.lang.Object.wait(Native Method)
- waiting on <0x1cd570> (a android.os.MessageQueue)
at java.lang.Object.wait(Object.java:195)
at android.os.MessageQueue.next(MessageQueue.java:144)
at android.os.Looper.loop(Looper.java:110)
at android.app.ActivityThread.main(ActivityThread.java:3742)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:739)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:497)
at dalvik.system.NativeStart.main(Native Method)
"Binder Thread #3" prio=5 tid=15 NATIVE
| group="main" sCount=1 dsCount=0 s=0 obj=0x434e7758
| sysTid=734 nice=0 sched=0/0 handle=1733632
at dalvik.system.NativeStart.run(Native Method)
"Binder Thread #2" prio=5 tid=13 NATIVE
| group="main" sCount=1 dsCount=0 s=0 obj=0x1cd570
| sysTid=696 nice=0 sched=0/0 handle=1369840
at dalvik.system.NativeStart.run(Native Method)
"Binder Thread #1" prio=5 tid=11 NATIVE
| group="main" sCount=1 dsCount=0 s=0 obj=0x433aca10
| sysTid=695 nice=0 sched=0/0 handle=1367448
at dalvik.system.NativeStart.run(Native Method)
```

SurfaceFlinger卡住

SF hang Time > 40s（Service.sf.status值），sf hang，直接在”SYS_ANDROID_LOG”搜索”I watchdog”，看是否有“surfaceflinger hang”关键字。如果有，请进一步确认main_log里有"SF-WD"相关log打印，或者与SWT相关的thread block在android.view.SurfaceControl.XXXX

SF hang Time超过40s，会发生因为sf hang引起的SWT。
确认问题时间点：
SYS_ANDROID_EVENT_LOG：
01-04 12:26:05.982
780
1160 I watchdog: surfaceflinger
hang.
SYS_ANDROID_LOG：
01-04 12:26:05.948 780 1160 V Watchdog: **SF hang Time **4618501-04 12:26:05.949 780 1160 E Watchdog: **SWT happen **

Native方法执行时间过长

线程状态为”Native”，根据native方法找到对应模块的owner，进一步确认该native方法为何执行时间过长，例如是否等待硬件返回或者硬件本身存在问题等。

1.确认问题时间点：
02-12 17:26:02.574534
1159
3442 E Watchdog: **SWT happen **Blocked in handler on ui thread (android.ui)
2.查找对应时间段内trace log：
从system_server blocked的thread入手分析，此题是android.ui
"android.ui" prio=5 tid=13 Native
| group="main" sCount=1 dsCount=0 flags=1 obj=0x15995758 self=0x799c9ec000
| sysTid=1287 nice=-2 cgrp=default sched=0/0 handle=0x797dc384f0
| state=S schedstat=( 183148434550 114009689792 565633 ) utm=11764 stm=6550 core=5 HZ=100
| stack=0x797db35000-0x797db37000 stackSize=1041KB
| held mutexes=
kernel: __switch_to+0xc0/0xcc
kernel: futex_wait_queue_me+0xc4/0x12c
kernel: futex_wait+0x14c/0x334
kernel: do_futex+0xf8/0x1588
kernel: SyS_futex+0x13c/0x194
kernel: __sys_trace_return+0x0/0x4
native: #00 pc 000000000001ee2c
/system/lib64/libc.so (syscall+28)
native: #01 pc 000000000002212c
/system/lib64/libc.so (__futex_wait_ex(void volatile*, bool, int, bool, timespec const*)+140)
native: #02 pc 000000000008586c
/system/lib64/libc.so (NonPI::MutexLockWithTimeout(pthread_mutex_internal_t*, bool, timespec const*)+220)
native: #03 pc 00000000000205a8
/system/lib64/libsensorservice.so (android::SensorService::populateActiveConnections(android::SortedVector<android::sp<android::SensorService::SensorEventConnection>>*)+56)
native: #04 pc 00000000000204d8
/system/lib64/libsensorservice.so (android::SensorService::setSensorAccess(unsigned int, bool)+88)
native: #05 pc 0000000000025fec
/system/lib64/libsensorservice.so (android::SensorService::UidPolicy::onUidIdle(unsigned int, bool)+140)
native: #06 pc 00000000000601f0
/system/lib64/libbinder.so (android::BnUidObserver::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+160)
native: #07 pc 00000000000509b0
/system/lib64/libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+136)
native: #08 pc 0000000000136340
/system/lib64/libandroid_runtime.so (android_os_BinderProxy_transact(_JNIEnv*, _jobject*, int, _jobject*, _jobject*, int)+152)
at android.os.BinderProxy.transactNative(Native method)
at android.os.BinderProxy.transact(Binder.java:1135)
at android.app.IUidObserver$Stub$Proxy.onUidIdle(IUidObserver.java:167)
at com.android.server.am.ActivityManagerService.dispatchUidsChangedForObserver(ActivityManagerService.java:5850)
at com.android.server.am.ActivityManagerService.dispatchUidsChanged(ActivityManagerService.java:5796)
at com.android.server.am.ActivityManagerService$UiHandler.handleMessage(ActivityManagerService.java:2425)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:226)
at android.os.HandlerThread.run(HandlerThread.java:65)
at com.android.server.ServiceThread.run(ServiceThread.java:44)
at com.android.server.UiThread.run(UiThread.java:43)
表示停在libsensorservice.so 这边执行populateActiveConnections时等锁超时：MutexLockWithTimeout

Binder Server卡住

线程状态为“Native”，且含有如下callstack：IPCThreadState::waitForResponse–>IPCThreadState::talkWithDriver，表示卡在binder对端，请对端相关的owner帮忙解决。

binder数据量过大

07-21 04:43:21.573 1000 1488 12756 E Binder : Unreasonably large binder reply buffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling 1 size 388568 (data: 1, 32, 7274595)
07-21 04:43:21.573 1000 1488 12756 E Binder : android.util.Log$TerribleFailure: Unreasonably large binder reply buffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling 1 size 388568 (data: 1, 32, 7274595)
07-21 04:43:21.607 1000 1488 2951 E Binder : Unreasonably large binder reply buffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling 1 size 211848 (data: 1, 23, 7274595)
07-21 04:43:21.607 1000 1488 2951 E Binder : android.util.Log$TerribleFailure: Unreasonably large binder reply buffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling 1 size 211848 (data: 1, 23, 7274595)
07-21 04:43:21.662 1000 1488 6258 E Binder : Unreasonably large binder reply buffer: on android.content.pm.BaseParceledListSlice$1@770c74f calling 1 size 259300 (data: 1, 33, 7274595)

binder通信失败

07-21 06:04:35.580 <6>[32837.690321] binder: 1698:2362 transaction failed 29189/-3, size 100-0 line 3042
07-21 06:04:35.594 <6>[32837.704042] binder: 1765:4071 transaction failed 29189/-3, size 76-0 line 3042
07-21 06:04:35.899 <6>[32838.009132] binder: 1765:4067 transaction failed 29189/-3, size 224-8 line 3042
07-21 06:04:36.018 <6>[32838.128903] binder: 1765:2397 transaction failed 29189/-22, size 348-0 line 2916

binder线程池耗尽

11-23 19:29:57.905 3505 9248 E IPCThreadState: binder thread pool (15 threads) starved **for** 1070 ms

Zygote fork进程时卡住

线程状态为”Native”，确认callstack中有”Process.zygoteSendArgsAndGetResult”，对于Zygote fork进程时卡住的问题，一般是由于底层memory问题引起的，请检查是否有memory不足或者memory leak的问题

缺陷分析

----滚动截图无响应

5.24日分析："从hilogs分析滚动截屏耗时操作
05-23 22:51:28.182
6149
6166 I MultiScreenSho: jit_compiled:[OK] huawei.hiview.HiTraceHandler android.common.HwFrameworkFactory.getHiTraceHandler() @ /system/framework/framework.jar
05-23 22:51:28.182
6149
6149 I HwScreenShot: BigDataReport:reportMultiScreenShotStart, packageName:com.ss.android.ugc.aweme.lite
05-23 22:51:28.183
6149
6149 W BlockMonitor: Package name: com.huawei.HwMultiScreenShot
05-23 22:51:28.183
6149
6149 W BlockMonitor: The Message{ what=1 target=com.huawei.HwMultiScreenShot.u } took 7746ms.
05-23 22:51:28.183
6149
6166 I MultiScreenSho: jit_compiled:[OK] com.huawei.xlayout.IHwXlayout huawei.android.common.HwFrameworkFactoryImpl.getHwXlayout() @ /system/framework/hwEmui.jar
05-23 22:51:28.184
6149
6149 W BlockMonitor: Message { what=1 target=com.huawei.HwMultiScreenShot.u } took 7746 ms, before dispatch event, event seq = 308798
05-23 22:51:28.178
6308
6335 I 01100/AbilityShell: AbilityShellProviderDelegate::onCreate registerDataAbility
05-23 22:51:28.184
6149
6149 I HwScreenShot: TouchToStopRegion:touch left stop view, stop scroll.
05-23 22:51:25.577
1248
6289 I am_anr
: [0,6149,com.huawei.HwMultiScreenShot,-1329054139,Input dispatching timed out (779b1d4 TouchToStoptrue (server) is not responding. Waited 5001ms for MotionEvent(deviceId=4, source=0x00001002, displayId=0, action=MOVE, actionButton=0x00000000, flags=0x00000000, metaState=0x00000000, buttonState=0x00000000, classification=NONE, edgeFlags=0x00000000, xPrecision=8.0, yPrecision=8.0, xCursorPosition=nan, yCursorPosition=nan, pointers=[0: (402.1, 1257.2)]), policyFlags=0x66000000)] 05-23 22:51:25.590
1671
1671 I auditd
: type=1400 audit(0.0:2733350): avc: denied { read } for pid=1671 comm="event_logger" name="ambient" dev="sysfs" ino=51180 scontext=u:r:logserver:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0"

----腾讯视频无响应

5.24日分析："从dropbox日志和hilog日志分析,腾讯视频长时间在后台被管控了,再次进入腾讯视频界面触摸焦点时候报出ANR；正常现象
05-22 23:46:10.240
1245
2162 I ActivityManager: Killing 15468:com.tencent.qqlive/u0a179 (adj 0): user request after error"

----必剪应用无响应

5.24日分析："从dropbox分析持锁，无对端解锁；hilogs分析ActivityManager: Killing 8198:com.bilibili.studio/u0a251 (adj 200): user request after error;Log中没有出现第一次进入App Statu U0打印；初步分析无剪应用在后台停留时间长被管控了，再次使用触摸焦点时候出现ANR;正常现象
"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 flags=1 obj=0x73c6c3a8 self=0xb400007f64469c00
| sysTid=8198 nice=-10 cgrp=vip sched=1073741825/2 handle=0x7f65afd4f8
| state=S schedstat=( 80240501348 6833782282 119768 ) utm=5411 stm=2612 core=5 HZ=100
| stack=0x7fed5bf000-0x7fed5c1000 stackSize=8192KB
| held mutexes= - locked <0x0ebf7bdd> (a com.bilibili.asrb2.model.d)
at com.bilibili.asrb2.AsrEngine$a.b(BL:2)
at com.bilibili.studio.module.recognize.RecognizeProcessor$a.a(BL:5)
at com.bilibili.studio.module.caption.operation.CaptionPageOperation.a(BL:27)
at com.bilibili.studio.module.caption.ui.CaptionRecognitionFragment$onClickExit$1.invoke(BL:4)
at com.bilibili.studio.module.caption.ui.CaptionRecognitionFragment$onClickExit$1.invoke(BL:1)
at com.bilibili.studio.module.caption.ui.CaptionRecognitionFragment$CloseDialog$show$2.invoke(BL:4)
at com.bilibili.studio.module.caption.ui.CaptionRecognitionFragment$CloseDialog$show$2.invoke(BL:1)
at com.bilibili.widgets.dialog.BDialogHelper$d.onClick(BL:1)
at android.view.View.performClick(View.java:7640)
at android.view.View.performClickInternal(View.java:7614)
at android.view.View.access$3700(View.java:847)
at android.view.View$PerformClick.run(View.java:29289)
at android.os.Handler.handleCallback(Handler.java:955)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:228)
at android.app.ActivityThread.main(ActivityThread.java:9105)
at java.lang.reflect.Method.invoke(Native method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:614)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1129)"

----指纹解锁无响应

#指纹解锁时发生冻屏导致systemUI无响应
场景：用户指纹解锁
现象：发生冻屏，点击屏幕无反应
根因：指纹认证模块发生死锁
分析过程：
1. 查看dropbox下的ANR日志可以看到。解锁时systemUI与fingerprint进行binder通信，并且binder阻塞了6s。
2. 查看具体阻塞的binder线程。
3. 看到持锁等待，怀疑死锁。
4. 经过排查发现死锁发生在底层调用fingerprintdaemon方法上。与上层认证时调用updategroupactive方法
5. 取消显示加锁，问题解决。

最后

以上就是高兴奇迹为你收集整理的ANR问题分析的全部内容，希望文章能够帮你解决ANR问题分析所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。

本文分类：# 模块知识点
浏览次数：68 次浏览
发布日期：2023-09-30 13:35:30
本文链接：https://www.kaopuke.com/article/k-p-k_14_uzogfx_14__7_k2.html

ANR问题分析

概述

线程关键字解读

ANR问题

概念

发生场景分类

进程角度分类

发生原因分类

内存

内存不足

数据库读写

主线程耗时操作，数据库读写

非应用类型ANR常见原因：

等锁

SurfaceFlinger卡住

Native方法执行时间过长

Binder Server卡住

binder数据量过大

binder通信失败

binder线程池耗尽

Zygote fork进程时卡住

缺陷分析

----滚动截图无响应

----腾讯视频无响应

----必剪应用无响应

----指纹解锁无响应

最后

评论列表共有 0 条评论

发表评论取消回复

ANR问题分析

概述

线程关键字解读

ANR问题

概念

发生场景分类

进程角度分类

发生原因分类

内存

内存不足

数据库读写

主线程耗时操作，数据库读写

非应用类型ANR常见原因：

等锁

SurfaceFlinger卡住

Native方法执行时间过长

Binder Server卡住

binder数据量过大

binder通信失败

binder线程池耗尽

Zygote fork进程时卡住

缺陷分析

----滚动截图无响应

----腾讯视频无响应

----必剪应用无响应

----指纹解锁无响应

最后

相关文章

评论列表共有 0 条评论

发表评论 取消回复

发表评论取消回复