手机屏幕的分辨率和图像尺寸关系
手机屏幕的分辨率 320*480 ，图像尺寸72*72，正常显示。
在 240*320 的屏幕分辨率下，图像尺寸是多少（缩放比率是多少）才会正常显示（不失真，不模糊）？
一般比你手机屏幕大的都没事，但是怎么保持比例，像320*480比例就是0.66，你做的图片，保持这个比例就行！
320/480=0.66啊就是这么算啊,下次你做图片就按这个比例来就好了,就不会变形,走样了
http://segmentfault.com/q/1010000000425073
手机切图
http://www.mobileui.cn/app-cut-pic-that-things.html
http://www.fondcool.com/article/detail/94.html
内容重点
以分辨率为1024×768的屏幕来说，即每一条水平线上包含有1024个像素点，共有768条线，即扫描列数为1024列，行数为768行。
举例来说，屏幕分辨率同为1280*720P 一个屏幕为6.0英寸，另一个屏幕为4.7英寸，都知道6.0英寸的要比4.7英寸的大，
而尺寸小的屏幕容纳的分辨率像素更密集，那么同样的分辨率在成像质量上4.7的肯定比6.0的效果要好啦，所以并非屏幕越大越好哦，还要算上屏幕分辩率
PPi（pixels per inch）所表示的是每英寸所拥有的像素（pixel）数目。因此PPI数值越高，即屏幕能够以越高的密度显示图像。
当然，显示的密度越高，拟真度就越高。红米手机的分辨率为1280*720P，而红米手机的尺寸为4.7英寸，根据以上PPI公式计算，
我们的红米手机显示精度为312PPI，已经超过了300PPI的人眼临界点，达到了视网膜屏幕的级别耶！在现在的千元机市场中，除了红米，是没有任何一部手机可以做到的。
http://tieba.baidu.com/p/2515286522
mdpi
hdpi
xhdpi
http://www.cnblogs.com/cmduan/archive/2012/03/09/2388345.html
Android上常见度量单位【xdpi、hdpi、mdpi、ldpi】解读
术语和概念
屏幕尺寸
屏幕的物理尺寸，以屏幕的对角线长度作为依据（比如 2.8寸， 3.5寸）。
简而言之， Android把所有的屏幕尺寸简化为三大类：大，正常，和小。
程序可以针对这三种尺寸的屏幕提供三种不同的布局方案，然后系统会负责把你的布局方案以合适的方式渲染到对应的屏幕上，这个过程是不需要程序员用代码来干预的。
屏幕长宽比
屏幕的物理长度与物理宽度的比例。程序可以为制定长宽比的屏幕提供制定的素材，只需要用系统提供的资源分类符long和 notlong。
分辨率
屏幕上拥有的像素的总数。注意，虽然大部分情况下分辨率都被表示为“宽度×长度”，但分辨率并不意味着屏幕长宽比。在 Android系统中，程序一般并不直接处理分辨率。
密度
以屏幕分辨率为基础，沿屏幕长宽方向排列的像素。
密度较低的屏幕，在长和宽方向都只有比较少的像素，而高密度的屏幕通常则会有很多 ——甚至会非常非常多——像素排列在同一区域。屏幕的密度是非常重要的，举个例子，长宽以像素为单位定义的界面元素（比如一个按钮），在低密度的屏幕上会 显得很大，但在高密度的屏幕上则会显得很小。
密度无关的像素（ DIP ）
指一个抽象意义上的像素，程序用它来定义界面元素。它作为一个与实际密度无关的单位，帮助程序员构建一个布局方案（界面元素的宽度，高度，位置）。
一个与密度无关的像素，在逻辑尺寸上，与一个位于像素密度为 160DPI的屏幕上的像素是一致的，这也是Android平台所假定的默认显示设备。在运行的时候，平台会以目标屏幕的密度作为基准，“透明地”处理所 有需要的DIP缩放操作。要把密度无关像素转换为屏幕像素，可以用这样一个简单的公式： pixels = dips * (density / 160)。举个例子，在 DPI为 240的屏幕上， 1个 DIP等于 1.5个物理像素。我们强烈推荐你用 DIP来定义你程序的界面布局，因为这样可以保证你的 UI在各种分辨率的屏幕上都可以正常显示。
为了简化程序员面在对各种分辨率时的困扰，也为了具备各种分辨率的平台都可以直接运行这些程序， Android平台将所有的屏幕以密度和分辨率为分类方式，各自分成了三类：
·三种主要的尺寸：大，正常，小；
·三种不同的密度：高（ hdpi），中（ mdpi）和低（ ldpi）。 【DPI是“dot per inch”的缩写，每英寸像素数。】
如果需要的话，程序可以为各种尺寸的屏幕提供不同的资源（主要是布局），也可以为 各种密度的屏幕提供不同的资源（主要是位图）。除此以外，程序不需要针对屏幕的尺寸或者密度作出任何额外的处理。在执行的时候，平台会根据屏幕本身的尺寸 与密度特性，自动载入对应的资源，并把它们从逻辑像素（ DIP，用于定义界面布局）转换成屏幕上的物理像素。
首先是几个基本概念：
1.屏幕尺寸Screen size
即显示屏幕的实际大小，按照屏幕的对角线进行测量。
为简单起见，Android把所有的屏幕大小分为四种尺寸：小，普通，大，超大(分别对应：small, normal, large, and extra large).
应用程序可以为这四种尺寸分别提供不同的自定义屏幕布局-平台将根据屏幕实际尺寸选择对应布局进行渲染，这种选择对于程序侧是透明的。
2.屏幕长宽比Aspect ratio
长宽比是屏幕的物理宽度与物理高度的比例关系。应用程序可以通过使用限定的资源来为指定的长宽比提供屏幕布局资源。
3.屏幕分辨率Resolution
在屏幕上显示的物理像素总和。需要注意的是：尽管分辨率通常用宽x高表示，但分辨率并不意味着具体的屏幕长宽比。
在Andorid系统中，应用程序不直接使用分辨率。
4.密度Density
根据像素分辨率，在屏幕指定物理宽高范围内能显示的像素数量。
在同样的宽高区域，低密度的显示屏能显示的像素较少，而高密度的显示屏则能显示更多的像素。
屏幕密度非常重要，因为其它条件不变的情况下，一共宽高固定的UI组件（比如一个按钮）在在低密度的显示屏上显得很大， 而在高密度显示屏上看起来就很小。
为简单起见，Android把所有的屏幕分辨率也分为四种尺寸：小，普通，大，超大(分别对应：small, normal, large, and extra large).
应用程序可以为这四种尺寸分别提供不同的资源-平台将透明的对资源进行缩放以适配指定的屏幕分辨率。
5.设备独立像素Density-independent pixel (dp)
应用程序可以用来定义UI组件的虚拟像素单元，通过密度无关的方式来描述布局尺寸和位置。
一个设备独立像素相当于一个160 dpi屏幕上的物理像素。
在程序运行时，系统根据屏幕的实际密度透明的处理任何需要缩放的设备独立像素单元，设备独立像素转换成屏幕实际像素的换算很简单：pixels = dps * (density / 160).
例如在240 dpi的屏幕上，1个设备独立像素等于1.5物理像素.为确保UI组件在不同的屏幕都能合适的展示，强烈建议使用设备独立像素单元来定义你的应用程序UI。
四种屏幕尺寸分类：: small, normal, large, and xlarge
四种密度分类: ldpi (low), mdpi (medium), hdpi (high), and xhdpi (extra high)
需要注意的是: xhdpi是从 Android 2.2 (API Level 8)才开始增加的分类.
xlarge是从Android 2.3 (API Level 9)才开始增加的分类.
DPI是“dot per inch”的缩写，每英寸像素数。
一般情况下的普通屏幕：ldpi是120，mdpi是160，hdpi是240，xhdpi是320。
参考：http://developer.android.com/images/screens_support/screens-ranges.png
两种获取屏幕分辨率信息的方法：
DisplayMetrics metrics = new DisplayMetrics();
Display display = activity.getWindowManager().getDefaultDisplay();
display.getMetrics(metrics);
//这里得到的像素值是设备独立像素dp
//DisplayMetrics metrics=activity.getResources().getDisplayMetrics(); 这样获得的参数信息不正确，不要使用这种方式。
不能使用android.content.res.Resources.getSystem().getDisplayMetrics()。这个得到的宽和高是空的。
private void initResolutionStr(Context context) {
if (ApiConfig.getResolutionStr() == null || ApiConfig.getResolutionStr().equals("")) {
WindowManager winMgr = (WindowManager) context.getApplicationContext().getSystemService(Context.WINDOW_SERVICE);
Display display = winMgr.getDefaultDisplay();
int height = display.getHeight();
int width = display.getWidth();
String resolution = height > width ? height + "x" + width : width + "x" + height;
ApiConfig.setResolutionStr(resolution);
// densityDpi = 120dpi is ldpi, densityDpi = 160dpi is mdpi,
// densityDpi = 240dpi is hdpi, densityDpi = 320dpi is xhdpi
DisplayMetrics dm = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dm);
int densityDpi = dm.densityDpi;
ApiConfig.setDensityDpi(densityDpi);
}
}
如果需要为Android pad定制资源文件，则res目录下的目录可能为：
drawable
drawable-ldpi
drawable-mdpi
drawable-hdpi
drawable-xhdpi
drawable-nodpi
drawable-nodpi-1024×600
drawable-nodpi-1280×800
drawable-nodpi-800×480
values
values-ldpi
values-mdpi
values-hdpi
values-xhdpi
values-nodpi
values-nodpi-1024×600
values-nodpi-1280×800
values-nodpi-800×480
Android上常见度量单位：
px（像素）：屏幕上的点，绝对长度，与硬件相关。
in（英寸）：长度单位。
mm（毫米）：长度单位。
pt（磅）：1/72英寸，point。
dp（与密度无关的像素）：一种基于屏幕密度的抽象单位。在每英寸160点的显示器上，1dp = 1px。
dip：Density-independent pixel,同dp相同。
sp：在dp的基础上，还与比例无关，个人理解为是一个矢量图形单位。
引入dp/dip的原因：
过去，程序员通常以像素为单位设计计算机用户界面。例如，定义一个宽度为300像素的表单字段，列之间的间距为5个像素，图标大小为16×16像素 等。这样处理的问题在于，如果在一个每英寸点数（dpi）更高的新显示器上运行该程序，则用户界面会显得很小。在有些情况下，用户界面可能会小到难以看清 内容。与分辨率无关的度量单位可以解决这一问题。
如何计算密度(请参照原帖：http://www.devdiv.com/thread-28610-1-1.html)；
1.标准是240*320画在1.5*2平方inch上。那么像每平方英寸有240*320/(1.5*2)=25600点，也就是一平方英寸的像素点为25600，所以dpi取为它的平方根160;如果你的dpi是120，那么它的密度就是0.75.
2.密度不只是与width有关，还与height有关，所以不管width是1.8还是1.3，它的密度都有可能是1；比如width是1.8，只要它 的height是3/1.8的话，如果pixel为240*320的话，它的密度仍旧是1；同样如果width为1.3，只要它的 height为3/1.3的话，像素点为240*320，则密度也是1.
3.320*480/(1.5*2)得到单位平方英寸的点为51200，所以单位平方英寸是240*320画在1.5*2屏幕的2倍。但是这是平方英寸啊，算密度的时候要开平方的啊，所以应该是2开平方，是1.414吧，大致密度为1.5。
如何做到与密度无关：
如果屏幕密度为160，这时dp和sp和px是一样的。1dp=1sp=1px，但如果使用px作单位，如果屏幕大小不变（假设还是3.2寸），而屏 幕密度变成了320。那么原来TextView的宽度设成160px，在密度为320的3.2 寸屏幕里看要比在密度为160的3.2寸屏幕上看短了一半。但如果设置成160dp或160sp的话。系统会自动将width属性值设置成320px的。 也就是160 * 320 / 160。其中320 / 160可称为密度比例因子。也就是说，如果使用dp和sp，系统会根据屏幕密度的变化自动进行转换。官方文档总结的计算公式为：pixels = dps * (density /160).
附：
传说iPhone/Mac的设计从一开始就考虑到对任意分辨率的支持，iOS的所有介面元素用的都已经是矢量化了的图片，UI界面是系统级别的与密度无关；而Android虽然支持任意分辨率，但不是系统全局的，求证。
