Hello Mark! I had a question when I came across this blog post about memory leaks written by Romain Guy. http://www.curious-creature.org/2008/12/18/avoi...

hi

So he shows the example, and I thought I knew the memory leak. I thought the drawable was leaked because it takes an activity to call getResources.getDrawable(); and so the drawable is leaked because of that. Then I read further, and he says the memory leak has to do with drawable attacheing to the view creates some callback that is leaked.

OK

and, your question is...?

:-)

So why am I wrong, and why is he right? What does that callback have to do with anything. The view isn't static... the drawable is.

well, resources are always "leaked", in that we do not explicitly unload them ourselves

?

Resources you mean anything from getResources/

?

I have no idea what getResources/ is

I mean Android resources

res/drawable-mdpi/

res/values/strings.xml

etc.

getResources is what you can call on activity to get drawables and strings

At least thats what Ive been doing.

oh, you mean getResources()

I am referring to the actual resources themselves

the drawables, strings, etc.

when you load a resource, such as a drawable, we never release that ourselves

that's why tools like MAT will report a bunch of those floating around our heap space

there's nothing we can really do about those

Oh!

Okay. So when do they actually get released?

And what gets leaked... the R.drawable.myimg integer in R.java? Or the drawable png file itself?

"when do they actually get released": AFAIK, they don't

Because the int isn't a big deal then, but the png file could be big

and it's neither the int nor the PNG, but the Bitmap decoded from the PNG

which will be substantially larger than the PNG itself

Oh. So those bitmap are big also

Yeah

Hmmm... that sucks.

So loading a whole bunch of those is really bad also.

in Romain's post, the Drawable itself is directly leaked, due to the static reference

it's usually only a problem if you have really big drawable resources, like full-screen backgrounds

anyway, back to Romain...

the non-obvious part is that an in-use Drawable can (or at least could, back in 2008) have an indirect reference to a widget that uses it

which in turn has a reference to the activity that hosts the widget

and the activity tends to hold onto a whole lotta stuff

now, I haven't heard about this issue in ages, so it might be fixed in the framework now

So now this isn't the case?

Okay cool. Good to know.

that being said, I still wouldn't put a Drawable in a static data member

Got it.

Alright, just wanted some clarification. Im going to look into if it was fixed in the framework

OK

and that's a wrap for today's chat

next one is Monday at 4pm Eastern

have a pleasant day!