If you're laying out an interactive touch UI element, such as a button, you want something with a sensible physical size, so the user can hit it comfortably. In this way, laying out a touch UI is just like laying out physical buttons and knobs on an electronic device. And for this kind of physical engineering, millimeters (or inches) are the unit of choice.
For some reason this doesn't seem to be the case in touch UI design. I don't consider myself extremely well-read in the subject, but I've honestly never seen anybody use mm as a unit in, say, an Android layout file. But I've seen endless debates about "px" vs "dp" vs "sp" vs who knows what.
The "device-independent pixel" (which on Android is defined in terms of physical length - 1dp ≈ 0.16mm) seems like a really convoluted way to specify a length.
Why not just use millimeters?
Is it a problem with devices not supporting these units properly? Is it a cultural thing (programmers might be more used to thinking in "some sorta pixels" rather than physical units)? What's going on?
Generally, you'll find mobile usability folks talking about millimeters. But programmers and visual designers talk about density-independent pixels or points (1 Android "DIP" = 1 iOS "point") because even if you could specify a measurement in millimeters exactly, you'd end up with rounding issues or half-pixel anti-aliasing ugliness:
1mm equals 6.3 DIP (degree of precision there depends on the exact DPI value of the screen, since dip are quantized to the nearest of 120/160/240/320/480/640 dpi). That means on a standard G1-style 160DIP screen, if you specify a button as (let's say) 8mm, it'd be 50.4 pixels on that screen - good luck rendering that with any degree of precision, or telling Photoshop to end a line exactly 50.4px. And just rounding isn't much of a solution; the screen is still a fixed total width in pixels, and those rounding errors would compound in ways that mess up symmetry if you're (let's say) laying out a grid of buttons with specific sizes and padding amounts.
Specifying that as (let's say) 48DIP is much better, since that smoothly scales: 48px at 160DPI, 72px at HDPI (240) and 96px at 320DPI (AKA 2x in iOS terminology), no fractional pixel rendering or rounding needed.
As to why exactly the 160DPI pixel won out as the 1x mobile unit of measurement for the density-independent pixel, blame the first few iPhones and the HTC G1, which shared that configuration.
I think the W3C provides a decent explanation of various units of measurement for screens, and where each has advantages and disadvantages. I would also very highly recommend Roman Nurik's Density Independent Pixels video. While it doesn't directly answer your question, it provides a lot of great information.
Here are my arguments for DPs instead of mm:
Resources
This is probably the biggest one. When designers and developers create image or video assets, we don't use physical sizes. If you take a picture with your camera, you can't say that the picture is 5 inches tall. How tall the picture is depends on how you decide to print it out.
Thus if I want to display an image to my users or I want to create a button graphic, I can't simply create the resource at 10mm wide by 10mm tall. That one image will render at different sizes on different screens. Even if the device/code does scale the image to exactly 10mm tall, it will look incredibly pixelated on most TVs, and/or will have more detail than a low density device (such as a watch) will be able to display (thus wasting the device's resources).
The answer then is to export a single image at different sizes so that it looks good across multiple devices.
Of course there are other ways around this. Vector graphics could solve this problem, but that's a completely different topic.
DP
As for an Android-specific answer- we kind of do. As you pointed out, we use DP which can be roughly converted to conventional physical units of length such as mm.
However, using DPs works in tandem with Android's density buckets to allow designers to create assets for a finite set of display sizes. In my opinion, labeling these buckets with a physical measurement would be a bit more confusing, as a 4.2" phone might be in a 4" bucket.
SP
SPs are used primarily for text to allow the user to customize their font size. Defining a font size in pixels or mm would be misleading once the user changes their scaling.
it is because Android supports many device sizes and resolutions. Would you want to develop an app that accepts touches in certain places measured by mm and have that location be different on a phone vs a tablet? Or a hi-density tablet of the same size as a low density tablet? Or even just the height/width ratio differences between phones and tablets.
Millimeters is a hard measurement that reflects real life distance, but not the number of pixels. Units such as "dp" and "sp" take into account the pixels as well as the size
Using sp/dp will make your Android applications compatible with multiple screen densities and resolutions
Which is not possible with mm where your app layout is independent of resolution .
来源：https://stackoverflow.com/questions/19526525/why-arent-standard-physical-length-units-like-mm-used-for-touch-ui-layout