search

Tencent / MMKV

An efficient, small mobile key-value storage framework developed by WeChat. Works on Android, iOS, macOS, Windows, and POSIX.
Other
17.39k stars 1.91k forks source link

mmkvWithID Lock Opt #1384

Closed wangtao19930524 closed 6 days ago

wangtao19930524 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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