Android Image Problems(blog.nicholascampion.com)
blog.nicholascampion.com
Android Image Problems
http://blog.nicholascampion.com/android-image-problems
3 comments
Author here. Thanks for reading. I concede that its possible to manage Bitmaps without issue. But I'd argue there are tons of resources (and SO questions) because the system in place is such a mess. Recycling bitmaps manually is a non-functional(and not elegant) solution for many use cases and really should be unnecessary in a environment featuring a GC. (though i understand why the implementation is the way it is).
I feel like it is a limitation of the framework. The problem exists because of limitations of the OS and the solutions for the problems (tiered memory-disk caches, custom remote image widgets) are "challenging" because of the limits. The problem itself (build the cache or remote widget) isn't conceptually or technically hard, its only hard because of the tools at our disposal.
I feel like it is a limitation of the framework. The problem exists because of limitations of the OS and the solutions for the problems (tiered memory-disk caches, custom remote image widgets) are "challenging" because of the limits. The problem itself (build the cache or remote widget) isn't conceptually or technically hard, its only hard because of the tools at our disposal.
There's a good video from a recent Google I/O on memory management where they explain the recycle method, their reason for requiring it, and that it won't be necessary in 2.3 and up. I still always recycle everything manually just to be defensive, but supposedly it's not required anymore in API 10+. Whenever you see a framework object with a recycle method it's because the memory is allocated outside of the dalvik heap, so it's not part of the GC cleanup process.
The real bitch of this, and what I think you were getting at, is the lack of accurate memory debugging tools. I read a really long post on SO about a guy who tested all of the various ways of testing memory consumption through DDMS, adb, etc, and all the numbers he got were conflicting.
The real bitch of this, and what I think you were getting at, is the lack of accurate memory debugging tools. I read a really long post on SO about a guy who tested all of the various ways of testing memory consumption through DDMS, adb, etc, and all the numbers he got were conflicting.
(1) If I'm just expanding included resource files (compressed images) into bitmaps for display, I write my own intelligent cache. Backed by a simple HashMap, I can even include in my cache keys the desired height and width and downsample intelligently and cache the downsampled version. Funny enough, when I presented this to my coworker, he had just done almost the exact same thing and we had never discussed it. In one case I needed to categorize my images to flush some and not others from the cache, so I just wrapped a bunch of instances of the same BitmapCache into a BitmapCacheManager class and it worked like a charm.
(2) To get around the fact that you can't just set the source path of an ImageView to a web url, you can use a custom class that wraps ImageView and just handles downloading the image on a background thread. I wrote a pretty complicated system that pumps the urls to a queue and broadcasts a notification when each download completes, but a single google search pointed me to an awesome apache licensed library that does exactly the same thing (and is admittedly cleaner than mine).
https://github.com/loopj/android-smart-image-view
It's totally doable. I never looked at it as a limitation of the framework - I actually saw it as an opportunity to do something more challenging than just drawing within the lines of the framework.