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中定义的状态说明
TERMINATEDZOMBIE线程死亡终止运行
RUNNABLERUNNING/RUNNABLE线程可运行或正在运行
TIMED_WAITINGTIMED_WAIT执行了带有超时参数的wait,sleep,join函数
BLOCKEDMONITOR线程阻塞,等待获取对象锁
WAITINGWAIT执行了无超时参数的wait函数
NEWINITIALZING新建,正在初始化,为其分配资源
NEWSTARTING新建,正在启动
RUNNABLENATIVE正在执行JNI本地函数
WAITINGVMWAIT正在等待VM资源
RUNNABLESUSPENDED线程暂停,通常是由于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;

进程角度分类

  1. 问题出在当前进程:
  • 主线程本身耗时,或则主线程的消息队列存在耗时操作;
  • 主线程被本进程的其他子线程所blocked;

2.问题出在远端进程:

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

发生原因分类

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

  1. 主线程频繁进行IO操作,如读写文件或者数据库,复杂的layout、庞大的for循环等;
  2. 硬件操作如进行调用照相机或者录音等操作;
  3. 多线程操作的死锁,导致主线程等待超时,如被子线程同步锁block、主线程被Binder对端block;
  4. 主线程操作调用join()方法、sleep()方法或者wait()方法;
  5. system server中发生WatchDog ANR;
  6. service binder的数量达到上限;
  7. lowmemorykill;
  8. 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. 取消显示加锁,问题解决。
  • 1
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值