Android development: in-depth analysis of DP and PX in Android-

Source: Internet
Author: User

Dip: Device Independent pixels (device independent pixel ). Different devices have different display effects, which are related to the hardware of the device. We recommend that you use this function to support WVGA, hvga, and qvga without pixels.

Density-independent pixels, an abstract unit based on the physical density of the screen. Density can be understood as the number of pixels per inch (unit: DPI). 1dp is actually equivalent to a point on the screen with a density of DPI (can it be understood as a physical size ?). That is to say, if the screen physical density is DPI, DP and PX are equivalent. Let's talk about it on the actual mobile phone screen. A cell phone screen with a resolution of 320*480. If the width is 2 inch and the height is 3 inch, the screen density is 160 DPI. If the screen size remains unchanged and the resolution changes, for example, the resolution changes from 320*480 to 480*800, the physical density of the screen increases (greater than 160 DPI ). This means that the screen can display more pixels per inch, and the display effect is more delicate. Assume that the width of a button is in the unit of DP, set to 160 at 320 DPI, and in a higher DPI (such as DPI), the width of the button looks the same as that of the screen at DPI. This is because the system calculates a conversion ratio when it finds that the screen density is not 160dpi, and then multiply the ratio with the actual size to obtain a new size. The ratio is calculated by dividing the density of the target screen by 160. If the density of the target screen is 320 DPI, the ratio is 2. If the button width is 160dp, the screen width on the 320dpi is 320 pixels (DP is an abstract unit and should be converted to pixels on the actual screen ). From this point, we can see that DP can adapt to the screen density. No matter how the screen density changes, as long as the physical size of the screen remains unchanged, the actual display size does not change. If you set the button width to 160 PX, there will still be pixels on the DPI screen. It seems that the width of the button is only half the screen width of DPI. Android officially recommends that you use DP as the unit of size when displaying attributes such as width, height, and position.
Px = dip * density/160 indicates that when the screen density is 160, PX = dip. According to Google's suggestion, it is best to use SP as the unit for the font size of textview, and check the source code of textview. Android uses SP as the font size unit by default. Units that use dip as other elements.
Note: according to Google's recommendation, dip is used for pixels and SP is used for fonts.
For example, the difference between PX and dip is as follows:
PX is a pixel. If PX is used, it will be drawn using the actual pixel. For example, draw a horizontal line with a length of PX, in a 480-width simulator, the screen width is half the screen width, and in a 320-width simulator, the screen width is 2/3.
Dip, for example, if you build a 320 dip horizontal line, whether you are on a 480 or simulator, it is half the screen length (when the screen size remains unchanged ).

public static int dip2px(Context context, float dipValue) {final float scale = context.getResources().getDisplayMetrics().density;return (int) (dipValue * scale + 0.5f);}public static int px2dip(Context context, float pxValue) {final float scale = context.getResources().getDisplayMetrics().density;return (int) (pxValue / scale + 0.5f);}

For more information, see [url = http://blog.csdn.net/eggcalm/article/details/7006?####/url=:
Today, I accidentally asked my colleague a question about the DP unit. Then, a series of questions caused by this question completely overturned my theory system on the DP.

My question is: Since the nature of DP is physical size, why not replace it with traditional length units such as cm or mm?

Then he replied that my DP is irrelevant to the pixel density... I did not care about this answer, but his next sentence completely shocked me. The sentence is like this: 320dp on your mobile phone is just full, 310dp is a little bit full screen.

My mobile phone Is HTC Desire. I have never heard of this theory, and then I immediately did a small experiment. In fact, it is true that I set a textview background to red, and the width to 320dp. I can see that the screen is full, 310dp is a little worse.

When I saw this test result, I collapsed again. I hope my colleague could say the second sentence is a beautiful mistake. I cannot accept what I have understood for so long, but the truth is cruel.

Android Developers I have read the DP document N times. I remember the PX and DP conversion formula: Px = DP * (DPI/160 ), however, after turning over the source code, we found that the DPI here is the normalized DPI, which may be 120 (low), 160 (medium), 240 (high) and 320 (xhigh). What I previously understood was the actual DPI of the device!

The actual DPI of G7 is 252. According to my previous understanding, the conversion of 310dp to PX should be: 310 * (252/160) = 488 pixels, while the horizontal direction of G7 is PX, in fact, Android does not use 252 as DPI. Instead, G7 is regarded as an hdpi device, and then DPI is used to calculate the final pixel, therefore, on G7, 320dp is: 320 * (240/160) = 480 pixels, which is just full screen. 310dp is really a little worse.

After figuring out this problem, I felt a little better, but another problem came one after another:
The nature of DP is still physical, isn't it? Although the Android system treats DP as four types of devices: 120 (low), 160 (medium), 240 (high), 320 (xhigh), and 160dpi, 160dp is 1 inch. On 240dpi, 160dp is 1 inch, 120dpi and 320dpi are also 1 inch, although they occupy different segments, however, the final results are all within 1 inch of the screen. This system is actually very reasonable. The physical size occupied by a DP button on all devices should be the same, in this way, they are as big as the angle of the human eye, and they feel the same as watching or reading.
Is the background as detailed ). This should be the reason why the DP concept is introduced in the Android system, because the pixel density difference between the mobile phone screen is too big, and the Web is not applicable at all, what is the difference in pixel density between the screens?

The ultimate question is, is there really only four devices with different pixel density in real life? Impossible. Although all these devices can be roughly divided into four density types: low, medium, high, and xhigh, for two devices with different pixel density in the same range, the physical sizes used by the same DP are different. For example, the screen size of G7 (HTC Desire) is 3.7 inch, the resolution is 480*800, the pixel density is 252 DPI, and the screen size of G10 (HTC Desire HD) is 4.3 inch, the resolution is 480*800, and the pixel density is 217 DPI. Assume that there is a button and Its width is set to DP.
Divided into hdpi, the actual width of the button on the two devices is: 100 * (240/160) = 150 pixels, because the actual pixel density of the two devices is different, so the actual display effect is: the actual physical size of the button on the two devices is different. This is contrary to the concept that android entered DP.

You can say that this difference is very small for devices that belong to the same hdpi, but it is obvious between ldpi and hdpi. I agree very much, but if DP is converted to PX, it does not use normalized DPI (that is, 120 (low), 160 (medium), 240 (high), 320 (xhigh), but uses the real pixel density of the device. Although the number of pixels is different, the physical size shown in the end is indeed the same, in my opinion, this calculation method is loyal to the theory that the pixel density is irrelevant.

Finally, I want to say that if Android wants a button with a width of 1 inch DP to be big on any device, why not use inches as the measurement unit directly? If you have a good idea, please leave a message.

Update:

When I answered a question from a factar user this afternoon, I finally found a reasonable answer to the "ultimate question" above. In the factar website, I found an important sentence:

"However, bitmap scaling can result in blurry or pixelated bitmaps, which you might notice in the above screenshots ."

This statement indicates that image blurring occurs when image resources are scaled. According to my analysis above, to ensure that the same image resources are identical in size on devices with different pixel density (this can be done completely, when DP is converted to PX, the physical pixel density parameter of the device is used.) the scaling factor of the image on different devices must be different, which leads to blurred images! Therefore, I guess Google has "almost the same size" of the same DP on different devices to ensure that the image will not be blurred ".

In addition, this answer also corrected my misunderstanding. Many application developers only use one hdpi resource or one xhdpi resource to reduce the installation package size, instead of mdpi resources or ldpi resources, it is feasible to implement scaling on the mdpi and ldpi devices, however, we should not ignore the image blur and poor display effects caused by scaling.

For questions and answers, refer:
I don't know if eggclam has a more in-depth understanding of DP. I am now in this step for DP. I now have three pads, one 10-inch, two 7-inch,
The parameters are as follows:
A: 7-inch Pad 1,
Denstiy: 1.0 resolution 1024x600
B: 7-inch pad 2,
Denstiy: 1.33 resolution 1280x800
C: 7-inch Pad 3,
Denstiy: 1.0 resolution 1280x800

According to the official Google documentation (http://developer.android.com/guide/practices/screens_support.html)
The density independence section uses DP under different denstiy, And the size should look the same.
I have set buttons with the same DP length in all three pads, but the lengths on the three pads are different. I don't know what the reason is? Can you add your friends to discuss it?

Reference "factar" Comments: I don't know if eggclam has a better understanding of DP now. I am also stuck in this step for DP now. I have three pads...

The C device should be 10 inches, right?

If the C device is 10 inch, the physical DPI of the three devices is roughly as follows:
A: 169.5
B: 215.6
C: 150.9

According to the Division (http://developer.android.com/guide/practices/screens_support.html#range) Here, A and C are evaluated as mdpi (density = 1.0), bben should be evaluated as hdpi (density = 1.5 ), however, since API Level 13, Android has introduced density_ TV (DPI = 213), and the data you post does prove this, so the density of Device B follows your data 1.33.

Next, calculate the number of pixels that a 50 DP line shows on the three devices:
A: 50*1.0 = 50 (PX)
B: 50*1.33 = 67 (PX)
C: 50*1.0 = 50 (PX)

The next question is simple. Is the physical size occupied by these three pixels on ABC consistent? We can calculate:
A: 50/169 .5 = 0.2950 (INCHES) = 0.7493 (centimeters)
B: 67/215 .6 = 0.3108 (INCHES) = 0.7894 (centimeters)
C: 50/150 .9 = 0.3313 (INCHES) = 0.8418 (centimeters)

Based on the above results, it is reasonable to see that the same DP in Android is on all mdpi devices, although the number of pixels is the same, however, because the physical DPI of each device is different, there is a slight difference in the final display size.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.