My problem is that I display dynamic images (buddy's avatars) which size can reach 128*128 but I down sample them into 64*64 so I can't use static members for them. A background thread (a single threaded ExecutorService) is responsible for producing the 64*64 thumbnails, using BitmapFactory. When a thumbnail is ready, a callback is called which occur in a call to notifyDataSetChange and the list view is refreshed.
Even when all the thumbnails are decoded, I have still garbage collector passes when I scroll the list view. I don't inflate views each time, I reuse the convertView given by the getView callback in BaseAdapter (I have overriden it). The problem seems to be the imageView.setImageBitmap call. Even if the thumbnail has been down sampled to 64*64 (and the image view is 64*64), the documentation of BitmapFactory says the sampling may not be accurate so I wonder if the image view makes extra work on the bitmaps. 2008/12/25 JP <joachim.pfeif...@gmail.com> > > Freepine might be right - I just toyed a little to see if there's any > match between garbage collection and the scrolling (of a map). I am > spreading garbage collection pretty wide however and it occurs at a > time when it does not affect the user experience much, so it goes > unnoticed. > So you will see changes but scrolling might still not smooth out. > There's a few additional things you can try; prefetch images and keep > them allocated until users performs an action where user would not > necessarily expect smooth transitions. Keep static images in class > variables. Good luck. > > On Dec 24, 5:15 am, Guillaume Perrot <guillaume.p...@gmail.com> wrote: > > I have very short freezes when scrolling a very long list views > > containing down sampled images (I use BitmapFactory to produce > > thumbnails in background that are placed in RAM cache but there is > > still a problem). > > When I look at the logs, each mini UI freeze corresponds to a garbage > > collector log, the freed memory can reach 1 MB ! > > I don't call the gc myself but I guess this is called automatically in > > the main thread, so it slows my UI. > > Maybe calling it explicitly in a background thread (and I have one for > > all network operations) may help, I'll try JP's approach ASAP. > > > > On Dec 24, 11:16 am, freepine <freep...@gmail.com> wrote: > > > > > Hi JP, > > > > > Yes, I agree to avoid time-consuming tasks in main thread:)What I am > saying > > > is that mostly GC will hold the whole process' execution while > collecting > > > memory, so it might not behave as you assumed even you put it in a > separate > > > thread. > > > > > -freepine > > > > > On Wed, Dec 24, 2008 at 1:37 PM, JP <joachim.pfeif...@gmail.com> > wrote: > > > > > > My approach is to relief the main thread from any heavy lifting; > > > > calling web servers, processing data and preparing data structures. > > > > Calls to web servers should also not be made directly from the main > > > > thread. All that helps a great deal to keep the app responsive. > > > > Correction: Is essential to keep the app responsive. You need to > > > > understand how to build mutex' though. > > > > Calling garbage collection (in the background thread) is in a way > just > > > > another operation which occurs in background thread processing. I > > > > stopped worrying about that a long time back. > > > > JP > > > > > > On Dec 23, 5:58 pm, freepine <freep...@gmail.com> wrote: > > > > > I was thinking that Dalvik GC was the stop-the-world GC. Does it > matter > > > > to > > > > > call gc manually in a seperate thread or UI thread itself? > > > > > > > -freepine > > > > > > > On Wed, Dec 24, 2008 at 2:49 AM, JP <joachim.pfeif...@gmail.com> > wrote: > > > > > > > > Depends where it's placed at. I calls to the GC "scattered" all > over, > > > > > > but with discretion. I made a concious design decision to avoid > > > > > > allocating memory in the presentation layer which is handling > user > > > > > > interactions. I rely on a separate thread to handle all "back > end" > > > > > > activities such as capturing and processing data, and found it is > safe > > > > > > to call the garbage collector in this separate thread at pretty > much > > > > > > any time. Garbage collection in this archiecture is just one > other > > > > > > activity that will not interfere with the user experience, as > long as > > > > > > the overall burden on resources remains within device > capabilities. > > > > > > > > On Dec 22, 12:41 pm, Dan Bornstein <danf...@android.com> wrote: > > > > > > > On Sun, Dec 21, 2008 at 11:34 PM, Imran <imran...@gmail.com> > wrote: > > > > > > > > hey can i use System.gc() in my activity to request for > > > > garbage > > > > > > > > collection. > > > > > > > > will it work () .. will the garbage collector be called > ? > > > > > > > > > Yes it will. However, let me warn you that in my experience > adding > > > > > > > explicit calls to System.gc() almost always results in > applications > > > > > > > that perform worse than ones that just let the underlying VM gc > as it > > > > > > > sees fit. > > > > > > > > > -dan > > > -- Guillaume Perrot Software Engineer at Ubikod BuddyMob developer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
