mmkvWithID Lock Opt

[wangtao19930524]

Through our online monitoring, we have found that there are many "getMMKVWithID" type Janks and ANRs during the app startup phase. The stack is as follows:

libc.so syscall libc.so _ZN5NonPIL20MutexLockWithTimeoutEP24pthread_mutex_internal_tbPK8timespec libmmkv.so _ZN4mmkv10ThreadLock4lockEv (ThreadLock.cpp:49) libmmkv.so _ZN4MMKV10mmkvWithIDERKNSt6__ndk112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEi8MMKVModePS6_SA_ (MMKV_Android.cpp:144) libmmkv.so getMMKVWithID (native-bridge.cpp:277) com.tencent.mmkv.MMKV.getMMKVWithID(MMKV.java:0) com.tencent.mmkv.MMKV.mmkvWithID(MMKV.java:355)

The reason is that there are many mmkv file initialization during the startup phase, and some files are relatively large, resulting in a severe lock time
By locking files with the same name in the MMKV.java and reducing the locking force of the native layer to solve this problem, it has been proven that it has a significant impact on the performance of our app.

[lingol]

Thanks for your contribution.

MMKV already does lazy loading on initialization, starting from v1.3.3. The optimization you make should be of little impact on the ANR.

What exactly is your version when you detect ANR and verify it's fixed?

[wangtao19930524]

I have conducted experimental observations before and found that lazy loading has a negative impact on our scenario. I speculate that lazy loading may cause some MMKV initialization to change from asynchronous execution to synchronous execution on the main thread, which indirectly leads to negative performance

[lingol]

No you aren't getting it. What is your version when you are doing this opt thing?