The key to optimizing Bitmap memory usage: image resolution, folder storage and loading strategy

The key to optimizing Bitmap memory usage: image resolution, folder storage and loading strategy

Memory usage calculation formula for images

  1. Image resolution = a*b For example: 180*120
  2. The dpi corresponding to the folder where the pictures are stored, for example, hdpi is 240 and xhdpi is 320dpi, which we locate as the variable inDensity
  3. The dpi of the mobile device. This value depends on each mobile phone. For example, my Xiaomi is 440dpi (this value is not the sum of the squares of the mobile phone resolution, the square root, and then divided by the size of the mobile phone. The display resolution depends on the manufacturer's algorithm). We define it as targetDensity
  4. The image scaling ratio is scale = targetDensity/inDensity. The memory size of each pixel, pointMemory, depends on the color depth. For example, the color depth of argb8888 is 32 bits = 4 bytes.
  5. Image memory occupied = (image width a*scale+0.5)*(image height b*scale+0.5)*pointMemory

Does the same image occupy the same amount of memory when displayed on mobile phones with different resolutions?

Inconsistent. Because the inDensity value is the same, but the targetDensity value is not, the image scaling is different, and the memory usage is naturally different.

When loading the same picture from folders with different resolutions on the same mobile device, will the memory usage be the same?

Although the inDensity values ​​are different at different resolutions, as long as the designer cuts the image according to the specification, the aspect ratio between images of different resolutions = the ratio between inDensity. Therefore, when images of different resolutions are displayed on the same device, the final values ​​after the image width and height are scaled are consistent, and the memory is also consistent.

Does the size of the ImageView control affect the memory usage?

No. Because through the src attribute, when we get the corresponding drawable, we set the density to 0. When the density is 0, the width and height of the image will not be scaled, so the memory size will not change. Memory size = original image width * original image height * color depth

For the same resource id, do the bitmap created by BitmapFactory and the src set by ImageView in the xml file occupy the same amount of memory?

There will be inconsistent scenes. If inDensity and targetDensity are inconsistent, the bitmap created by BitmapFactory will be scaled, resulting in memory size != original image width * original image height * color depth. However, for images set by xml through the src attribute, because density=0, the image will not be scaled at all, and the memory size = original image width * original image height * color depth

Will setting the image size in a third-party image loading framework affect the memory usage of the image?

Yes. The essence of the operation of setting the image size in the third-party framework is to modify the width and height of the image. When the width and height of the image change, the memory size occupied will naturally change.

Android image adaptation rules

First, find the drawable folder corresponding to the dpi of the mobile device. If it cannot be found in the current folder, the strategy is to reduce the image first. So it will then look for the image in the high-resolution folder. If it is not found in the high-resolution folder, it will then search in the low-resolution folder.

For example: the dpi of a mobile device is 320 (xhdpi). If you cannot find the corresponding image in the drawable-xhdpi file, then search in the drawable-xxhdpi and drawable-xxxhdpi folders. If you still cannot find it, search in the drawable-hdpi and drawable-mdpi folders.

Why is it recommended that images be placed in folders with the correct resolution?

Only analyze the resolution of mobile devices with xxhdpi, and think about other resolutions yourself, targetDensity=480

The resolution is xxhdpi, put it in the correct drawable-xxhdpi folder. inDensity=480, targetDensity=480, image scaling scale=1

The image with resolution of xxhdpi is placed in the wrong drawable-xhdpi folder. inDensity=320, targetDensity=480, image scaling ratio scale=1.5

The memory size has changed from width*height*pointMemory to (width*1.5+0.5)*(height*1.5+0.5)*pointMemory, resulting in a significant increase in the occupied memory.

On a mobile device with a dpi of 320, if I load a picture in drawable-xxxhdpi, will the memory occupied be the same as that of a picture in drawable-xhdpi?

Of course, when loading high-resolution images, the images will be scaled down, and the image size will be scaled to the same as other resolutions, so the memory size occupied is the same

Since the same image in different resolution directories is loaded on our mobile phone, the memory size occupied is the same, so why do we need to create multiple drawable directories? Wouldn't it be possible to reduce the package size by directly using drawable-xxxhdpi?

There is a problem involved here, that is, in the XML file, we use the ImageView control to directly reference the image resource through the src attribute.

When referencing image resources through XML files, the memory size occupied is as follows: Because through the src attribute, when we obtain the corresponding drawable, we set the density to 0. When the density is 0, the width and height of the image will not be scaled, so the memory size will not change. Memory size = original image width * original image height * color depth

So if I have a 320 phone, I load an image in xhdpi, assuming the image is 18*12 argb8888, then the memory usage is 18*12*4, but if I only have images in xxxhdpi, assuming the image is 36*24, then the memory usage is 36*24*4, which is 4 times the memory usage. The images in our drawable directory are almost all used for XML reference images, and are rarely created with bitmapFactory, so it is best to put images of corresponding resolutions in each folder.

<<:  Difference between FragmentPagerAdapter and FragmentStatePagerAdapter

>>:  The basic principles and implementation details of calling APP from the Web in Android

Recommend

Xiaohongshu Food Popularity Article Methodology

The article starts with analyzing the hot food ar...

Live streaming and street stall economy

Operator thinking is a complete thinking framewor...

Liu Tong talks about survival in the workplace: 20 heartfelt answers to key questions

Course Catalog: 01 【Editorial】Resolve workplace d...

In-depth analysis and market report on overseas influencer marketing

This report is produced by SocialBook, an America...

How to list on Android App Market in 2018

The user activity rate of domestic app stores has...

Fighting Cock: Once the God of War, Now the Pickled Chicken Feet

Animal fighting seems to have accompanied every s...

From brainstorming to implementation, how should we operate and promote events?

A senior who works in operations said that event ...

Why not choose one year of training instead of four years of university?

[[142050]] I am a college student. I am currently...