On Jun 16, 11:48 am, Romain Guy <[email protected]> wrote: > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
