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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to