I have a few questions regarding Bitmap objects and memory and their general taxonomy.
A bitmap is simply a rectangle of pixels. Each pixel can be set to a given color but exactly what color depends on the type of the pixel. The first two parameters give the width and the height in pixels. The third parameter specifies the type of pixel you want to use.
A bitmap is a type of memory organization or image file format used to store digital images. The term bitmap comes from the computer programming terminology, meaning just a map of bits, a spatially mapped array of bits.
Examples of bitmap graphic formats include GIF, JPEG, PNG, TIFF, XBM, BMP, and PCX as well as bitmap (i.e., screen) fonts. The image displayed on a computer monitor is also a bitmap, as are the outputs of printers, scanners, and similar devices.
The memory that backs a Bitmap object is allocated using native code (malloc()
), rather than the Java new
keyword. This means that the memory is managed directly by the OS, rather than by Dalvik.
The only real difference between the native heap and Dalvik's heap is that Dalvik's heap is garbage collected, and the native one isn't.
For these purposes though, here's not much difference. When your Bitmap object gets garbage collected, it's destructor will recycle the associated memory in the native heap.
Source:
There is an important subtlety here: though Bitmap pixels are allocated in the native heap, some special tricks in Dalvik cause it to be accounted against the Java heap. This is done for two reasons:
(1) To control the amount of memory an application allocates this. Without the accounting, an application could allocate a huge amount of memory (since the Bitmap object itself is very small yet can hold on to an arbitrarily large amount of native memory), extending beyond the 16MB or 24MB heap limit.
(2) To help determine when to GC. Without the accounting, you could allocate and release references on say 100 Bitmap objects; the GC wouldn't run, because these objects are tiny, but they could in fact represent a large number of megabytes of actual allocations that is now not being GCed in a timely manner. By accounting these allocations against the Java heap, the garbage collector will run as it thinks memory is being used.
Note that in many ways this is an implementation detail; it is very likely that it could change in the future, though this basic behavior would remain in some form since these are both important characteristics for managing bitmap allocations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With