In-depth understanding of Android's density independence, and in-depth understanding of android

In-depth understanding of Android's density independence, and in-depth understanding of android
Preface

Android is a mobile operating system with few restrictions on hardware devices. Manufacturers can create almost any shape, size, and density of screen devices. The device can have a physical keyboard and button, or only a virtual keyboard and button. The customization of its equipment creates some trouble for software developers. First, how can application software ensure consistent user experience on a variety of devices? Secondly, how can application software take advantage of some devices with high-end hardware or unique features? Android has taken these considerations into consideration during its initial R & D, providing developers with tools to support various configuration devices and optimizing the user experience of devices with different configurations. These will be described below.

To make the application flexible and compatible with any configured devices, it is necessary to think carefully about the appropriate cross-configuration user experience. When creating an Android Application, the designer and developer must create a good UI interface that runs well on a small-sized mobile phone or a large-sized tablet. They also need to consider image resource optimization for high-density and low-density screens. This BLOG is centered on how Android supports screens of different density.

The basic design concept of Android is to ensure that the elements in the user interface have the same physical size, regardless of the screen density. Why? It's easy, regardless of the screen density, the physical size of a user's finger remains unchanged. Keys or elements that can be pressed should be rendered on any device in the same size as the physical size of the finger (larger than the fingerprint ). Text and letters should also be rendered to the same font size (readable) on different devices ).

 

Screen density is not equal to resolution

The pixel density on the screen is the ratio of resolution to display size. The pixel density can be measured by pixels per inch or dpi. The higher the dpi, the clearer the pixel. Simply put, the higher dpi, the more details are displayed per inch, rather than directly dependent on high resolution. For example, the resolution of Galaxy Nexus (diagonal 4.65 '') is 720x1280, and that of Nexus 7 (diagonal 7'') is 800x1280. the common misconception is that they have the same pixel density because they have almost the same resolution. However, the screen pixel density of Galaxy Nexus is about 316 dpi, and the screen pixel density of Nexus 7 is 216 dpi, which is far different. This is because they have the same resolution, but they have different Display sizes. Again, the pixel density of the screen is the ratio of the resolution to the display size. The two factors determine the pixel density of the screen together.

 

Density level

The image density of countless Android devices varies with each other. The image density ranges from DPI to DPI. To optimize images with different density, you must create images with different resolutions. However, trying to optimize all the image resources for all the images in the number of images will make it unimaginative and boring, and at the same time cause the application to become bloated, A simple method is not feasible. As a compromise, Android uses the density level concept to classify devices with a specified density range. In this way, the application only needs to optimize the image for each density level, instead of optimizing all possible pixel density. This makes the workload of designers and developers reasonable and prevents the expansion of application size. Of course, the cost is: the physical sizes of devices with different pixel density after rendering are different, which will be described later.

 

Therefore, how do designers and developers optimize image resources based on density blocks? First, you must determine the image size. For example, an icon tries to display the size of x0.5 on the screen. Next, create a maximum density supported by an image, or a scalable vector image. The best practice is to support the maximum density. Currently, xxhdpi is at DPI. at 480 dpi, A 0.5x0.5 image is converted to 240x240px. once the maximum density version of the graphic resource is created in 240x240px. then it can be scaled down appropriately in the density block version subsequently created, and each version uses the same file name. Google recommends that you do not create a tvdpi version in 213dpi because it is only required by a specific application and used by a small number of devices. Once all versions are created, they can be added to the drawable folder, and the resource identifier is used to tell the size of each density block in the Android system. Finally, let's take a look at the graphic resources in the xml layout layer and encode their names to generate them in the R file. The R file is a file that can reference all resources in the program. The Android system loads resources at runtime and tries its best to match the actual device configuration and Resource Identifier application. If the density version of any image resource is not included, Android will use another density version and reduce it to the appropriate size. Of course, it is not recommended that the Android system do this. Because the Andorid system does not have the image editing software to operate image resources more efficiently and accurately.

 

Dimension Unit

In Android, the user interface can be created in an xml file or implemented in code. There are several units that can be used to indicate the length and width of a form. They can be used on many elements to Set width, height, outer spacing, and inner spacing.

Px --Real pixels on the screen. This is a unit associated with the pixel density.PxThe physical size of the unit depends on the pixel density of the screen.

IN --The physical inch on the screen. This is a unit unrelated to the pixel density.InThe physical size of a unit is the same as that of a screen of any pixel density. IInUnit convertedPxThe Unit is determined by the pixel density of the screen.

Mm --The physical millimeters on the screen. This is a unit unrelated to the pixel density.MmThe physical size of a unit is the same as that of a screen of any pixel density. 25.4MmEqual to 1In.IMmUnit convertedPxThe Unit is determined by the pixel density of the screen.

Pt --Point, the unit of common font size on the screen. This is a unit unrelated to the pixel density.PtThe physical size of a unit is the same as that of a screen of any pixel density. 72PtEqual to 1In. IPtUnit convertedPxThe Unit is determined by the pixel density of the screen.

Dp-- The pixel density is unrelated to the pixel unit. This is a unit that is unrelated to the pixel density. However, IDpThe physical size of the unit is equal to that of myopia on different pixel density screens. About 160DpEqual to 1In. InDPConverted to 160DpIA proportional factor is associated with the device density level. IDpThe number of pixels equals is determined by the pixel density of the screen and the device's density level.

S P --An independent unit of pixels. Specify the size of text. This is a unit that is unrelated to the pixel density. However, I SpThe physical size of the unit is equal to that of myopia on different pixel density screens. In SpConverted to 160 DpiA proportional factor is associated with the device density level and the font size. I SpThe number of pixels equals is determined by the pixel density of the screen and the device's density level.

 

Amazing "dp"

As discussed earlier, "px" is not density independent and has different sizes on different devices. However, "in ", "mm" and "pt" are independent of each other. Of course, they have the same size on different devices. However, "dp" and "sp" are somewhat different from the rest. Although they are density independent, they have different sizes on different devices. Why? The answer is how "dp" and "sp" are computed as pixels. Android uses mdpi (160 dpi) as its standard password, where 1dp is 1px. In essence, "dp" can be considered as "px" on 160 dpi ". This is why 160 dp is converted to about 1 in. Therefore, the ratio between the device density level and the standard density (mdpi) is used to convert "dp" to "px ".

The reason why "dp" tends to be different physical sizes is that the same scaling factor is applied to the entire density bucket. This scaling factor is used to calculate the dpi of the density bucket, rather than the actual dpi of the device. When the dpi of a device is not exactly the same as the dpi of its density bucket, "dp" with the same number is converted to "px" with the same amount ". This will cause the "px" of the same number to be displayed on the screen with different degree of density and displayed in different sizes.

The above table shows how 100 dp converts to "px" On devices of different density ". 100 dp should be roughly converted to 0.625 in and perfectly converted to bucket sizes. However, when the dpi of a device is less than the dpi of a density bucket, the pixels of the device are physically larger, and the "dp" with the same number is rendered larger, and vice versa.

So this raises a question: why does "dp" allow this physical size change? Basically, android sacrifices some precision in physical size to maintain performance and display quality. Because android's density bucket ratio (0.75: 1.0: 1.5: 2.0: 3.0) is used to scale "dp" to "px ", this allows for minor "px" rounding and simple estimation. At the same time, because the scaling factor is proportional to the ratio of the density bucket, "dp" will display the image resources provided for various density in proportion. Finally, when scaling a graph row, it is best to keep close to an integer and a simple score, because the complex score will cause the image color transition to be abnormal and out of shape.

 

Define the boundaries of UI elements

Several special options are available when defining the length and width of a user interface element, just like the size unit.

Wrap_content-- This option will expand the boundary of the element to a sufficient size so that it can accommodate the content it contains (images, text, etc.). In essence, this option sets the element to the maximum size of its child element, and does not adjust the element size.

Match_parent(Fill_parent is out of date in API 8) -- this option will make the element adapt to the size of the parent element and use the maximum space of the parent element to reduce the spacing. Essentially, this enables the child element to be the maximum size allowed by the parent element and adjusts the element size when necessary.

Dimension unit-- This option sets the boundary of the element to the exact unit size, which has been discussed above. In essence, it sets the boundary of the element to the determined unit size, and adjusts the element size when necessary. Demo

To explain how all of this works together, it is necessary to create and test a sample application. For example, an image with a density of xhdpi or 320 dpi, 200X200 px is designed. For simplicity, name the image resource "android_logo ". With the density at 320 dpi, 200X200 px image resolution as the required physical size, the replaceable image size can be calculated.

Density isXhdpi (320 dpi ),200x200px Image

After calculating the size of the image with the desired density, they can be scaled down to the appropriate size in the maximum density version, as described above. Next, images of each density version can be placed in the "drawable" folder marked with the corresponding resource identifier. The Android system selects the best resource during running based on the configuration on the device.

Resource Directory with Identifier

Now, in order to present the possible ways to keep density independent, set the image to the same physical size using each density independent unit. Because "px" is not density independent, and "sp" is designed for text, ignore them.

 

 

Device example: xhdpi Bucket

By using a layout that contains the same images, these images use various size units to set the same physical size and compare how each size unit works. When running on a 320 dpi simulator, the image is displayed in exactly the same size, and each size unit is like this. This is expected because the dpi of the simulator fully matches the xhdpi (320 dpi) density level. However, when running on the Galaxy Nexus with the same xhdpi density level, the image size may change.

 320 dpi Simulator

Galaxy Nexus

 

After checking, it is obvious that the size of the image set with "wrap_content" and "dp" is matched, and "in ", "mm" and "pt" also match. But yes, the two groups do not match each other. What happened? As discussed earlier, "wrap_content" and "dp" Use the density bucket ratio to appropriately convert their dimensions. Therefore, the image size is calculated to 200x200 px. However, the actual screen density of Galaxy Nexus is not 320 dpi, which is 315.3 xdpi and 318.7 ydpi. Because the actual density is lower than the xhdpi density of 320 dpi, the physical size of pixels on the actual device is larger than the expected 0.625 in.

When the analysis uses "in", "mm", and "pt" to set the image size, it is noted that each image is converted to 197.1x199.2 px. As discussed earlier, "in", "mm", and "pt" both use the density of the actual device to convert their sizes to pixels. Because the actual density of Galaxy Nexus is lower than the xhdpi density of 320 dpi, fewer pixels need to be converted to 0.625x0.625 in, so that the image is reduced.

When comparing the displayed images, it is obvious that the physical size precision of the images set with "wrap_content" and "dp" is low, but their image quality is "in ", "mm" and "pt" are better.

"Wrap_content" and "dp" (left) are not scaled ). YesZoom"In", "mm" and "pt""(Right)

 

 

Device example: hdpi Bucket

Next, when running on a DPI simulator, the image shows each size unit in the same size. Repeat, we expect that this is because the dpi of the simulator exactly matches the hdpi density bucket in the dpi file ). But as before, when running on an hdpi device, there was an incredible change in the image size.

 

 

240dpi simulator Screen

 

 

 

HTC Droid Incredible

As usual, HTC Droid Incredible displays 150x150 px images, which are set with "wrap_content" and "dp. Because the actual screen density of Droid Incredible is 254x254 dpi, which is greater than the hdpi density of 240 dpi, this means that the pixels on the screen are smaller than the corresponding pixel size of dpi density. This causes the image size of 150x150 px to be smaller than the base size of 0.625 in. The image set with "in", "mm" and "pt" is displayed as 158.8x158.8px, because more pixels need to be converted to 0.625x0.625 in, so that the image will be enlarged.

Just like on Galaxy Nexus, images with "wrap_content" and "dp" are physically less precise, but their image quality is "in ", "mm" and "pt" are better.

"Wrap_content" and "dp" (left) are not scaled ). YesZoom"In", "mm" and "pt""(Right)

You can find all the source code of the demo on GitHub or obtain it from the attachment below.

 

Size unit best practices

Px-Density independence is not maintained. It should never be needed.

In/mm/pt-Maintaining density independence, but calculating the exact amount of pixels will reduce the user experience, and cause the color transition to be unnatural and out-of-the-box. If the accuracy of the size is required and any deviation is unacceptable, it is necessary to select in/mm/pt. When the exact distance is required, it is also useful to set the distance between elements in/mm/pt.

Dp-Keep the density independent and keep the best image quality, but the physical size should be at the cost of a small deviation. Because it uses the density bucket ratio to calculate the size, it appropriately provides accurate size and image resources. This is the recommended unit of dimensions used to set the boundary between elements or the distance between them.

Sp-Maintain density independence and font quality, but the physical size should be at the cost of a small deviation. This is the recommended size unit and is only used to set the font size, because it needs to consider the density and user's text size preferences.

 

 

Summary

In general, the key points to maintaining density independence are as follows:

• Determine each image resource determine the physical size required to present the resource
• Vector image resources or original image resources with a designed size greater than the maximum density Bucket
• Create a specific density version for each density bucket, and put them in the "drawable" Resource Directory identified by the appropriate identifier
• When setting the image boundary, use "wrap_content" to get the best display effect, use "match_parent" to fill the entire display area, or use "dp" to set a fixed size.
• Use "dp" to get the best display effect when setting the distance in the layout. To use precise dimensions, use "in", "mm", or "pt" only ". Never use "px" here"

With the understanding of how Android handles display at different density screens, it will make it easier to design and develop the best applications on a display at any density.

 

Understanding Density Independence in Android
Use edge density functions to determine independence

First, evaluate the value of
On the plane, calculate the point (equal to 1) for f (x, y). Naturally, the value of parameter A can be obtained.

When judging independence
Edge density
Then whether the product of the two edge density is equal to the original joint Density
If they are equal, they are independent.

Do you understand?
Can be followed up?

Set the density function of the binary random variable (x, y) to f (x, y) = 2 0 <x <1, x <y <1x and y covariance to determine the independence of xy.

F (x, y) = 2 0 <x <1, x <y <1
Draw a graph. the area where two-dimensional random variables are located is a triangle formed by y = x, x = 0, and y = 1.
FX (x) = hour (-∞ → + ∞) f (x, y) dy
= 2 hour (x → 1) dy
= 2-2x
FY (y) = minus (-∞ → + ∞) f (x, y) dx
= 2 rows (0 → y) dx
= 2y
EXY = linearregression (-∞ → + ∞) xyf (x, y) dxdy
= 2 rows (0 → 1) dx round (x → 1) xydy
= 1/4
EX = forward (0 → 1) xfX (x) dx = 1/3
EY = round (0 → 1) yfY (y) dy = 2/3
Cov (X, Y) = EXY-EXEY = 1/4-2/9 = 1/36
∵ EXY =exey (or f (x, y) =fx (x) · fY (y ))
Random Variables X and Y are not independent.