I will guarantee you that each image is not 100 bytes. Actually, I'll bet that is more along the lines of the amount of memory needed just for the Java and C++ data structures for the drawable and bitmap objects. The size of a status bar icon is 25x25; I will assume that this image is 32bpp since without an alpha channel it very unlikely it will look good in the status bar, so that gives us 2500 bytes per image. Multiplied by 5,000 images, that is 12MB of RAM. For reference, that is larger than the entire memory used by the system process after initial boot. (Even if we were to take your number of 100 bytes, that is still 1/2 meg of image data, which is a noticeable increase in the system process size.)
And it's not just the crazy amount of RAM we are talking about. When you put your notification in the status bar, it would have to load *****5,000***** images to display it. That is going to take a hell of a long time. Actually, it's pretty likely this would cause the status bar to ANR. Repeatedly. And once it's loaded, none of the drawable containers were designed to deal with such an extreme number of images -- they were design with the order of 10s of images in mind. Any change to the drawable will result in a linear search through all of the images to find the best match. This is just a totally unreasonable thing to do. Sorry. :} 1000 states is also really unreasonable. And there is really just no reason in the world to do this kind of thing. You can freely update the notification whenever you want, with whatever new icon you want. You do want to be careful about not updating too often there (try to target no more than once a minute, definitely keep it no less than 10s of seconds), but that is true regardless just for simple battery life. And actually wouldn't you need to repost the notification when you want to change the icon regardless of whether you have all of those images in a single drawable? If so, having the notification show one explicit icon is going to be so incredibly more efficient than sending over a ton of icons each time only one of which will be shown, that there really isn't anything to think about here. On Thu, Aug 27, 2009 at 8:24 AM, markh23 <[email protected]> wrote: > Thanks for the responses. > > So from I got, it's the sheer number of images that makes this > scenario difficult for Android to handle? And the size of each of the > images won't make (much of) a difference? Say for instance, I have an > icon with 1000 states, and each image is only 100bytes. Will this > still get me in trouble? > > Thanks again. > > --Mark > > On Aug 27, 1:24 am, Dianne Hackborn <[email protected]> wrote: > > Btw, if at some point in the future I find myself trying to figure out > why a > > particular device is sluggish with a big system process, and see this > > situation, I will without hesitation put in a limit on the number of > images > > associated with a notification to something reasonable. :} > > > > On Wed, Aug 26, 2009 at 10:19 PM, Dianne Hackborn <[email protected] > >wrote: > > > > > > > > > > > > > The current absolute limit is 32,767 resources per type. > > > > > However... uh, you should really re-think this. All of the drawable > > > containers (level list, state list, etc) load ALL of their images > up-front. > > > Ghod god please please don't load 5,000 images into the system process. > > > Please. > > > > > On Wed, Aug 26, 2009 at 9:15 PM, markh23 <[email protected]> > wrote: > > > > >> Hello, > > > > >> I have a notification icon in the status bar with thousands (5000+) of > > >> states, and each state has a different corresponding icon. Right now > > >> I'm using a <level-list> xml file to switch between all these > > >> different images. > > > > >> It seems to be working right now (it takes a little longer to install/ > > >> uninstall from the emulator however), but does someone see any > > >> problems with this that I'm not catching? Is it possible to have too > > >> many items in the res/drawable folder? Will there be a huge > > >> performance hit by having an icon with so many states? > > > > >> Thanks. > > > > >> --Mark > > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > > 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. > > > > -- > > Dianne Hackborn > > Android framework engineer > > [email protected] > > > > 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. > -- Dianne Hackborn Android framework engineer [email protected] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
