OK, so I've done some searching, seen others hit this problem but never really saw a solid resolution. I have a situation where I am loading large-ish images (~120KB jpg) from a remote webserver and displaying them to users in a gallery view.
Now these images take a bit of time to download, so I would like to cache them. So I stick the bitmap in a hashmap of softreferences inside a static manager class. I know the usual culprit here is that the programmer is leaking memory. But this is the same approach (soft references, hashmap) that JBQ takes in his shelves app, and I really don't think I'm keeping any more references to the bitmap than the one soft reference. So I don't think leaking is the problem, although if someone who knows better insists that I probably made some mistake, I'll revisit this. And yes I know my "images are too large, make them smaller", but really I want an image larger than the screen so users can zoom and pan around inside the image. If you want to tell me that's not a function Android can support, then I am at a loss for words. So my app gets an External allocation too large message on logcat. It only happens after I run the program for a long time. I see finalize() methods being called on my Image derivative objects, I also see many of the softreference entries going to null inside my hashmap, so I suspect that my cache is operating correctly, although I am not sure how timely the actual bitmaps are being GCed, but I see GC messages saying ~900KB freed, which I can't see coming from anywhere else in my app. So I have three main questions that I can't find the answer to in similar past threads: 1. I've seen recommendation on calling recycle() on bitmaps. But given the fact that I want to keep the bitmap in softreferencecache to keep the app responsive, I don't really know when the softreference goes invalid to call recycle. If the GC runs and clears the softreference that is the only remaining reference to the bitmap, is that as good as calling the recycle on the bitmap, or not necessarily? 2. Is there a way I can manually keep my memory usage down right before bitmap decoding is going to need to work? I see ways to see if the system is in low memory state. But I don't care about that, I need to know about my own dalvik process. How can I estimate whether I have the 1228800 bytes to decode the uncompressed image. Because I know every time I'm about to allocate the image, is there a recommended way to detect issues, and is there a way to force the GC to successfully clean up? I only display one image at a time, although it's possible that the BaseAdapter has more widgets created than just the one being displayed (but I don't suspect that it has that many views holding references to the bitmaps, it does recycle views after all). I see that one Dalvik VM API is deprecated and going internal. What's left for me to use? 3. LAST RESORT: If it's impossible to get Dalvik to stay at a low memory usage. Then I suppose I need to stop caching my bitmaps in a hashmap. In which case I'm going to write them to storage (yuck). I don't want to pollute their SD card, and I don't want them to see the app cache consuming some of their precious ~90MB of usable internal space. Is there an application lifecycle hook that I can hook into to clear up my file cache? I don't want to delete stuff as soon as an Activity goes into the background because they might go right back, I want to hook into when my entire application hasn't done anything in the while and Android low memory kills it. Then I have a minor question: 1. In JBQ's shelves application I see he switches between decoding with SKIA which he uses BitmapFactory.decodeStream and BitmapFactory.decodeByteArray, I didn't realize that one was different. Is SKIA bad? How should we as developers know this? Thanks in advance. -Eric -- 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
