标签：
方法二、
drawable-ldpi、 120ppi
drawable-mdpi、 160ppi
drawable-hdpi、 240ppi
drawable-xhdpi， 320ppi
drawable-xxhdpi 480ppi
300ppi的手机会选择320ppi对应的drawable目录下的资源，
方法三、
可以看出他们占用的长和宽都是一样的，这种自动缩放的优点是只需要一张图片就能适应各种ppi类型的屏幕。
缺点是当对100X100的图片进行变换成200X200的图片时肯能会造成图片的不清晰，如果提供一个drawable-xhdpi下的图片资源，图片较多的话会无形增加应用的大小，所以说如何进行选择也是一个衡量。
建议是将比较重要的图片资源提供多个版本。不是很重要的图片资源存储一个版本，让系统根据自己的ppi自己对图片进行适当的缩放显示。
Android多分辨率适配是一件很有意义但是比较麻烦的事情，网上有很多关于多分辨率适配的文章，多数文章讲解的都是整个APP的图片比较规则，可以将图片做成9图来完成多分辨率适配，但是对于一些游戏类应用（这里说的游戏没有使用游戏引擎）、低龄儿童应用，APP中有很多花哨的图片，这种APP的图片显然无法做成9图，在网上查了很多资料始终没有比较理想的解决方案，结合自己最近做的项目介绍一下针对这种情况下的多分辨率适配：
为了减少UI的工作量，一个APP只提供一套图；
为了减少程序员的重复工作，一个APP只维护一套程序；
为了在各种分辨率下图片不失真，UI按照最高分辨率提供图片；
为了达到理想的效果，图片切分尽量细，将带有修饰效果的图片全部和背景分离（比如APP的大背景中有树、花草、人物，将这些小场景从背景图中切出来，程序员自己将图贴上去，只是不同分辨率下的尺寸、位置不一样。）；
为了图片不变形，图片宽高必须等比缩放；
原则上程序只有一套布局，对于有特殊要求的地方，可以创建多套layout文件夹，为主流分辨率提供相应的布局文件；
程序员创建多套values文件夹，文件夹下的dimens.xml文件存放相应分辨率的图片尺寸和坐标。
将公用的布局抽出，在需要使用的地方以include标签的形式引入。
注：
上面的方案基本上解决了多分辨率适配的问题（项目中大概只需要适配4-5款分辨率的机型），对于分辨率相差较大或者屏幕尺寸相差太大的情况，可以考虑做两套UI和两套程序，这样才能达到比较理想的效果，比如很多APP都提供了手机版和PAD版两个APP。
多分辨率适配通常的做法是在同一套程序下按照分辨率创建多个layout文件夹，但在开发中我发现也可以按照分辨率创建多个values文件夹，比如：values-1230x800、values-1920x1200、values-1969x1536、values-974x768，对于按照分辨率创建不同文件夹特别需要说明的是：
格式：文件夹名称-大数值x小数值（大数值在前，小数值在后）；
文件夹名称中的数值不是机器的真实分辨率，需要减掉通知栏的高度；
同一分辨率在横竖屏情况下是是两个不同的文件夹，比如分辨率为1024x768,通知栏高度为50，那么横屏对应的文件夹为：values-1024x718，竖屏对应的文件夹为values-974x768。
dp(density-independent pixel)是与密度无关的像素单位，也就是dip。它是基于设备屏幕物理密度的抽象单位。1dp 表示屏幕DPI为160时1px的长度。DPI 越高的屏幕，屏幕绘制1dp 需要越多的像素，反之亦然。
小结：通过加上上述限定可以实现一个apk适配几种主流的屏幕尺寸和屏幕密度，这种限定方式比较适用于对外发布应用，不知道终端具体参数的情况，但是不能做到精确适配，对于屏幕尺寸和密度相差不大的两种平台不能很好的区分。
为了解决上述问题，自Android3.2开始，引入了精确适配，理论上可以适配任意像素宽度，高度，屏幕密度的平台，需用以下方式添加限定符
相信设计师们一般都会用最新的iPhone5（5s和5的尺寸以及分辨率都一样）来做原型设计，而iPhone5的屏幕分辨率为640X1164, 屏幕尺寸为4英寸，根据勾股定理(a^2 + b^2 = c^2)640^2+1164^2=1764496, 然后再对其开根号可求出屏幕对角线的分辨率为：1328，除以4可得出iphone5的dpi：1328/4≈332 可以看出iPhone5的屏幕的dpi约等于320, 刚好属于xhdpi，所以你可以很自豪的像你们的设计师说不用专门为Android端切图，直接把iPhone的那一套切好的图片资源放入drawable-xhdpi文件夹里就ok了。
标签：
原文地址：http://www.cnblogs.com/zrui513/p/4875732.html
