MMKV clear ANR

[buyiyun]

"main" prio=5 tid=1 Native
| group="main" sCount=1 dsCount=0 obj=0x74f594b8 self=0xb7fc4ff8
| sysTid=9314 nice=0 cgrp=default sched=0/0 handle=0xb6fd6b34
| state=S schedstat=( 0 0 0 ) utm=38 stm=23 core=2 HZ=100
| stack=0xbe04b000-0xbe04d000 stackSize=8MB
| held mutexes=
#00 pc 0000000000016a18 /system/lib/libc.so (syscall+28)
#1 pc 0000000000042261 /system/lib/libc.so (_ZL33__pthread_mutex_lock_with_timeoutP24pthread_mutex_internal_tPK8timespeci+328)
#2 pc 0000000000042415 /system/lib/libc.so (pthread_mutex_lock+26)
#3 pc 000000000000b9e9 /data/app/com.vstatus.premium-1/lib/arm/libmmkv.so (???)
#4 pc 0000000000005315 /data/app/com.vstatus.premium-1/lib/arm/libmmkv.so (???)
#5 pc 0000000000002683 /data/app/com.vstatus.premium-1/lib/arm/libmmkv.so (???)
#6 pc 0000000000ae4a7b /data/app/com.vstatus.premium-1/oat/arm/base.odex (Java_com_tencent_mmkv_MMKV_sync__Z+78)
at com.tencent.mmkv.MMKV.sync (Native method)
at com.tencent.mmkv.MMKV.apply (631)
at o.akv.apply (133)
at o.ctd.ˊ (85)
at com.snaptube.account.manager.UserManagerImpl.ʻ (119)

Crash on this code
SharedPreferences pref = DaggerService.<BaseAppDependencies>get(context.getApplicationContext()) .preferencesProvider() .getSharedPreferences(PREF_NAME); // get mmkv if (pref.getInt(KEY_VERSION, -1) != PREF_VERSION) { pref.edit().clear().apply(); // call mmkv clean }

[lingol]

All stacks including other processes’ call stacks is needed to further investigate this ANR issue. Logs of mmkv/logcat will be very helpful.

[lingol]

Also, please provide de-symbolized native stacks.

[buyiyun]

screencapture-play-google-apps-publish-2019-09-16-16_22_39.pdf

screencapture-play-google-apps-publish-2019-09-16-16_23_55.pdf

We found two examples of Crash, where I shared the stack information for all threads with you, providing image format and PDF format. @lingol

[lingol]

I don't know which crash report platform did you use, but I'm sure there's a way to symbolized native call stacks. Please provide them.

It's impossible to investigate anything with these stacks, ok?

...
#3 pc 000000000000b9e9 /data/app/com.vstatus.premium-1/lib/arm/libmmkv.so (???)
#4 pc 0000000000005315 /data/app/com.vstatus.premium-1/lib/arm/libmmkv.so (???)
#5 pc 0000000000002683 /data/app/com.vstatus.premium-1/lib/arm/libmmkv.so (???)
...

https://developer.android.com/ndk/guides/ndk-stack.html

[samlu]

The problem may be caused by Application.onCreate() does too many tasks. As to our case, we call MMKV.initialize() on the first use and don't see such ANRs on our vitals console.

The ANR may also be caused by Thread 11 which is performing a disk I/O. Trying to offload some tasks from Application.onCreate() is definitely helpful.

FYI.

[lingol]

The problem may be caused by Application.onCreate() does too many tasks. As to our case, we call MMKV.initialize() on the first use and don't see such ANRs on our vitals console.

The ANR may also be caused by Thread 11 which is performing a disk I/O. Trying to offload some tasks from Application.onCreate() is definitely helpful.

FYI.

Thanks. That's good to know. @buyiyun You might take a look at this tip.

[buyiyun]

Thanks you @samlu and @lingol , I will check for this .