Menu
I am trying to fix the memory leak using the LeakCanary and honestly, I can't understand the stack trace that was showing me. I am using a firebase paging option and stop the listening on the onDestroy method. I also did not pass any activity or context to the adapter so I am sure that there is no problem in that. Below are the logs from the 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
796
LeakCanary hooks into the Android lifecycle to automatically detect when activities and fragments are destroyed and should be garbage collected. These destroyed objects are passed to an ObjectWatcher , which holds weak references to them.
LeakCanary 🐤 LeakCanary is a memory leak detection library for Android. LeakCanary's knowledge of the internals of the Android Framework gives it a unique ability to narrow down the cause of each leak, helping developers dramatically reduce Application Not Responding freezes and OutOfMemoryError crashes.
Memory leaks occur when an application allocates memory for an object, but then fails to release the memory when the object is no longer being used. Over time, leaked memory accumulates and results in poor app performance and even crashes.
The HomeFragment was destroyed and should be garbage collected, but it cannot be garbage collected because DiscoverStoreAdapter is registered as a lifecycle listener on HomeBuyersActivity and DiscoverStoreAdapter has a mParser field which is an anonymous class implementing SnapshotParser in HomeFragment.
It's hard to say without the code, but DiscoverStoreAdapter.mParser should probably be set to null when the fragment is destroyed.
135
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
