Computing image memory occupied by a BitMap in Android is optimized,

Computing image memory occupied by a BitMap in Android is optimized,

In Android development, I have found that many users do not perform good computing on the memory occupied by images.

Therefore, I wrote this blog post to introduce it and hope it will serve as a reference.

The memory occupied by a BitMap in Android is mainly related to the following factors: Image length, image width, and the number of bytes occupied by pixels. Memory occupied by an image (BitMap) = image length * Image Width * bytes occupied by pixels Note: The image length and image width are measured in pixels. The memory occupied by the image (BitMap) should have nothing to do with the screen Density (Density), although I still have no direct evidence. When creating a BitMap, the number of bytes occupied by its unit pixels is determined by the inPreferredConfig variable of Its Parameter BitmapFactory. Options. InPreferredConfig is of the Bitmap. Config type, and the Bitmap. Config class is of the enumeration type. It can be of the following values:

Enum Values
Bitmap. Config	ALPHA_8	Each pixel is stored as a single trans0000cy (alpha) channel. This is very useful to efficiently store masks for instance. No color information is stored. With this configuration, each pixel requires 1 byte of memory. At this time, the image only has the alpha value and no RGB value, One pixel occupies one byte
Bitmap. Config	ARGB_4444	This field is deprecated. Because of the poor quality of this configuration, It is advised to useARGB_8888Instead.  Images in this format seem to be of poor quality and are no longer recommended. Each pixel is stored on 2 bytes. The three RGB color channels and the alpha channel (trans1_cy) Are stored with a 4 bits precision (16 possible values .) This configuration is mostly useful if the application needs to store transmissioncy information But also needs to save memory. It is recommended to use ARGB_8888 instead of this configuration. One pixel occupies 2 bytes, alpha (A) value, Red (R) value, Green (G) value, and Blue (B) value each occupy 4 bites. A total of 16 bites, that is, 2 bytes
Bitmap. Config	ARGB_8888	Each pixel is stored on 4 bytes. Each channel (RGB and alpha for trans0000cy) Is stored with 8 bits of precision (256 possible values.) This configuration Is very flexible and offers the best quality. It shoshould be used whenever possible A pixel occupies 4 bytes, And the alpha (A) value, Red (R) value, Green (G) value, and Blue (B) Values each occupy 8 bites. A total of 32 bites, that is, 4 bytes This is a high-quality image format, which is commonly used on computers. It is also the default format of a BitMap on the Android phone.
Bitmap. Config	RGB_565	Each pixel is stored on 2 bytes and only the RGB channels are encoded: Red is stored with 5 bits of precision (32 possible values ), Green is stored with 6 bits of precision (64 possible values) and blue Is stored with 5 bits of precision. This configuration can produce slight visual Artifacts depending on the configuration of the source. For instance, Without dithering, the result might show a greenish tint. To get better results dithering shoshould be applied. This configuration may be useful when using opaque bitmaps that do not require high color fidelity. A pixel occupies 2 bytes and has no alpha (A) value. Therefore, transparency and transparency are not supported, Red (R) values accounted for 5 bitesThe Green (G) value accounts for 6 bites. , The Blue (B) Value occupies 5 bites, a total of 16 bites, that is, 2 bytes. For images without transparent and translucent colors, the format of the image can achieve a comparative effect, Compared with ARGB_8888, it can also reduce the memory overhead by half. Therefore, it is a good choice. In addition, when we use android. content. res. Resources to obtain an image, it also uses this format to build BitMap This option is invalid since Android4.0. Even if it is set to this value, the system still usesARGB_8888

Note: ARGB refers to A color pattern in which A represents Alpha, R represents red, G Represents green, and B Represents blue. In fact, all visible colors are composed of red, green, and blue, therefore, red, green, and blue are also called primary colors. A R G B
Transparency, red, green, and blue.

Image Format (Bitmap. Config)	Memory usage	Memory usage of a 100*100 Image
ALPHA_8	Image length * Image Width	100*100 = 10000 bytes
ARGB_4444	Image length * Image Width * 2	100*100*2 = 20000 bytes
ARGB_8888	Image length * Image Width * 4	100*100*4 = 40000 bytes
RGB_565	Image length * Image Width * 2	100*100*2 = 20000 bytes

In addition, note that the image memory occupied here refers to the memory occupied in Navtive. Of course, the vast majority of memory used by BitMap is the memory. Because we can simply think of it as the memory occupied by BitMap. When a Bitmap object is not in use, we should first call recycle () and then set it to null. Although Bitmap can recycle the memory through BitmapFinalizer when it is recycled. However, calling recycle () is a good habit. Before Android4.0, Bitmap memory is allocated in the Native heap. Calling recycle () can immediately release Native memory. From Android4.0, Bitmap memory is allocated to the dalvik heap, that is, in the JAVA heap. Calling recycle () does not immediately release Native memory. However, calling recycle () is also a good habit.
The dumpsys meminfo command can be used to view the memory usage of a process. Of course, you can also use it to observe the changes in memory of a BitMap image created or destroyed, so as to infer the memory usage of the image. Example: Adb shell "Dumpsys Meminfo Com. lenovo. robin "running result. Applications Memory Usage (kB): Uptime: 18696550 Realtime: 18696541 ** MEMINFO in pid 7985 [com. lenovo. robin] **   Native   Dalvik Other Total Size: 4828 5379 N/ 10207 Allocated: 4073 2852 N/ 6925 Free: 10 2527 N/ 2537 (Pss ): 608 317 1603 2528 (shared dirty ): 2240 1896 6056 10192 (Priv dirty ): 548 36 1276 1860
  Objects Views: 0 ViewRoots: 0 AppContexts: 0 Activities: 0 Assets: 2 AssetManagers: 2 Local Binders: 5 Proxy Binders: 11 Death Recipients: 1 OpenSSL Sockets: 0
  SQL
  Heap: 0 MEMORY_USED: 0 PAGECACHE_OVERFLOW: 0 MALLOC_SIZE: 0