Ignoring the monkey wrench in the works represented by Android's
handling of image data outside of the Java heap, the rules for what
gets collected and what doesn't are quite straight-forward: If
something can possibly be referenced it's saved. If not, it's
eligible for collection (though, depending on the collection
algorithm, it might not be collected for several GC cycles.)
Java GC works basically by starting from the known "roots" (basically
pointers in your program stack) and "tracing" all the objects that can
be "reached". As a new object is encountered in this "trace", it is
added to the list of objects to be traced, and eventually all of its
pointers will be examined (and followed to other objects). (While
this sounds like it would be slow, it's actually quite fast to do if
properly optimized.)
Objects can't get "lost". If an object gets to the point where
absolutely nothing points to it, it gets collected. The problem comes
when objects are not so much "lost" as "forgotten" -- eg, there is a
pointer to them somewhere in some structure that you used four calls
down in the stack and you'll never reference again. Worst is when
this "forgotten" object is something like a hashtable that references
a whole bunch of other objects.
One important thing to understand is that heap grows until it reaches
a threshold that triggers garbage collection. So if you look at heap
size from time to time in a small application that uses heap
relatively slowly, the heap will appear to be growing larger and
larger (because it is). This (within reason) is not a problem -- as
you conceptually "delete" objects (by, eg, overwriting the pointers to
them in your program stack) they are not immediately freed but rather
will sit there until the next GC cycle (or perhaps several cycles, for
some algorithms). Over time, after several GC cycles, your heap
should achieve a sort of "steady state" -- the occupied size will rise
steadily until GC occurs, then reset, but the minimum size of the heap
after a "full" GC cycle will remain relatively fixed. Occupied heap
size will graph as a sawtooth where the tops and bottom of the teeth
describe relatively horizontal lines.
If you have a "leak" ("forgotten" objects), however, the heap size
graph will show a steady increase from one "tooth" to the next of the
sawtooth graph.
On Jan 23, 12:47 am, TheRain <[email protected]> wrote:
> Hey all-
>
> I'm fairly new to Android development and Java development and I've
> discovered that an app I created recently has a serious memory leak
> issues.
>
> Due to the nature of this app, potentially Activities could be added
> to the stack ad infinitum. To make matters worse, every activity
> downloads a lot of images from web feeds.
>
> I have read a lot about bitmaps leaking in android and have
> implemented many suggestions from the web about how to release these
> explicitly. I'm mainly doing this in the onStop override for each
> Activity. It seems that I still have a lot of leaking going on, I
> have some lines of code tracking the memory build up as I go.
>
> I have a few pointed questions about what I'm doing that I'm hoping
> getting answers to will correct my understanding and my code:
>
> 1.) My understanding is that if an object (an Activity in this case)
> is holding objects, upon being destroyed the memory for those objects
> should also marked for GC as long as nothing else is holding a
> reference to it. Is that correct? Because of that, I have been
> using the current Activity as the context for any Adapters I
> instantiate as well, assuming that would pair the Adapters and any
> views they are holding with the Activities lifecycle.
> Is that more or less correct?
>
> 2.) If I start another activity from the current activity, what
> context should I pass to the constructor of Intent? Currently I've
> been either using the current activity instance, or the view who's
> onclicklistener has been triggered.
>
> 3.) If I set a reference to a new object, the previous object it held
> should be ready for GC, assuming nothing else is holding it, correct?
>
> Any other thoughts or ideas around my problems would be appreciated as
> well. I have been finding the DDMS tool to be difficult to use to
> trace back leaks to their origins.
>
> Thanks!
--
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
