> Bitmaps are allocated on the native heap but their size is counted
> against the Java heap limit. You can use tools like MAT to see whether
> you are leaking Bitmap objects but you can't rely on these tools to
> measure the amount of memory used by those bitmaps.
Too bad.
> Thankfully, it's
> very easy to figure out how much memory is used by a bitmap :)
Not true in all cases. Look at BitmapFactory.Options:
-------
public boolean inPurgeable
Since: API Level 4
If this is set to true, then the resulting bitmap will allocate its
pixels such that *they can be purged if the system needs to reclaim
memory*. In that instance, when the pixels need to be accessed again
(e.g. the bitmap is drawn, getPixels() is called), they will be
automatically re-decoded. For the re-decode to happen, the bitmap must
have access to the encoded data, either by sharing a reference to the
input or by making a copy of it. This distinction is controlled by
inInputShareable. If this is true, then the bitmap may keep a shallow
reference to the input. If this is false, then the bitmap will
explicitly make a copy of the input data, and keep that. Even if
sharing is allowed, the implementation may still decide to make a deep
copy of the input data.
---------
Unless you assume using inPurgeable is utterly useless, I can't tell
if those bitmaps are being purged when necessary.
That means that bitmap is using either 0, 29K bytes, 256k bytes.
That's quite a range.
In total, that means that this bitmap collection is using somewhere
between 600K bytes and 70000K bytes. Quite a range also.
So is inPurgeable useless or does it work?
Nathan
--
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment