LeakCanary получил обратный вызов Fragment # onDestroy (), а Fragment # mFragmentManager имеет значение null - PullRequest
Новая
       85

LeakCanary получил обратный вызов Fragment # onDestroy (), а Fragment # mFragmentManager имеет значение null

2 голосов
/ 05 августа 2020

Я пытаюсь исправить утечку памяти с помощью LeakCanary и, честно говоря, я не могу понять трассировку стека, которая мне показывала. Я использую опцию разбиения по страницам firebase и останавливаю прослушивание методом onDestroy. Я также не передавал адаптеру никаких действий или контекста, поэтому я уверен, что в этом нет проблем. Ниже приведены журналы из LeakCanary. 

    HEAP ANALYSIS RESULT
    ====================================
    1 APPLICATION LEAKS
    
    References underlined with "~~~" are likely causes.
    Learn more at https://squ.re/leaks.
    
    31417285 bytes retained by leaking objects
    Signature: 31c372d2f2d3d219e828763d8f853ceca5851b
    ┬───
    │ GC Root: System class
    │
    ├─ leakcanary.internal.InternalLeakCanary class
    │    Leaking: NO (HomeBuyersActivity↓ is not leaking and a class is never leaking)
    │    ↓ static InternalLeakCanary.resumedActivity
    ├─ com.dreamakers.coonna.Activity.HomeBuyersActivity instance
    │    Leaking: NO (Activity#mDestroyed is false)
    │    ↓ HomeBuyersActivity.mLifecycleRegistry
    │                         ~~~~~~~~~~~~~~~~~~
    ├─ androidx.lifecycle.LifecycleRegistry instance
    │    Leaking: UNKNOWN
    │    ↓ LifecycleRegistry.mObserverMap
    │                        ~~~~~~~~~~~~
    ├─ androidx.arch.core.internal.FastSafeIterableMap instance
    │    Leaking: UNKNOWN
    │    ↓ FastSafeIterableMap.mEnd
    │                          ~~~~
    ├─ androidx.arch.core.internal.SafeIterableMap$Entry instance
    │    Leaking: UNKNOWN
    │    ↓ SafeIterableMap$Entry.mKey
    │                            ~~~~
    ├─ com.dreamakers.coonna.Adapter.DiscoverStoreAdapter instance
    │    Leaking: UNKNOWN
    │    ↓ DiscoverStoreAdapter.mParser
    │                           ~~~~~~~
    ├─ com.dreamakers.coonna.Activity.HomeFragment$11 instance
    │    Leaking: UNKNOWN
    │    Anonymous class implementing com.firebase.ui.firestore.SnapshotParser
    │    ↓ HomeFragment$11.this$0
    │                      ~~~~~~
    ╰→ com.dreamakers.coonna.Activity.HomeFragment instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.dreamakers.coonna.Activity.HomeFragment received Fragment#onDestroy() callback and Fragment#mFragmentManager is null)
    ​     key = 6e0451ae-0c0b-4de8-8993-011515e95a80
    ​     watchDurationMillis = 6238
    ​     retainedDurationMillis = 1238
    ====================================
    0 LIBRARY LEAKS
    
    A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
    See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
    ====================================
    METADATA

1 Ответ

0 голосов
/ 06 августа 2020

HomeFragment был уничтожен и должен быть обработан сборщиком мусора, но он не может быть собран, потому что DiscoverStoreAdapter зарегистрирован как прослушиватель жизненного цикла в HomeBuyersActivity, а DiscoverStoreAdapter имеет поле mParser, которое является анонимным классом, реализующим SnapshotParser в HomeFragment.

Трудно сказать без кода, но DiscoverStoreAdapter.mParser, вероятно, следует установить в значение null при уничтожении фрагмента.

...