Bitmap things: memory usage calculation and loading considerations

I was originally working on TV applications, but because the company was going to release a mobile phone and was short of staff, they assigned me to support it. Who says I am Lei Feng? One of the functions I worked on was to process the application icons in the mobile phone. The processing was nothing more than beautification, re-combination and cropping with the baseboard, which used a lot of knowledge about Bitmap. I had always wanted to write some blogs about Bitmap, and this happened to be an opportunity, so the series of blogs about Bitmap was born. In this series, I will publish some knowledge I learned about Bitmap for your reference and communication.

In mobile phones, pictures generally refer to Bitmap pictures. Why do we say Bitmap? Because when developing applications, we will use some pictures to express UI, and users also like to look at pictures. It is too slow and not intuitive to get information by looking at text. If the art design is good, you can basically know what you want to express by looking at the pictures without looking at the text content. For example, all shopping websites will edit a lot of pictures of products to present to users. This shows that pictures are common and important in applications. As long as we talk about pictures, we can't leave the topic of how to avoid OOM, because OOM is easy to appear when processing many pictures, so learning picture processing is particularly important. Let us learn the relevant knowledge of pictures step by step.

Memory usage calculation of Bitmap images:
When a Bitmap image is loaded into memory, it is calculated as: width * height * number of pixels. You can think of the image as a matrix consisting of width rows and height columns. Each matrix element represents a pixel, and each pixel is an integer multiple of 1 byte. The larger the data, the richer the color represented and the higher the display quality of the image. There is an enumeration class Config in Bitmap that is used to configure the compression format of the image, which represents how much data is used to store each pixel. The larger the value, the more color information can be stored, and the richer it is, and the better the display effect. Config.ALPHA_8 is 1 byte, Config.RGB_565 and Config.ARGB_4444 are both 2 bytes. Config.RGB_565 has no Alpha value, so it is mostly used to configure images without transparency. Config.ARGB_8888 is 4 bytes, and general images are configured in this way. The following is the code to get the configuration:

 static   int getBytesPerPixel(Config config) {
 if (config == Config.ARGB_8888) {
 return   4 ;
 } else   if (config == Config.RGB_565) {
 return   2 ;
 } else   if (config == Config.ARGB_4444) {
 return   2 ;
 } else   if (config == Config.ALPHA_8) {
 return   1 ;
 }
 return   1 ;
 }

What you need to pay attention to when using pictures:

1. Problems with the Android system itself. The Android system allocates a certain amount of memory space to each application. The amount depends on the manufacturer and model. The value can be obtained through the Runtime class. Runtime.getRuntime() gets the instance, and then the maxMemory() method is used to get the maximum memory that the system can allocate to the APP. totalMemory() gets the size of the memory heap space currently allocated to the APP, and freeMemory() gets the current available memory. When it is exhausted, it will automatically expand, but it will not exceed maxMemory. The figure below shows the minimum memory allocated at different resolutions and different dpis provided by the Google official website;

2. How big a photo is needed. In fact, many pictures do not need to be completely loaded into the memory when they are displayed on the phone. For example, if I took a photo with my phone camera that is 4208*3120, it will take up 52M of memory when loaded into the memory. This is terrible. Two photos will almost use up your app's memory. In general, you need to process the pictures you need to load. This processing mainly reduces the size of the picture and reduces the resolution. For example, if your control display is 100*100 in size, you need to reduce the picture to 100*100.

3. Release memory in time. Before Android 2.3.3 (API level 10), Bitmap pixel data and Bitmap objects are stored separately. Pixel data is stored in native memory, and objects are stored in Dalvik heap. Pixel data in native memory is not released in a predictable way, which may cause the application to temporarily exceed its memory limit and crash. Therefore, before Android 2.3.3 (API 10), you must call the recycle() method to release memory to avoid OOM. Of course, the premise is to make sure that the bitmap is no longer used, otherwise "Canvas: trying to use a recycled bitmap" will appear. After Android 3.0 (API 11), Bitmap pixel data and Bitmap objects are stored in the Dalvik heap together, so we don't need to manually call recycle() to release the Bitmap object. The release of memory is left to the garbage collector.

The above is some basic knowledge of learning Bitmap and the matters needing attention when loading it into the mobile phone memory. In the next blog, I will write about how to load Bitmap better, how to save memory, and how to be efficient. Thank you for your browsing. If you have any questions or if you have any questions, please leave a message or add the coder_online public account to communicate with me faster. There are not only my articles here, but also my friends' articles and various technical sharing. You may as well take a look. We look forward to your arrival. You can also scan the QR code below and find us in a second. . . . . . .