The problem

A few days ago, when I was working on a project, my colleague had a problem. The picture was very fuzzy when loading drawable, but it was clear when loading it by Glide. The picture was placed in the XHDPI folder, and the screen resolution was 1280×720. I later wrote a demo to verify it, and found that it would indeed be unclear, as follows:

Loading the local drawable is not clear

Android development pitfall: How much memory do your Bitmaps take up?
Android Application Performance Optimization Series views – Memory killers hidden in resource images

Resource image final size = Width x(device density/resource dimension density)x High (device density/resource dimension density)x 4

Device density refers to the density of screens with different resolutions. Resource dimension density refers to the density of drawable- MDpi, HDPI, xhdPI and XXHDpi, which also correspond to different densities. See the following table for details

folder Resource dimension density Corresponding resolution Device density
drawable-mdpi 160 320×480 160
drawable-hdpi 240 480×800 240
drawable-xhdpi 320 720×1280 320
drawable-xxhdpi 480 1080×1920 480
drawable-xxxdpi 640 1440 * 2560 560

The resource dimension density is specified by the system because the screen resolution is different from the screen size. The device density can be checked by using getResources().getDisplayMetrics().densitydpi. The device density printed by the TV I tested is 240, which is surprisingly not 320. Later in this article, I learned that this value was defined by the manufacturer, so the density of devices with different screen sizes will be different with the same resolution. I didn’t know this at the beginning, but I just thought that the screen with 1280×720 resolution should be placed in the XHDPI folder. It should not be compressed.

answer

Going back to our question, the image size is 411×195, the memory usage for native image and Glide loading is 179871 and 320580 respectively

Resource image final size = Width x(device density/resource dimension density)x High (device density/resource dimension density)x 4

Glide load can not be compressed, so memory usage =411x195x4=320580, and the print value. Calculate the local loading time width =411×240/320=308.25 rounded 308, height 195×240/320=146.25 rounded 146,308x146x4=179872, which is the same as the printed value. This problem is solved. At first, we did not know that the screen density is regulated by the manufacturer, not by the screen resolution, so even if we put the image into the drawable corresponding to the resolution, it may still be compressed.

conclusion

In Android, we recommend dp as the unit of length, which is a device-independent unit to look the same at different resolutions, or to look different at different screen sizes at the same resolution. Dp with 160 as 1 means 1dp means 1px on a 160-density screen, 1DP means 2px on a 320 screen, 1DP means 4px on a 640 screen, and so on. Let’s say you have two 5-inch screens, one with 1280×720 resolution and one with 1920×1080 resolution, and now you put an 80dpx80dp image on top. The image will eventually display 160pxx160px on the 1280 screen and 240pxx240px on the 1920 screen. So 160/720=0.222, 240/1080=0.222, so that the image has the same proportion on the screen, that is, you can put a few buttons on the low resolution, and a few buttons on the high resolution, and the position size looks the same.

But generally with the resolution of the screen are larger than the phone’s screen, mobile emissions two buttons may be about the same, but on TV if you put two buttons will only appear button is very big, very not harmonious, television may put down four or more buttons, this is the more so the greater the screen should be displayed. For example, the device density of the same 1920×1080 resolution is 480 for a mobile phone, and the device density of a TV may be only 240 (the TV I tested was only 213). According to the formula:

Resource image final size = width x(device density/resource dimension density)x high (device density/resource dimension density)x 4 100dpx20DP button on mobile phone actually 300pxX60px, but only 150pxX30px on TV, on 1080 mobile phone can only put 3 in a row at most, On TV, 1080/150=7 (regardless of the vertical and horizontal screens), but of course you can’t put 7. A button that takes up a third of the screen width on a phone looks good, but a button that takes up a third of the screen width on a TV looks less elegant.

thinking

The screen sizes of mobile phones and TVS are very different, but only for TVS. TVS of different sizes (40 inch, 55 inch, 65 inch, etc.) are made by different manufacturers, and the device densities are also very different. For example, the two TVS I tested are 1280×720, but the density of one is 213 and the density of the other is 240. But the specific screen size is the same 21 inches. If we continue to use dp and SP, we can know from the above formula: Actual width = width x device density/resource dimension density, resulting in width and height on the device density of 213 will be smaller than that on the device density of 240, so the final unit is PX, based on 1280×720 as the standard, and the actual pixel value is calculated on different resolutions of the screen. For example, the image design based on 1280×720 as the template is 100×100. It’s 150×150 on top of 1920×1080, so it fits perfectly on different screens