

Android Image Problems - campnic
http://blog.nicholascampion.com/android-image-problems

======
aguynamedrich
The OutOfMemory issue is a pretty big problem, but I'd say it's quite lazy to
just dismiss it as something the framework needs to fix so that you can
effectively do your job. I ran into this problem a lot early on in my Android
development, and as I studied it further I found tons of resources and
information to make it work in all cases and there are plenty of creative
solutions documented in blogs and discussed on StackOverflow about it as well.
Half the time you can get around this error by recycling your bitmaps when
you're done with them and/or rethinking your approach to needing really large
bitmaps in memory at the same time. There are two things I've done commonly in
apps to get around this.

(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.

~~~
campnic
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.

~~~
aguynamedrich
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.

