Office Hours — Today, September 18

Tuesday, September 16

Mark M.
has entered the room
Mark M.
turned on guest access
Sep 18
8:10 PM
EGHDK
has entered the room
EGHDK
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...
8:15 PM
Mark M.
hi
EGHDK
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.
Mark M.
OK
and, your question is...?
:-)
EGHDK
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.
8:20 PM
Mark M.
well, resources are always "leaked", in that we do not explicitly unload them ourselves
EGHDK
?
Resources you mean anything from getResources/
?
Mark M.
I have no idea what getResources/ is
I mean Android resources
res/drawable-mdpi/
res/values/strings.xml
etc.
EGHDK
getResources is what you can call on activity to get drawables and strings
At least thats what Ive been doing.
Mark M.
oh, you mean getResources()
I am referring to the actual resources themselves
the drawables, strings, etc.
8:25 PM
Mark M.
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
EGHDK
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?
Mark M.
"when do they actually get released": AFAIK, they don't
EGHDK
Because the int isn't a big deal then, but the png file could be big
Mark M.
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
EGHDK
Oh. So those bitmap are big also
Yeah
Hmmm... that sucks.
So loading a whole bunch of those is really bad also.
Mark M.
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
8:30 PM
Mark M.
now, I haven't heard about this issue in ages, so it might be fixed in the framework now
EGHDK
So now this isn't the case?
Okay cool. Good to know.
Mark M.
that being said, I still wouldn't put a Drawable in a static data member
EGHDK
Got it.
Alright, just wanted some clarification. Im going to look into if it was fixed in the framework
Mark M.
OK
and that's a wrap for today's chat
next one is Monday at 4pm Eastern
have a pleasant day!
EGHDK
has left the room
Mark M.
turned off guest access

Tuesday, September 16

 

Office Hours

People in this transcript

  • EGHDK
  • Mark Murphy