Any ideas? I've created a little test app that's nothing more than a Gallery with an adapter that creates an ImageView and populates it through new BitmapDrawable(BitmapFactory.decodeFile(filename)), with always the same filename.
Every time a new view is created, the "data object" size increases by 2KB or so. What is classified as a "data object" and how can I track them? Likewise, the 1-byte array heap also goes up by 32KB every time, as do the 4-byte arrays (by 4KB). And finally, how is the 16MB heap an application has split up? In the constructor of my test app, Runtime.getRuntime().freeMemory() returns ~760KB. -Mike On Nov 16, 12:34 pm, EboMike <[EMAIL PROTECTED]> wrote: > I'm reading JPGs off the storage device, and they are typically > 1024x768 since they came straight from a server. The VM typically > errors out allocating ~1MB of memory. (One time, it errored allocating > 30KB even though the gc freed up 900KB just prior to that). > > Yeah, I could have the server crunch the image to 480x320 first, but > I'd like to reserve the option to add a zoom function later. Besides, > it DOES work most of the time, and if I really have a 16MB heap, there > shouldn't be any issues whatsoever. > > By the way, it does seem like there might be a leak - in the "data > object" row in the Heap DDMS view, I seem to be leaking 10KB or so > with every image. How can I track down what's going on there? Like I > mentioned earlier, my BitmapDrawables are deleted properly according > to the allocation tracker. > > -Mike > > On Nov 16, 12:02 pm, Romain Guy <[EMAIL PROTECTED]> wrote: > > > What is the size of the Bitmap you are trying to create? > > > On Sun, Nov 16, 2008 at 11:33 AM, EboMike <[EMAIL PROTECTED]> wrote: > > > > Um, yes... except that I'm randomly getting OutOfMemoryExceptions when > > > I create a new bitmap :) > > > > On Nov 16, 11:13 am, Romain Guy <[EMAIL PROTECTED]> wrote: > > >> 16 MB is the maximum limit of the heap. Your app can use at most 16 > > >> MB. The heap in your application will grow as more memory is needed. > > >> If you're currently at 3/4 MB, then everything's fine :)) > > > >> On Sun, Nov 16, 2008 at 11:00 AM, EboMike <[EMAIL PROTECTED]> wrote: > > > >> > Thanks for your answer, Romain! > > > >> > How much of those 16MB are accessible to the app? When I look at the > > >> > Heap view in the DDMS, I only see one heap with a total size of 3MB, > > >> > sometimes 4MB. If I add up all the allocations (either in the VM Heap > > >> > or the allocation tracker), I don't get anywhere near 16 MB. I also > > >> > don't see any major allocation from the drawables themselves other > > >> > than 16KB for the BufferedInputReader and BitmapFactory per drawable - > > >> > is the bitmap data being allocated by native code and invisible to the > > >> > VM allocation tracker? > > > >> > After a gc, Runtime.getRuntime().freeMemory() typically gives me > > >> > numbers between 600KB and 800KB at any given point while I have the > > >> > Gallery up. > > > >> > It also seems that I'm not leaking any drawables, at least judging by > > >> > the number of BitmapDrawable/Bitmap/BufferedInputRead/BitmapFactory > > >> > objects I have in the allocation tracker - they match the amount of > > >> > visible views in my gallery. > > > >> > -Mike > > > >> > On Nov 15, 1:01 am, Romain Guy <[EMAIL PROTECTED]> wrote: > > >> >> Applications have a hard limit of 16 MB. As for the other bug you > > >> >> mention, it has nothing to do with memory usage; the implementation of > > >> >> BitmapFactory that reads images from URL will fail over slow > > >> >> connections. Besides, when you load a Drawable from the resources, it > > >> >> simply calls the BitmapFactory to decode the resource anyway. > > > >> >> If you hit an out of memory exception, your app *is* using too much > > >> >> memory (which you might very well be "leaking," it's not that hard, > > >> >> especially if you use static fields in your code.) You can use DDMS > > >> >> and its allocation tracker, as well as its various GC/heap monitors to > > >> >> see when and how your application is allocating so much memory. > > > >> >> I have run myself into this issue several times over the past 18 > > >> >> months and every time, the application was leaking something > > >> >> (especially on screen rotation.) > > > >> >> On Sat, Nov 15, 2008 at 12:55 AM, blindfold <[EMAIL PROTECTED]> wrote: > > > >> >> > Well Mike, I don't know either, but just remember from my own app > > >> >> > that > > >> >> > I too had a zillion unexplained "Clamp target GC heap" messages at > > >> >> > that 16 MB limit (while my app definitely needs far less memory than > > >> >> > that), until I got rid of Drawables altogether. It could have been a > > >> >> > coincidence, but together with the report from a Google Android Team > > >> >> > member > > >> >> > thathttp://groups.google.com/group/android-developers/browse_thread/threa... > > >> >> > "this is a known bug" (without being more specific) and his > > >> >> > Drawable- > > >> >> > free workaround it suggested that this could be related to your > > >> >> > problem. Of course there are plenty of other things that could be > > >> >> > wrong... > > > >> >> >> This is for an ImageSwitcher, so I need a Drawable of some sort > > > >> >> > I have never used ImageSwitcher myself (Android seems to often offer > > >> >> > at least three totally different ways to do the same thing, which is > > >> >> > nice if two-out-of-three are still too buggy for deployment <g>). > > >> >> > Yet > > >> >> > to avoid Drawables there I could imagine trying > > >> >> > ImageSwitcher.setImageURI(new > > >> >> > ContentURI("/data/data/mypackage/files/ > > >> >> > myimage.jpg")) if the image is in internal flash, or > > >> >> > ImageSwitcher.setImageURI(new ContentURI("/sdcard/mypath/ > > >> >> > myimage.jpg")) when loading from SD card. Just my two cent guess. > > > >> >> > Regards > > > >> >> > On Nov 15, 7:57 am, EboMike <[EMAIL PROTECTED]> wrote: > > >> >> >> Hey blind, you're right, I'm using Drawables -- BitmapDrawables, > > >> >> >> to be > > >> >> >> precise. This is for an ImageSwitcher, so I need a Drawable of some > > >> >> >> sort (since I'm loading jpeg images off the storage device, so I > > >> >> >> can't > > >> >> >> use resources). I've tried BitmapFactory.decodeFile() instead of > > >> >> >> BitmapDrawables constructor that takes a String, but I get the same > > >> >> >> result, except that the OutOfMemoryException is now in > > >> >> >> BitmapFactory.decodeFile() itself instead of a cryptic callstack > > >> >> >> like > > >> >> >> before. > > > >> >> >> I also call the gc right before creating the Bitmap... and the TTY > > >> >> >> is > > >> >> >> kind of interesting: > > > >> >> >> 06:50:43.970: INFO/dalvikvm-heap(6039): Clamp target GC heap from > > >> >> >> 17.019MB to 16.000MB > > >> >> >> 06:50:43.990: DEBUG/dalvikvm(6039): GC freed 8139 objects / 927224 > > >> >> >> bytes in 171ms > > >> >> >> 06:50:45.271: ERROR/dalvikvm-heap(6039): 38400-byte external > > >> >> >> allocation too large for this process. > > >> >> >> 06:50:45.271: ERROR/(6039): VM won't let us allocate 38400 bytes > > >> >> >> 06:50:45.280: DEBUG/skia(6039): xxxxxxxxxxxxxxxxxxxx allocPixelRef > > >> >> >> failed > > > >> >> >> The gc freed 927KB, and then cannot allocate 38KB? Um, what? > > > >> >> >> -Mike > > > >> >> -- > > >> >> Romain Guywww.curious-creature.org > > > >> -- > > >> Romain Guywww.curious-creature.org > > > -- > > Romain Guywww.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
