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 <nathan.d.mel...@gmail.com>: > 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 android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > 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 android-developers+unsubscr...@googlegroups.com. > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com 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 android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
