Research and analysis on the relationship between image size, memory footprint and Drawable folder in Android

From the previous article "Android screen adaptation to the full guide" after writing, often a friend asked me this question: "Can an app only provide a set of graphs to adapt to all the resolution?" "I think it is necessary to write an article to study the problem, so there is this article."

• • Research content
  • Research methods
  • Test environment
  • Research process
  • Results analysis
  • Conclusion
  • Another difficult question to explain

Research content

This article focuses on the following scenarios: the same picture, placed in a different drawable folder, running on the same device, the size of the picture and the memory footprint of the impact.

Research methods

• Control variable method
• Analytical method

Test environment

Tested with a hammer T1 cell phone (1080*1960,xxhdpi)

For memory viewing, use the AS-comes memory viewing tool.

The image size is obtained using the following code

 Private voidPrintbitmapsize (ImageView ImageView) {drawable drawable=ImageView.Getdrawable ();if(drawable!= NULL) {bitmapdrawable bitmapdrawable=(bitmapdrawable) drawable; Bitmap Bitmap=Bitmapdrawable.Getbitmap ();Log.DTAG,"width =" +Bitmap.GetWidth ()+ "height =" +Bitmap.GetHeight ()); }Else{Log.DTAG,"drawable is null!"); }    }

Research process

The following will give the test process, then analyze and summarize

The following test uses a PNG image with a 720*1280 resolution of 32-bit color, which takes up a hard disk size of 77.11k

The test engineering code is given below, very simple

Main interface

 Public  class mainactivity extends appcompatactivity {    Private Static FinalString TAG ="Mainactivity";PrivateImageView 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(BooleanHasfocus) {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

<?xml version= "1.0" encoding= "Utf-8"?><relativelayout xmlns:android="Http://schemas.android.com/apk/res/android" android:layout_width="Match_parent"android:layout_height="Match_parent" >            <ImageViewandroid:id= "@+id/img"android:layout_width=" Wrap_content "android:layout_height=" wrap_content " />                        </relativelayout>

App takes up 8.31M of memory without setting a picture

Here is the test section

Put the picture in the Drawable folder, the image size is 2160*3840, the memory occupies 39.88M

Put the picture in the Drawable folder, the image size is 2160 * 3840, memory consumption 39.88M

Put the picture in the drawable-mdpi folder, the image size is 2160 * 3840, memory consumption 39.84M

Put the picture in the drawable-hdpi folder, the image size is 1440 * 2560, memory consumption 22.26M

Put the picture in the drawable-xhdpi folder, the image size is 1080 * 1920, memory consumption 16.11M

Put the picture in the drawable-xxhdpi folder, the image size is 720 * 1280, memory consumption 11.86M

Put the picture in the drawable-xxxhdpi folder, the image size is 540 * 960, memory consumption 10.29M

Results analysis

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

1. The same picture, placed in different directories, will generate different sizes of bitmap
2. The larger the length and width of the bitmap, the greater the memory
3. The size that the picture occupies on the hard disk is completely different from the size in memory

I'll explain some of the above questions.

We take the picture below the Drawable folder as an example, after loading into memory, the 2160*3840 size of bitmap takes up memory as

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

So the drawable folder of the app memory consumption = raw memory 8.31m+ image memory 31.64m= 39.95M, and the actual memory consumption 39.88M there is 0.1755% error, within the error range.

A simple explanation of the above calculation formula, long * Width is the total number of pixels of the picture, multiplied by 4 because a pixel occupies a, R, G, b four channels, each channel occupies 8 bits, so the description of a pixel requires 32 bits is 4 bytes.

A color channel requires a 8-bit description, 2^8=256, so there are 256 states for each color channel. If the color map is converted to grayscale, there are also 256 transitions from white to black.

Of course, not all the format of the picture each pixel occupies 4 bytes, which is related to the image set at the time of loading bitmap.config, the default is Bitmap.Config.ARGB_8888, the other types are as follows:

• Bitmap.Config.ALPHA_8 this time the image has ALPHA value, no RGB value,
  11 Pixels takes one byte
• Bitmap.Config.ARGB_4444 a pixel occupies 2 bytes, an alpha (a) value, a Red (R) value, a Green (G) value, and a Blue (B) value of 4 bites a total of 16bites, or 2 bytes
• Bitmap.Config.ARGB_8888 a pixel occupies 4 bytes, an alpha (a) value, a Red (R) value, a Green (G) value, and a Blue (B) value of 8 bites each, a total of 32bites, or 4 bytes. This is a high-quality picture format that is commonly used on computers. It is also the default format for a bitmap on Android phones.
• Bitmap.Config.RGB_565 a pixel occupies 2 bytes, has no alpha (a) value, that is, transparent and translucent, Red (R) values are 5 bites, Green (G) is 6 bites, and Blue (B) is 5 bites, A total of 16bites, or 2 bytes. For images that do not have transparent and translucent colors, the image of this format can be compared to the rendering effect, and can reduce the memory cost by half compared to argb_8888. So it's a good choice.

So why the storage on the hard disk only need 77.11k, put in memory to need more than 30 m?

Because it's not the same thing at all

The image files stored on the hard disk will be compressed according to their compression rules, such as JPEG lossy compressed image format, most often using variable word length encoded Havermann encoding, will use the Havermann tree, which is the optimal binary tree, according to the frequency of some data to encode data segments, thereby reducing the size of the hard disk.

For example, "10111" This sequence in the image of the binary data in the largest probability, then we can use "01" to replace this piece of data, the original 5-bit data, with 2 bits can be expressed, this is the compression rate of 60%. Of course, this is just an analogy, in the actual operation need to consider the "different prefix principle" and other coding principles.

And if the image is read into memory is not the same, because we need every pixel can be displayed on the screen, so we will load each pixel into memory, not the same pixel compression or replacement, so you should also be able to understand the earlier mentioned bitmap memory size calculation formula is the origin.

Speaking of which, in fact, the latter two conclusions have been explained clearly, then why "the same picture, placed in different directories, will generate different sizes of bitmap"?

If you really understand the article I wrote earlier, then this question should not be considered a problem.

My test equipment for the hammer t1,1080*1960,xxhdpi, so that if you put this in xxhdpi, the image should not be indented, that is, the original size, so we get in front of the drawable-xxhdpi folder, the image size is 720 * 1280 is fully understandable, is the size of the picture itself.

When the picture is placed in the drawable-hdpi, the image size is 1440 * 2560, the length of the width becomes twice times the original, this is due to the multiple relationship between different resolutions, to a picture

We can clearly see that xxhdpi is twice times the size of hdpi, so if placed in a drawable folder alone, the phone automatically shrinks the image based on the current screen density.

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

As for why in the previous test, drawable and drawable-mdpi are the same size because drawable-mdpi is the default pixel density of the system, and other pixel densities are based on it, and when the picture is present only in drawable, if the picture is used, Then the drawable-mdpi is scaled down according to the scale of the reduction.

Conclusion

From the above test we can draw the following conclusions:

1. When the picture is placed in a different drawable folder, and only this one picture, the running device will be based on its own screen density, the picture is shrunk, scaled to match the rules on the previous diagram
2. The size of the picture file is not the same size as in memory, the actual footprint in memory is related to image resolution, pixel display parameters

So, using a set of UI in an app should theoretically be fine, but be aware

• It is best to use a higher resolution transduction, and put it in the correct drawable folder, such as the xxhdpi resolution to be cut, placed in drawable-xxhdpi
• For pictures that can use the. 9 format, it's best to use. 9 to reduce resource size
• If there are conditions, it is best to provide multiple sets of UI transduction. If only a set of graphs, the system needs to compress the picture, will be a large number of operations, affecting the performance of the device. At the same time, in some cases, the system image compression may appear jagged, resulting in the loss of information

Think about what would happen if you put a picture that should have been placed in the drawable-xxhdpi in the Drawable folder?

On the XXHDPI device, the image will be magnified 3 times times, the image memory will become 9 times times the original!

Another difficult question to explain

I also try to put the above picture in the Drawable-xxhdpi folder to observe the performance of different screen density devices

xxhdpi device (T1), image size 720 * 1280, memory consumption = 11.86m-8.31m= 3.55M

xxhdpi device (N5), image size 720 * 1280, memory consumption = 20.19m-16.82m = 3.37M

xxhdpi device (Meizu m351), image size 720 * 1280, memory consumption = 20.17m-17.84m = 2.33M

XHDPI device (Huawei g716-l070) memory footprint = 7.72m-2.66m = 5.06M

HDPI device (Lenovo A360E), image size 360 * 640, memory consumption = 2.83m-2.96m = -0.7m

hdpi device (Cool 7269), image size 320 * 568, memory consumption = 6.85m-2.78m = 4.07M

And then I get messy, what the hell is this? In addition to my big hammer and native N5 match the image memory formula, what other devices are! Lenovo phone is still negative! However, I have a similar effect on the simulator, this test should be the same situation as above, the specific reason is not only.

You can tell me if you know the reason, thank you.

Respect the original, reproduced please specify: from Kaizico (http://blog.csdn.net/zhaokaiqiang1992) infringement must investigate!

Follow my Weibo to get more content

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Research and analysis on the relationship between image size, memory footprint and Drawable folder in Android