Ivan, Which Android version are testing this with?
Among the devices I own, 2.2 seems much more aggressive with GC than 2.1. 01.04.2011 0:20 пользователь "ivan" <istas...@gmail.com> написал: > Roman, can you recommend your preferred way for analyzing whether or > not an object is being withheld from GC by another? > > On Mar 31, 2:05 pm, Romain Guy <romain...@android.com> wrote: >> 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 -- 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
