I have seen many lists with images before. Again, I'd be happy to fix a possible issue but I would need a repro case and an explanation of what is holding memory and how. I can certainly see views moved to the scrap heap holding onto these large images, but the scrap heap is mostly filled when a list uses views of different types, which doesn't seem to be what you are describing (I would expect at most one view in the scrap heap in your case.)
On Thu, Mar 31, 2011 at 12:02 PM, Matthew Powers <mtpow...@gmail.com> wrote: > Yeah we have a unique setup. An e-reader that uses a listview to actually > scroll vertically instead of using the conventional gallery, with very high > resolution images. It doesn't surprise me that you have not seen this > before, its an unconventional way of using a listview and we are using very > high res images. I can assure you though, it happens. > > > On Thu, Mar 31, 2011 at 2:51 PM, Romain Guy <romain...@android.com> wrote: > >> Bitmaps are an entirely different problem. Android 3.0 improves bitmaps >> memory management a lot by reducing the time it takes for them to be >> reclaimed by the GC. A leak happens only if there's memory that never gets >> reclaimed, which I believe is not the case here. I would again be happy to >> track down and fix such an issue but the fact that we've never witnessed it >> in many many apps that use ListView makes me doubtful. >> >> On Thu, Mar 31, 2011 at 11:47 AM, Matthew Powers <mtpow...@gmail.com>wrote: >> >>> Sorry I didn't explain myself fully. In our layout we have a listview >>> with rather large images. We have shown many times that the gc does not run >>> quick enough to clean up the images onDestroy, onConfigurationChange, etc >>> and are getting OOM exceptions. We have seen bitmaps getting stranded and >>> have had to clean them up by hand, thus walking the tree and recycling the >>> individual bitmaps by hand (nulling out does nothing). There appears to be >>> new documentation about the recycler where theoretcially we could set a >>> recycler listener and monitor when a view is moved onto the scrap heap to >>> achieve the same thing, however I have seen instances of onMovedToScrapHeap >>> firing on views that are still in focus. I have submitted a bug with >>> detailed instructions on how to reproduce this. >>> I could be wrong but we have had a lot of engineers looking at this leak >>> in the listview over the last several months. >>> >>> >>> On Thu, Mar 31, 2011 at 2:40 PM, Romain Guy <romain...@android.com>wrote: >>> >>>> There is no need to do this whatsoever. And you cannot "recycle" Views >>>> anyway, at most you can set all the references to null manually which will >>>> not make much of a difference. The GC will eventually collect the ListView >>>> instances. >>>> >>>> On Thu, Mar 31, 2011 at 11:32 AM, Matthew Powers <mtpow...@gmail.com>wrote: >>>> >>>>> I have played with this MANY times. The only solution I have seen is >>>>> to walkthetree in the listview and recycle your objects by hand >>>>> >>>>> On Thu, Mar 31, 2011 at 2:08 PM, ivan <istas...@gmail.com> wrote: >>>>> >>>>>> Ok I just tested the api demo again. >>>>>> >>>>>> I went in and out of List1.java 15 times, and only saw 8 instances >>>>>> still on the heap. >>>>>> >>>>>> So, clearly "some" are being GC'd. >>>>>> >>>>>> My question still remains... Why doesn't this happen with other views? >>>>>> >>>>>> On Mar 31, 11:50 am, ivan <istas...@gmail.com> wrote: >>>>>> > So to reiterate ... >>>>>> > >>>>>> > I can see every instance of a ListView/ListActivity (ever created) >>>>>> > sitting around in memory, even though I force a GC in every call to >>>>>> > onDestroy(). >>>>>> > ... And this is the expected behavior, because the Dalvik GC will >>>>>> > "eventually" collect them. >>>>>> > >>>>>> > Why isn't this the case with other views? >>>>>> > >>>>>> > On Mar 31, 10:28 am, Mark Murphy <mmur...@commonsware.com> wrote: >>>>>> > >>>>>> > > On Thu, Mar 31, 2011 at 11:58 AM, ivan <istas...@gmail.com> >>>>>> wrote: >>>>>> > > > Incoming references and path to GC root show only the >>>>>> TmpTestActivity. >>>>>> > >>>>>> > > If I am understanding you correctly, then, it is merely a matter >>>>>> of >>>>>> > > them not having been GC'd yet. Bear in mind that the Dalvik GC >>>>>> > > implementation does not try to reclaim all unreferenced objects in >>>>>> a >>>>>> > > single pass. >>>>>> > >>>>>> > > -- >>>>>> > > Mark Murphy (a Commons Guy)http://commonsware.com| >>>>>> http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy >>>>>> > >>>>>> > > Android Training in NYC:http://marakana.com/training/android/ >>>>>> >>>>>> -- >>>>>> 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 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Romain Guy >>>> Android framework engineer >>>> romain...@android.com >>>> >>>> Note: please don't send private questions to me, as I don't have time to >>>> provide private support. All such questions should be posted on public >>>> forums, where I and others can see and answer them >>>> >>> >>> >> >> >> -- >> Romain Guy >> Android framework engineer >> romain...@android.com >> >> Note: please don't send private questions to me, as I don't have time to >> provide private support. All such questions should be posted on public >> forums, where I and others can see and answer them >> > > -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them -- 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
