10 threads is still a lot. All of the devices you will run on the foreseeable future are only going to have one cpu, so one thread, maybe two (you might get some parallelism out of decoding while another thread is reading through problem not much) should be more than enough. Going up to ten has a good chance of having worse performance than just a couple, since the scheduler is now needing to bounce around between all those threads (plus until 1.6 we are only relying on the Linux nice level for scheduling threads, so the more threads you have doing work in the background, the more time you will take away from the main thread as it wants slices to interact with the user).
Anyway nothing you do should make the system freeze, so there is definitely a system bug there. :) Does pressing the home button not work either? On Fri, Sep 11, 2009 at 7:00 PM, Mark Murphy <mmur...@commonsware.com>wrote: > > michael m wrote: > > What I am doing, which I question, is loading each image via a thread > > as it is retrieved from the ImageCache...I pass back a default image > > if the bitmap is null, then update the default image in the ImageViews > > with the Bitmap is loaded from the sdcard; I'm doing this by posting > > to a Handler in the Adapter from the thread that loads the image. > > I suspect you are going to get in trouble with that many threads. > > > So if the number of threads is the problem I'm thinking of loading all > > the bitmaps when the app is first initiated, probably using the > > AsyncTask class. > > That is probably too far in the other extreme. > > > A question I have though about this is that the docs > > say that you can only call execute() once...what's happens if some of > > my Bitmaps are garbage collected?? Do I then call individual threads > > to reload? I've looked through some of the Google apps, Shelves and > > Photostream, but they don't seem to be using Bitmaps wrapped in > > SoftReferences. > > I've wrapped up this pattern in a ThumbnailAdapter: > > http://github.com/commonsguy/cwac-thumbnail/tree/master > > Basically, I use AsyncTaskEx, which is my fork of AsyncTask that allows > for 10 parallel threads -- not infinite, but not only 1. > > I also gave up on SoftReferences, as posts in this list from a month or > two ago gave me the impression that SoftReferences are effectively > pointless with the current Dalvik garbage collection implementation. > Instead, I use an LRU cache, (re)loading images on demand via AsyncTaskEx. > > It may be, though, that ThumbnailAdapter will "just work" for you, > though I have not tried it for images starting on the SD card -- I was > focused on caching them off the Internet. I don't have much in the way > of documentation at this point, but there is a sample app in the github > project. While I suspect I'll be upgrading the implementation in the > coming months, the "API" (put the URL of the image to be loaded in the > ImageView's setTag()) should remain constant. > > If you give it a whirl and run into problems, ping me on the cw-android > Google Group, and I may be able to help: > > http://groups.google.com/group/cw-android > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://twitter.com/commonsguy > > Android Development Wiki: http://wiki.andmob.org > > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. 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 -~----------~----~----~----~------~----~------~--~---
