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 --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
