Android中常用单位dp，sp和px的区别、关系和使用问题

[i=s] 本帖最后由 jp1017 于 2015-8-18 09:22 编辑 [/i]

安卓中常用的三种单位dp、sp、px到底是什么呢，这里揭秘下：

一：区别

1、dip或dp (device independent pixels)设备独立像素，一种基于屏幕密度的抽象单位，在每英寸160点的显示器上，1dip=1px。

2、sp (scaled pixels — best for text size) 放大像素，主要处理字体的大小。可以根据用户字体大小首选项进行缩放。

3、px (pixels)像素，每个px对应屏幕上的一个点，这个用的比较多。

这里还有一个，屏幕像素密度（ppi）计算公式如下：ppi = √（长度像素数的平方+ 宽度像素数的平方） / 屏幕对角线英寸数，如800×480的4英寸屏幕的ppi =（ √(800*800+480*480)） / 4 = 233ppi。

二：换算

dp与px换算：
px = dp*ppi/160
dp = px / (ppi / 160)

sp与px换算
px = sp*ppi/160
sp = px / (ppi / 160)

三：多屏幕适配的3条原则：
1、设置view的属性android:layout_width和android:layout_height的值时，wrap_content，match_parent或dp比px更好，文字大小应该使用sp来定义。

2、在程序的代码中不要出现具体的像素值，在dimens.xml中定义；

3、对不同的屏幕提供合适大小的图片。

四：屏幕适配的注意事项：
1、AndroidManifest.xml设置
android:anyDensity=”true”时，应用程序安装在不同密度的终端上时，程序会分别加载xxhdpi、xhdpi、hdpi、mdpi、ldpi文件夹中的资源。
相反，如果设为false，即使在文件夹下拥有相同资源，应用不会自动地去相应文件夹下寻找资源：
    1) 如果drawable-hdpi、drawable-mdpi、drawable-ldpi三个文件夹中有同一张图片资源的不同密度表示，那么系统会去加载drawable_mdpi文件夹中的资源；
    2) 如果drawable-hpdi中有高密度图片，其它两个文件夹中没有对应图片资源，那么系统会去加载drawable-hdpi中的资源，其他同理；
    3) 如果drawable-hdpi,drawable-mdpi中有图片资源，drawable-ldpi中没有，系统会加载drawable-mdpi中的资源，其他同理，使用最接近的密度级别。

2、横屏竖屏目录区分
    1) drawable
        a) drawable-hdpi该图片即适用于横屏，也适用于竖屏；
        b) drawable-land-hdpi,当屏幕为横屏，且为高密度时，加载此文件夹的资源；
        c) drawable-port-hdpi,当屏幕为竖屏，且为高密度时，加载此文件夹中的资源。其他同理。
    2) layout

在res目录下建立layout-port和layout-land两个目录，里面分别放置竖屏和横屏两种布局文件，以适应对横屏竖屏自动切换。

3、使用9-patch PNG图片
使用图片资源时，如果出现拉伸，因为图片处理的原因，会变形，导致界面走形。9-patch PNG图片也是一种标准的PGN图片，在原生PNG图片四周空出一个像素间隔，用来标识PNG图片中哪些部分可以拉伸、哪些不可以拉伸、背景上的边框位置等。
“上、左”定义可拉伸区域，“右、下”定义显示区域，如果用到完整填充的背景图，建议不要通过android:padding来设置边距，而是通过9-patch方式来定义。

4、不同的layout
Android手机屏幕大小不一，有480×320, 640×360, 800×480……怎样才能让Application自动适应不同的屏幕呢？其实很简单，只需要在res目录下创建不同的layout文件夹，比如：layout-640×360、layout-800×480……所有的layout文件在编译之后都会写入R.java里，而系统会根据屏幕的大小自己选择合适的layout进行使用。

参考：

http://blog.m1910.com/archives/1205.html http://blog.csdn.net/guozh/article/details/8954994 http://blog.csdn.net/jdsjlzx/article/details/45891551 http://www.cnblogs.com/zhwl/archive/2013/06/12/3132722.html http://www.cnblogs.com/bluestorm/p/3640786.html