Gain an in-depth understanding of Android's density independence

Objective

Android is a mobile operating system that has few restrictions on hardware devices. Manufacturers can create almost any shape, size and density of the screen equipment. Devices can have physical keyboards and buttons or only virtual keyboards and buttons. Due to the freedom of its equipment, the software developers have made some trouble. First, how does application software guarantee a consistent user experience across a wide variety of devices? Second, how does application software take advantage of devices that have high-end hardware or unique features? This was considered by Android at the time of development, providing developers with tools to support a variety of configured devices, optimizing the user experience for different configured devices, as described below.

For application flexibility and compatibility with any configured device, it is necessary to think carefully about the appropriate cross-configuration user experience. When creating an Android app, designers and developers have to create a UI that works well on small-sized phones or on large-sized tablets. They also have to consider the image resources optimized for high density and low density screens. The center of this blog is how Android supports different densities of screens.

Android's basic design idea is to ensure that the elements in the user interface have the same physical size, regardless of the screen density. Why is it? Very simply, no matter what the screen density, the physical size of a user's finger is constant. Keys or elements that can be pressed on any device should render the size of the physical size of the sing woo finger (a little larger than the finger). Text and letters should also be rendered to the same font size (readable) on different devices.

Screen density is not equal to resolution

Screen pixel density is the ratio of resolution to display size, which can be measured in pixels per inch or dpi. The higher the DPI, the clearer the smaller each pixel will become. To put it simply, the higher the DPI means the more detail is displayed per inch, rather than directly depending on the high resolution. For example, the Galaxy Nexus (Diagonal 4.65 ") Resolution is: 720x1280,nexus 7 (Diagonal 7") Resolution: 800x1280. The common misconceptions are that they have the same screen pixel density because their resolution is almost the same. However, the Galaxy Nexus screen pixel density of about 316dpi,nexus 7 screen pixel density of 216dpi, very far. This is because although they have the same resolution, they do not display the same size. Again, the screen pixel density is the ratio between resolution and display size, and the two factors together determine the pixel density of the screen.

Density level

Countless Android devices have different image densities and are distributed over 100dpi to 480dpi. To optimize images for screens of different densities, you must create images of different resolutions. However, trying to optimize all of the image resources for all of the density of pixels will make it unthinkable to be tedious, while causing the application size to become bloated, the simple way is not feasible. As a compromise, Android uses a density-level concept to classify devices with a certain density range. This allows the application to optimize the picture only for each density level, rather than for all possible pixel densities. This makes the workload of designers and developers reasonable, while preventing the expansion of application size. The cost, of course, is that the physical dimensions of the device slices with different pixel densities are the same size, and this will be explained later.

So how do designers and developers optimize their image resources based on density blocks? The first thing to decide is the rendering size of the picture. For example, an icon tries to render the size of the 0.5x0.5 on the screen. Next, create a picture to support the maximum density, or a scalable vector graph. The best practice is to support the maximum density, which is currently in the xxhdpi at 480dpi. At 480dpi, a picture of 0.5x0.5 is converted to 240x240px. Once the maximum density version of the graphics resource is created in 240x240px. Then it You can then create a density block version that is appropriately scaled down, with the same file name for each version. Google does not recommend creating a tvdpi version in 213dpi because it is only needed by a particular application and is used by a handful of devices. Once all the versions are created, they can be added to the Drawable folder, and the resource identifiers are used to tell the Android system the size required for each density block. Finally, refer to the graphical resources at the XML layout layer, and then generate them in the R file by encoding their names, which is a file that can reference all the resources in the program. The Android system loads the resources at runtime and does its best to match the actual device configuration with the resource identifier application. If the density version of any image resource is not included, Android will use a different density version and reduce it to the appropriate size that is needed. Of course, it is not recommended to let the Android system do this. Because the Andorid system in the operation of picture resources and no picture editing software operation more efficient and accurate.

Dimension Units

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 represent the length and width of a form. They can be used on many elements to set the width, height, outer spacing, inner spacing and so on.

px-- The true pixels on the screen. This is a unit that is associated with pixel density, and the physical size of one px unit depends on the pixel density of the screen.

I n-- The physical inch on the screen. This is a unit that is not associated with pixel density, and the physical size of an in unit is as large as the screen of any pixel density. How many px units are converted into units depends on the pixel density of the screen.

mm-- The physical millimeter on the screen. This is a unit that is not associated with pixel density, and the physical size of a single mm unit is as large as the screen of any pixel density. 25.4mm equals one in . how many px units are converted to one mm unit depends on the pixel density of the screen.

pt-- Point, the normal font size unit on the screen. This is a unit that is not associated with pixel density, and the physical size of a PT unit is as large as the screen of any pixel density. The sum ofpt equals one in. The conversion of a PT unit to how many px units depends on the pixel density of the screen.

DP--pixel density is not associated with pixel units. This is a unit that is not associated with pixel density. However the physical size of a DP unit on a different pixel density screen is just equal to myopia. Approx.dp equals one in. A scale factor in the conversion of one DP to thedpi is associated with the density level of the device. How many pixels a dp equals depends on the pixel density of the screen and the density level to which the device belongs.

s p--The size of a separate pixel unit that specifically specifies the size of text. This is a unit that is not associated with pixel density. However a SPThe physical size of the unit is equal to the myopia on different pixel density screens. In a SPConversion to 160 DPIA scale factor in is associated with the density level of the device and the size of the font representation. One SPHow many pixels is equal depends on the pixel density of the screen and the density level the device belongs to.

The magic of "DP"

As discussed earlier, "px" is not density independent and has different sizes on different devices, however "in", "MM" and "PT" are density independent, of course, have the same size on different devices. However, "DP" and "SP" are somewhat different from the rest, although they are density independent, but they have different sizes on different devices. What is this for? The answer is how "DP" and "SP" are computed for the imager. Android uses MDPI (160DPI) as its standard density, where 1DP is 1px. In essence, "DP" can be thought of as "px" on the DPI. This is why the DP is converted to about 1 in. Therefore, the "DP" to "PX" is converted according to the ratio between the device density level and the standard density (MDPI).

The reason "DP" tends to vary in physical size is due to the fact that the same scaling factor is applied to the entire density bucket. The scaling factor is the compute density bucket dpi, not the device's true dpi. When the DPI of the device is not exactly the same as its density bucket dpi, the same number of "DP" is converted to the same amount of "px". This causes the same number of "PX" to be displayed on different densities of screens, presented in different sizes.

The table above shows how the DP is converted to "PX" on devices of different densities. The DP should be roughly converted to 0.625 in and perfectly converted to a bucket sizes. However, when the DPI of the device is less than the dpi of the density bucket, its pixels are physically larger, and the same number of "DP" is rendered larger, and vice versa.

So this begs the question, why does "DP" allow this physical size change? Fundamentally, Android will sacrifice some precision in physical size to maintain performance and display quality. The use of Android's density-barrel ratio (0.75:1.0:1.5:2.0:3.0) allows "DP" to be scaled to "PX", allowing for very small "px" rounding and simple estimation. At the same time, because the scaling factor is proportional to the density-to-barrel ratio, DP Displays the picture resources that are provided for various densities proportionally. Finally, when zooming the graph line, it is best to keep close to the whole number and a simple score, because a complex score causes the picture color transition to be abnormal and distorted.

Defining bounds for UI elements

There are several special options for defining the length and width of a user interface element, just like a unit of dimensions.

wrap_content-This option will extend the bounds of the element to enough size to accommodate what it contains (pictures, text, and so on), which, in essence, sets the element to the size of its largest child element and does not resize the element.

match_parent (Fill_parent is obsolete in API 8)-This option makes the element fit to the parent element's size, using the parent element's maximum space, and reducing the spacing. Essentially, this causes the child element to be the size of the maximum size allowed by the parent element, and adjusts the size of the element when necessary.

Dimension Unit--This option sets the bounds of the element to the exact unit size, which has been discussed earlier in these units. Essentially, it sets the bounds of the element to the determined unit size and, if necessary, adjusts the size of the element. Demo

To explain how all this works together, it is necessary to create and test a sample application. For example, a design of a picture with a density of xhdpi or 320dpi,200x200 px is used. For simplicity, name the picture resource "Android_logo". With the density at 320dpi,200x200 PX Image resolution as the desired physical size, the replaceable image size can be computed.

Density of xhdpi (320dpi),200x200px Pictures

After calculating the image size required for a specific density, they can be scaled down to the appropriate size in the maximum density version, as explained earlier. Next, each density version of the picture can be placed under the "drawable" folder labeled with the corresponding resource identifier. The Android system chooses the best resources at run time based on the configuration on the device.

Resource Directory with identifiers

Now, in order to present a possible way to maintain density independence, the picture is set to the same physical size using each density-independent dimension unit. Because "px" is not density-independent, and "SP" is designed for text, they are ignored.

Equipment Example: xhdpi Bucket

By using a layout that contains the same picture, these images are set to the same physical size using various size units, which can compare how each unit of dimension works. When running on the simulator at the same time, the image will be displayed in exactly the same size, in every size unit. This is expected because the DPI of the simulator exactly matches the xhdpi (at) density level. However, when running on a galaxy nexus of the same xhdpi density level, there are some changes in the size and dimensions of the picture.

320dpi Simulator

Galaxy Nexus

After inspection, it is obvious that the images with "Wrap_content" and "DP" are matched in size, while the "in", "MM" and "PT" are also matched. However, the two groups did not match each other. What the hell's going on? As discussed earlier, "Wrap_content" and "DP" use density-bucket ratios to properly convert their dimensions. Therefore, the image size is calculated to 200x200 px. However, the actual screen density of the Galaxy nexus is not the 315.3-dpi, which is the xdpi and 318.7 ydpi. Because the actual density is lower than the xhdpi density of the. dpi, the pixel points on the actual device will be larger than the physical size of the imagined 0.625 in.

When the analysis uses "in", "MM" and "PT" To set the picture size, notice that each picture is converted to 197.1x199.2 px. As discussed earlier, "in", "MM" and "PT" are used to convert their dimensions to pixels using the actual device density. Because the actual density of the Galaxy Nexus is lower than the xhdpi density of the. dpi, fewer pixels need to be converted to 0.625x0.625 in, so the picture is reduced.

When comparing the displayed pictures, it is clear that the physical dimensions of the pictures with "Wrap_content" and "DP" are less accurate, but their picture quality is better than "in", "MM" and "PT".

there is no scaling of "wrap_content" and "DP" (left). There are scaling "in", "MM" and "PT"(right )

Equipment Example: hdpi Bucket

Next, when running on a 240dpi simulator, the picture displays each size cell in exactly the same size. Again, it is expected that this is because the dpi of the simulator exactly matches the hdpi density of buckets (buckets) in the 240dpi condition. But as before, when running on a hdpi device, there is an incredible thing, the size of the image has some changes.

240DPI Simulator Screen

HTC Droid Incredible

As usual, HTC Droid incredible displays images of 150x150 px, which are set with "Wrap_content" and "DP". Because the actual screen density of the droid Incredible is 254x254dpi, which is greater than the hdpi density of 240dpi, this means that the pixels on the screen are less than the size of the pixels of the previous dpi density. This causes the 150x150 px picture to appear to be smaller than the base size of 0.625 in. Pictures that are set with "in", "MM", and "PT" are displayed as 158.8x158.8px because more pixels are required to be converted to 0.625x0.625 in so that the image is magnified.

Just like on the Galaxy Nexus, pictures with "Wrap_content" and "DP" settings are less accurate in physical dimensions, but their picture quality is better than "in", "MM" and "PT".

there is no scaling of "wrap_content" and "DP" (left). There are scaling "in", "MM" and "PT"(right )

You can find all the source code of the demo on GitHub, or get it from a later attachment.

Dimension Unit Best Practices

px- does not maintain density independence. Should never be needed.

in/mm/pt- keeps density independent, but counting the exact amount of pixels reduces the experience and causes the image color transition to be unnatural and distorted. If size accuracy is required and any deviations are unacceptable, it is necessary to select IN/MM/PT. In/mm/pt is also useful for setting the distance between elements when the exact distance is required.

The dp- maintains a density independent and maintains the best picture quality, but at the cost of a small deviation in physical size. Because it uses the density bucket ratio to calculate the size, it properly provides accurate size and picture resources. This is the recommended size unit for setting the bounds between elements or the distance between them.

sp- maintain density independent and font quality, but at the cost of physical size, with small deviations. This is the recommended size unit and is used only to set the font size because it takes into account the density and the user's text size preference.

Summarize

Overall, the key to maintaining density independence:

• Identify each image resource to determine the physical dimensions required to render the resource
• Design a vector image resource or raw image resource larger than the maximum density bucket
• Create a specific version of density for each density bucket and put them in the "drawable" Resource directory identified with the appropriate identifiers
• When setting the image boundary, use "wrap_content" to get the best display, use "match_parent" to fill the entire display area, or use "DP" to set a fixed size
• When setting the distance in the layout, use "DP" to get the best display effect. Use only "in", "MM", or "PT" If you need a precise size. Never use "px" here.

This will make it easier to design and develop the best applications on any density display, with an understanding of how Android handles display on different densities of screens.

English Original: Understanding Density independence in Android

Gain an in-depth understanding of Android's density independence