In my experience, WeakReferences are collected quite aggressively by Android 2.3 and higher.
Haven't had a problem with non-static inner classes -- I don't think those are always a memory leak, it all depends on the lifespan duration of the inner object instances. I think MAT is a great tool for tracking down stuff. I'm always careful to force GC in DDMS a few times (monitoring logcat output, until GC collects, basically, nothing). This makes the picture a lot clearer. In MAT, I usually start by looking at the object histogram, and applying filters by my package name or a specific class. -- K 2014-09-18 1:35 GMT+04:00 Nathan <[email protected]>: > Should WeakReferences prevent garbage collection? I thought they were weak > because they didn't prevent garbage collection. > > I am seeing that some of the Android classes are holding static > collections of stuff. I can't see where I am causing that behavior, but I > keep trying. > > In fact, some of the articles on this topic suggest replacing your > anonymous inner classes with named, static inner classes that have > WeakReferences to the outer activity. There are forty of those inner > classes, with all the clicklisteners and whatnot. It is quite a bit of > turmoil to change them all, but I may do that. > > All in all, as shown here, these things are often obscure. > It took me weeks to track down a memory leak caused by Google Analytics > before I could release my first app. I believe MAT helped me find the > crucial evidence. > > Have the rest of you found that following the links, trees, reports, and > histograms in Memory Analyzer are helpful? it seems like there ought to be > some clues in there, but I am getting mostly false leads. > > Otherwise I am using Treking's method. Disabling bits of functionality at > a time. > > Nathan > > > On Tuesday, September 16, 2014 5:56:48 AM UTC-7, Streets Of Boston wrote: >> >> I had a similar issue once and I tracked it down to the View#setTag(int >> key, Object tag) method. >> In my code, setTag was called with a tag value being an object >> holding/referencing an instance that had children referring to children of >> the View on which this setTag was called (tag was a 'ViewHolder' >> instance). >> >> Certain versions of Android implement setTag using a *static *map of >> WeakRereferences. This caused a View to never get garbage collected, since >> the tag would hold references to its children whose parents would then >> point (all the way up) to that View again. And if a View doesn't get >> garbage collected, its Context (i.e. Activity) would never get garbage >> collected. >> >> Look if there is anything holding on to your Activity by the virtue of >> other instances being held through incorrect usage of WeakReferences. >> >> >> On Wednesday, September 10, 2014 12:00:36 AM UTC-4, Nathan wrote: >>> >>> I'm fairly sure I have been able to use the eclipse tools before to >>> track down memory leaks - I even found one in Google Analytics. >>> >>> But I can't for the life of me figure out. >>> >>> I have found out that there are two instances of Activity B in memory >>> when the activity is closed. I can see that with >>> >>> I know enough to know that that is bad. >>> >>> But what I cannot see is WHY. Why is that stupid activity still in >>> memory twice? >>> >>> I seem to remember that I right click on something and choose Merge Path >>> to GC Roots. >>> >>> Then I get something like this. >>> >>> >>> Class Name >>> | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------- >>> com.android.internal.policy.impl.PhoneLayoutInflater @ 0x42d2b0d8 >>> Unknown | 1 | 40 >>> | 536 | 64 >>> '- mPrivateFactory, mContext MyActivity @ 0x42d28230| 1 >>> | 536 | 536 | 127,336 >>> class com.android.internal.os.ZygoteInit @ 0x41a21a18 System >>> Class | 1 | 120 >>> | 536 | 1,000 >>> '- mResources android.content.res.Resources @ >>> 0x41aa7108 | 1 >>> | 112 | 536 | 8,512 >>> '- mContext android.app.ContextImpl @ 0x43009398 >>> | 1 | 128 | 536 | 10,400 >>> '- mOuterContext MyActivity @ 0x42d4f008 | 1 >>> | 536 | 536 | 3,864 >>> ------------------------------------------------------------ >>> ------------------------------------------------------------ >>> ------------------------------------------- >>> >>> Well that PhoneLayoutInflater shouldn't be holding on to that context of >>> a closed activity, but I don't think I control that. >>> And definitely that ZygoteInit thing shouldn't be holding a context in a >>> static way, but I don't control that either. >>> >>> Any tips on finding the causes better? >>> >>> Nathan >>> >>> >>> Nathan >>> >> -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Android Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en --- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
