Research and Analysis on the Relationship between image size, memory usage, and drawable folder in Android

Research and Analysis on the Relationship between image size, memory usage, and drawable folder in Android

After reading the previous article "Android screen adaptation Guide", some friends often asked me this question: "Can an App provide only one set of cut charts to adapt to all resolutions ?" I think it is necessary to write an article to study this problem.

Research Content research methods testing environment research process results analysis conclusions another difficult to explain Problem

Study content

This article mainly discusses the following scenarios: the same image is placed in different drawable folders and runs on the same device. What is the impact on the image size and memory usage.

Research Method control variable method analysis method test environment

Use a hammer T1 mobile phone (1080*1960, xxhdpi) for testing

For memory viewing, use the AS built-in memory viewing tool.

Use the following code to obtain the image size:

 private void printBitmapSize(ImageView imageView) {        Drawable drawable = imageView.getDrawable();        if (drawable != null) {            BitmapDrawable bitmapDrawable = (BitmapDrawable) drawable;            Bitmap bitmap = bitmapDrawable.getBitmap();            Log.d(TAG,  width =  + bitmap.getWidth() +  height =  + bitmap.getHeight());        } else {            Log.d(TAG, Drawable is null !);        }    }

Study Process

The following describes the testing process, and then analyzes and summarizes it.

The following test uses a 720*1280 resolution png Image in 32-bit color, occupying a hard disk size of 77.11 kb.

The test project code is provided below, which is very simple.

Main Interface

public class MainActivity extends AppCompatActivity {    private static final String TAG = MainActivity;    private ImageView img;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        img = (ImageView) findViewById(R.id.img);    }    @Override    public void onWindowFocusChanged(boolean hasFocus) {        super.onWindowFocusChanged(hasFocus);        printBitmapSize(img);    }    private void printBitmapSize(ImageView imageView) {        Drawable drawable = imageView.getDrawable();        if (drawable != null) {            BitmapDrawable bitmapDrawable = (BitmapDrawable) drawable;            Bitmap bitmap = bitmapDrawable.getBitmap();            Log.d(TAG,  width =  + bitmap.getWidth() +  height =  + bitmap.getHeight());        } else {            Log.d(TAG, Drawable is null !);        }    }}

Layout Interface

If no image is set, the App occupies 8.31 MB of memory.

The test section is as follows:

Place the image in the drawable folder. The image size is 2160*3840, and the memory usage is 39.88 MB.

Place the image in the drawable-mdpi folder. The image size is 2160*3840, and the memory usage is 39.84 MB.

Place the image in the drawable-hdpi folder. The image size is 1440*2560, and the memory usage is 22.26 MB.

Place the image in the drawable-xhdpi folder. The image size is 1080*1920, and the memory usage is 16.11 MB.

Place the image in the drawable-xxhdpi folder. The image size is 720*1280, and the memory usage is 11.86 MB.

Place the image in the drawable-xxxhdpi folder. The image size is 540*960, and the memory usage is 10.29 MB.

Result Analysis

From the above test results, we can draw the following conclusions:

Put the same image in different directories, the larger the length and width of Bitmap of different sizes will be generated, the larger the memory occupied by the image on the hard disk, the size used in the memory is completely different.

I will explain the above questions one by one.

Take the image placed in the drawable folder as an example. After loading to the memory, the memory occupied by Bitmap of 2160*3840 is

2160*3840*4 = 3317,7600 byte = 3, 2400kb = 31.640625 M

Therefore, the App memory usage in the drawable folder = original memory 8.31 M + image memory 31.64 M = 39.95 M, which is 0.1755% different from the actual memory usage 39.88M and is within the error range.

First, let's briefly explain the formula above. The length * width is the total number of pixels in the image. multiplied by 4 is because A pixel occupies four channels: A, R, G, and B, each channel occupies 8 bits, so the description of a pixel requires 32 bits, that is, 4 bytes.

A color channel requires 8-bit description, 2 ^ 8 = 256, so each color channel has 256 states. If you convert a color image to a grayscale image, there are also 256 states to split the Transition Colors from white to black.

Of course, not all formats of images occupy 4 bytes per pixel, which is consistent with the Bitmap set during image loading. the default value is Bitmap. config. ARGB_8888. Other types are as follows:

Bitmap. Config. ALPHA_8 the image has only the alpha value and no RGB value,
One pixel occupies one byte Bitmap. config. ARGB_4444 A pixel occupies 2 bytes, the alpha (A) value, the Red (R) value, the Green (G) value, and the Blue (B) value each occupy 16 bites in total, that is, two bytes of Bitmap. config. ARGB_8888 A pixel occupies 4 bytes, alpha (A) value, Red (R) value, Green (G) value, Blue (B) value each occupies 8 bites, A total of 32 bites, 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 A pixel occupies 2 bytes without an alpha (A) value, that is, transparency and translucent are not supported. Red (R) values occupy 5 bites, and Green (G) the value occupies 6 bites, and the Blue (B) Value occupies 5 bites. A total of 16 bites are 2 bytes. For images without transparent and translucent colors, this format can achieve a relatively good effect, and reduce the memory overhead by half compared with ARGB_8888. Therefore, it is a good choice.

So why does it take 77.11 kb to store data on the hard disk and more than 30 mb to store data in the memory?

This is not the same thing ~

Image files stored on hard disks are compressed according to their respective compression rules. For example, Jpeg, A lossy compression image format, most often uses the hafman encoding with variable-length encoding, the Haffman tree, or the optimal binary tree, is used to encode data segments based on the frequency of data occurrence, thus reducing the disk size occupied.

For example, if the sequence "10111" has the highest probability of appearing in the binary data of an image, we can use "01" to replace this data segment. The original five-bit data, it can be expressed in 2 bits, which means the compression rate is 60%. Of course, this is just an example. In actual operations, we need to consider the basic encoding principles such as the "different prefix principle.

However, it would be different if we read the image to the memory, because we need to display every pixel on the screen, so we will load every pixel into the memory, it does not compress or replace the same pixels. Therefore, you should be able to understand the formula for calculating the memory size occupied by Bitmap.

Speaking of this, the last two conclusions have already been explained clearly. Why does "a Bitmap of different sizes be generated for the same image in different directories?

If you really understand the article I wrote earlier, it should not be a problem.

My testing device is a hammer T1, 1080*1960, xxhdpi, So if you place this in xxhdpi, the image will not be scaled down, that is, the original size, therefore, the figure size in the drawable-xxhdpi folder is 720*1280, which is the size of the image.

When an image is placed in drawable-hdpi, the image size is 1440*2560, and the length and width change to twice the original size. This is due to the multiple relationship between different resolutions.

We can see that xxhdpi is twice that of hdpi, so if it is placed separately in a drawable folder, the mobile phone will automatically scale down the image based on the current screen density.

For example, when an image is placed in xxxhdpi, the image length is 720 * (3/4) = 540, and the image width is 1280 * (3/4) on the xxhdpi device) = 960, which is exactly the same as the above test results.

In the previous test, drawable and drawable-mdpi are of the same size, because drawable-mdpi is the default pixel density of the system, and other pixel density is based on it, if an image exists only in drawable, It is scaled down according to the scale-in ratio of drawable-mdpi.

Conclusion

From the test above, we can draw the following conclusions:

When an image is placed in different drawable folders and only this image is available, the running device compresses the image according to its screen density, the scale-down ratio conforms to the rules shown in the preceding figure. The size of the image file does not matter the size occupied in the memory. The actual memory size is related to the image resolution and pixel display parameters.

Therefore, using a set of UI in an App is theoretically normal, but pay attention

It is best to use a high-resolution cut graph and place it in the correct drawable folder. For example, you can use a cut Graph Based on the resolution of xxhdpi and place it in drawable-xxhdpi. 9 Format Image, preferably. 9. Reduce the resource size. If there are conditions, it is best to provide multiple sets of UI cut diagrams. If there is only one set of cut images, the system needs to compress the images and perform a lot of operations, affecting the device performance. At the same time, in some cases, the system may compress the image, resulting in the loss of information. If there are multiple sets of cut images, it is best not to directly use tools to scale down according to the proportion, in this way, small icons will lose some details. Of course, this part is done by the artist, so that she can refer to this article and use the new features of PS CS6 to keep the ICON details perfect.

Think about it. What will happen if I put an image that should have been placed in drawable-xxhdpi IN THE drawable folder?

On the xxhdpi device, the image size is increased by 3 times, and the image memory usage is changed to 9 times!

Another hard-to-explain question

I also tried to place the above image in the drawable-xxhdpi folder and observe the performance of devices with different screen density.

Xxhdpi device (T1), image size: 720*1280, memory usage = 11.86 M-8.31 M = 3.55 M

Xxhdpi device (N5), the image size is 720*1280, memory usage = 20.19 M-16.82 M = 3.37 M

Xxhdpi device (meizu m351), the image size is 720*1280, memory usage = 20.17 M-17.84 M = 2.33 M

Xhdpi device (Huawei g716-l070) memory usage = 7.72 M-2.66 M = 5.06 M

Hdpi device (Lenovo A360e), the image size is 360*640, memory usage = 2.83 M-2.96 M =-0.7 M

Hdpi device (cool 7269), image size: 320*568, memory usage = 6.85 M-2.78 M = 4.07 M

Then I am confused. What is this! Apart from the sledgehammer and N5, the native meets the image memory calculation formula. What are the other devices! Lenovo mobile phone is still negative! However, I also got a similar result on the simulator. This test should be the same as the above, for no specific reason.

If you know the reason, please let me know. Thank you.