谈到适配，首先需要介绍几个基本单位：
1、密度无关像素（dp）：
含义：density-independent pixel，叫dp或dip，与终端上的实际物理像素点无关
单位：dp，可以保证在不同屏幕像素密度的设备上显示相同的效果，是安卓特有的长度单位。
场景例子：假如同样都是画一条长度是屏幕一半的线，如果使用px作为计量单位，那么在480x800分辨率手机上设置应为240px；在320x480的手机上应设置为160px，二者设置就不同了；如果使用dp为单位，在这两种分辨率下，160dp都显示为屏幕一半的长度。
dp与px的转换：1dp = （dpi / 160 ） * 1px;
| 密度类型 | 代表的分辨率（px） | 屏幕密度（dpi） | 换算 |
| 低密度（ldpi） | 240 x 320 | 120 | 1dp = 0.75px |
| 中密度（mdpi） | 320 x 480 | 160 | 1dp=1px |
| 高密度（hdpi） | 480 x 800 | 240 | 1dp=1.5px |
| 超高密度（xhdpi） | 720 x 1280 | 320 | 1dp=2px |
| 超超高密度（xxhdpi） | 1080 x 1920 | 480 | 1dp=3px |
2、独立比例像素（sp）：
含义：scale-independent pixel，叫sp或sip
单位：sp，字体大小专用单位 Android开发时用此单位设置文字大小，可根据字体大小首选项进行缩放； 推荐使用12sp、14sp、18sp、22sp作为字体大小，不推荐使用奇数和小数，容易造成精度丢失，12sp以下字体太小。
3、sp 与 dp 的区别：
dp只跟屏幕的像素密度有关；
sp和dp很类似但唯一的区别是，Android系统允许用户自定义文字尺寸大小（小、正常、大、超大等等），当文字尺寸是“正常”时1sp=1dp=0.00625英寸，而当文字尺寸是“大”或“超大”时，1sp>1dp=0.00625英寸。类似我们在windows里调整字体尺寸以后的效果——窗口大小不变，只有文字大小改变。
追到android源码，发现系统内部用applyDimension() （路径：android.util.TypedValue.applyDimension()）将所有单位都转换成px 再处理：
/**
Converts an unpacked complex data value holding a dimension to its final floating
point value. The two parameters unit and value
are as in {@link #TYPE_DIMENSION}.
@param unit The unit to convert from.
@param value The value to apply the unit to.
@param metrics Current display metrics to use in the conversion –
supplies display density and scaling information.
1
@return The complex floating point value multiplied by the appropriate
metrics depending on its unit.
*/
public static float applyDimension(int unit, float value,
DisplayMetrics metrics)
{
switch (unit) {
case COMPLEX_UNIT_PX:
return value;
case COMPLEX_UNIT_DIP:
return value * metrics.density;
case COMPLEX_UNIT_SP:
return value * metrics.scaledDensity;
case COMPLEX_UNIT_PT:
return value * metrics.xdpi * (1.0f/72);
case COMPLEX_UNIT_IN:
return value * metrics.xdpi;
case COMPLEX_UNIT_MM:
return value * metrics.xdpi * (1.0f/25.4f);
}
return 0;
}可以发现dp和sp的区别在于density和scaledDensity两个值上；
/**
The logical density of the display. This is a scaling factor for the
Density Independent Pixel unit, where one DIP is one pixel on an
approximately 160 dpi screen (for example a 240x320, 1.5"x2" screen),
providing the baseline of the system’s display. Thus on a 160dpi screen
this density value will be 1; on a 120 dpi screen it would be .75; etc.
This value does not exactly follow the real screen size (as given by
{@link #xdpi} and {@link #ydpi}, but rather is used to scale the size of
the overall UI in steps based on gross changes in the display dpi. For
example, a 240x320 screen will have a density of 1 even if its width is
1.8", 1.3", etc. However, if the screen resolution is increased to
320x480 but the screen size remained 1.5"x2" then the density would be
increased (probably to 1.5).
@see #DENSITY_DEFAULT
*/
public float density;
/**
A scaling factor for fonts displayed on the display. This is the same
as {@link #density}, except that it may be adjusted in smaller
increments at runtime based on a user preference for the font size.
*/
public float scaledDensity;4、适配方案
屏幕适配问题的本质是使得布局、布局组件在Android不同尺寸、不同分辨率的手机上具备相同的显示效果，为了更形象的展示，假设我们在布局文件中把一个ImageView的宽度设置为360dp,那么在下面两张图中表现是不一样的：
图一是1080P,480dpi的手机， 图二是1080P,420dpi的手机
从上面的布局中可以看到，同样是1080P的手机，差异是比较明显的。在这种情况下，我们的UI可能需要做一些微调甚至单独适配。
第二个问题，这种方式无法快速高效的把设计师的设计稿实现到布局代码中，通过dp直接适配，我们只能让UI基本适配不同的手机,但是在设计图和UI代码之间的鸿沟，dp是无法解决的，因为dp不是真实像素。而且，设计稿的宽高往往和Android的手机真实宽高差别极大，以我们的设计稿为例，设计稿的宽高是375px750px，而真实手机可能普遍是10801920,
那么在日常开发中我们是怎么跨过这个鸿沟的呢？基本都是通过百分比啊，或者通过估算，或者设定一个规范值等等。总之，当我们拿到设计稿的时候，设计稿的ImageView是128px128px，当我们在编写layout文件的时候，却不能直接写成128dp128dp。在把设计稿向UI代码转换的过程中，我们需要耗费相当的精力去转换尺寸，这会极大的降低我们的生产力，拉低开发效率。
目前主流UI规范屏幕尺寸：
| 标识 | 屏幕尺寸 |
| xhdpi | 720*1280 |
| xxhdpi | 1080*1920 |
Android 设计规范中间距单位是 dp，dp 在 Android 机上不同的密度转换后的 px 是不一样的，所以按照设计图的 px 转换成 dp 也是不一样的。
现在，多数标注工具都支持 dp 标注功能，比如 MarkMan，如果UI设计者是按照1280*720的尺寸设计的效果图，在标注时选择xhdpi即可
使用 MarkMan 进行 dp 标注
DP/PX在线转换工具：http://pixplicity.com/dp-px-converter
宽高限定符适配
为了高效的实现UI开发，出现了新的适配方案，我把它称作宽高限定符适配。简单说，就是穷举市面上所有的Android手机的宽高像素值：
设定一个基准的分辨率，其他分辨率都根据这个基准分辨率来计算，在不同的尺寸文件夹内部，根据该尺寸编写对应的dimens文件。
比如以480x320为基准分辨率
宽度为320，将任何分辨率的宽度整分为320份，取值为x1-x320
高度为480，将任何分辨率的高度整分为480份，取值为y1-y480
那么对于800*480的分辨率的dimens文件来说，
x1=(480/320)*1=1.5px
x2=(480/320)*2=3px
…
这个时候，如果我们的UI设计界面使用的就是基准分辨率，那么我们就可以按照设计稿上的尺寸填写相对应的dimens引用了,而当APP运行在不同分辨率的手机中时，这些系统会根据这些dimens引用去该分辨率的文件夹下面寻找对应的值。这样基本解决了我们的适配问题，而且极大的提升了我们UI开发的效率，
但是这个方案有一个致命的缺陷，那就是需要精准命中才能适配，比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。而使用默认的尺寸的话，UI就很可能变形，简单说，就是容错机制很差。
不过这个方案有一些团队用过，我们可以认为它是一个比较成熟有效的方案了。
UI适配框架（已经停止维护）
鸿洋大佬的适配方案的项目也来自于宽高限定符方案的启发。
使用方法也很简单：
第一步：在你的项目的AndroidManifest中注明你的设计稿的尺寸。
第二步：让你的Activity继承自AutoLayoutActivity。
然后我们就可以直接在布局文件里面使用具体的像素值了，比如，设计稿上是96*96,那么我们可以直接写96px，APP运行时，框架会帮助我们根据不同手机的具体尺寸按比例伸缩。
这可以说是一个极好的方案，因为它在宽高限定符适配的基础上更进一步，并且解决了容错机制的问题，可以说完美的达成了开发高效和适配精准的两个要求。
但是我们能够想到，因为框架要在运行时会在onMeasure里面做变换，我们自定义的控件可能会被影响或限制，可能有些特定的控件，需要单独适配，这里面可能存在的暗坑是不可预见的，还有一个比较重要的问题，那就是整个适配工作是有框架完成的，而不是系统完成的，一旦使用这个框架，未来一旦遇到很难解决的问题，替换起来是非常麻烦的，而且项目一旦停止维护，后续的升级就只能靠你自己了，这种代价团队能否承受？当然，它已经停止维护了。
不过仅仅就技术方案而言，不可否认，这是一个很好的开源项目。
smallestWidth适配
smallestWidth适配，或者叫sw限定符适配。指的是Android会识别屏幕可用高度和宽度的最小尺寸的dp值（其实就是手机的宽度值），然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。
这种机制和上文提到的宽高限定符适配原理上是一样的，都是系统通过特定的规则来选择对应的文件。
举个例子，小米5的dpi是480,横向像素是1080px，根据px=dp(dpi/160)，横向的dp值是1080/(480/160),也就是360dp,系统就会去寻找是否存在value-sw360dp的文件夹以及对应的资源文件。
smallestWidth限定符适配和宽高限定符适配最大的区别在于，前者有很好的容错机制，如果没有value-sw360dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问题。
这套方案是上述几种方案中最接近完美的方案。
首先，从开发效率上，它不逊色于上述任意一种方案。根据固定的放缩比例，我们基本可以按照UI设计的尺寸不假思索的填写对应的dimens引用。
我们还有以375个像素宽度的设计稿为例，在values-sw360dp文件夹下的diemns文件应该怎么编写呢？这个文件夹下，意味着手机的最小宽度的dp值是360，我们把360dp等分成375等份，每一个设计稿中的像素，大概代表smallestWidth值为360dp的手机中的0.96dp，那么接下来的事情就很简单了，假如设计稿上出现了一个10px*10px的ImageView,那么，我们就可以不假思索的在layout文件中写下对应的尺寸。
而这种diemns引用，在不同的values-swdp文件夹下的数值是不同的，比如values-sw360dp和values-sw640dp,
当系统识别到手机的smallestWidth值时，就会自动去寻找和目标数据最近的资源文件的尺寸。
获取设备最小宽度代码：
DisplayMetrics dm = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dm);
int heightPixels = dm.heightPixels;
int widthPixels = dm.widthPixels;
float density = dm.density;
//手机高度dp值 = 手机实际高度像素px / 手机屏幕密度比
float heightDP = heightPixels / density;
//手机宽度dp值 = 手机实际宽度像素px / 手机屏幕密度比
float widthDP = widthPixels / density;
float smallestWidthDP;
if(widthDP < heightDP) {
smallestWidthDP = widthDP;
}else {
smallestWidthDP = heightDP;
}比如你的手机宽度是360dp，高度是640dp。那么无论是横屏还是竖屏时，程序运行时都会寻找values-sw360dp的目录(如果有)来作用在UI上。而不会是竖屏使用values-sw360dp，横屏时使用values-sw640dp了，自己实验。
如果你不希望这个结果，那么你可以选择values-w<N>dp的目录方式，具体参考上面官网文档说明，自己实验。
为什么选择 smallestWidth 限定符适配？
既然原理都一样，都需要多套 dimens.xml 文件，那为什么要选择 smallestWidth 限定符适配呢？
- 屏幕分辨率限定符适配是根据屏幕分辨率的，Android 设备分辨率一大堆，而且还要考虑虚拟键盘，这样就需要大量的 dimens.xml文件。因为无论手机屏幕的像素多少，密度多少，90% 的手机的最小宽度都为 360dp，所以采用 smallestWidth限定符适配只需要少量 dimens.xml 文件即可。
- 屏幕分辨率限定符适配采用的是 px 单位，而 smallestWidth 限定符适配采用的单位是 dp 和 sp，dp 和 sp是google 推荐使用的计量单位。又由于很多应用要求字体大小随系统改变，所以字体单位使用 sp 也更灵活。
- 屏幕分辨率限定符适配需要设备分辨率与 values-xx 文件夹完全匹配才能达到适配，而 smallestWidth 限定符适配寻找dimens.xml 文件的原理是从大往小找，例如设备的最小宽度为 360dp，就会先去找 values-360dp，发现没有则会向下找values-320dp，如果还是没有才找默认的 values 下的 demens.xml文件，所以即使没有完全匹配也能达到不错的适配效果。
使用步骤
1、以设计图最小宽度（单位为 dp）作为基准值，生成所有设备对应的 dimens.xml 文件
生成这些文件当然不会手动去写，网上已经有大神 android阿杜 提供了自动生成工具。
工具使用步骤：
1在 Android Studio 中安装 ScreenMatch 插件，如图：
2在项目的默认 values 文件夹中需要一份 dimens.xml 文件
3执行生成 插件安装好后，在项目的任意目录或文件上右键，选择 ScreenMatch 选项。如下图：
然后选择在哪个 module 下执行适配。即基于哪个 module 下的 res/values/dimens.xml 文件作为基准 dimens.xml 文件，生成的其他尺寸 dimens.xml 文件放在哪个 module 下。例如选择 app，然后点击 OK ，出现如下界面表示生成文件成功。如下图：
然后再看看 res 目录下会自动生成一堆 dimens.xml 文件，如下图：
通过上面的步骤就已经生成了所有设备对应的 dimens.xml 文件。
根据设计图填写最小宽度基准值，并填写需要适配的设备最小宽度 dp 值
步骤 3 是以插件默认的最小宽度基准值为 360dp，适配的设备最小宽度为
384,392,400,410,411,432,480,533,592,600,640,662,720,768,800,811,820,960,961,1024,1280,1365（包含了平板和 TV ）生成的文件，但实际情况要根据设计图和需求设置。
例如设计图的最小宽度为 375dp，则需要更改最小宽度基准值为 375dp。如果项目只需要适配手机的话，适配的设备最小宽度保留 320,360,384,392,400,410,411,480 即可。
以上修改需要在配置文件里修改，即screenMatch.properties 文件，该配置文件是执行完上面第 3 步后自动生成在项目的跟目录下的。如下图：
打开配置文件，修改下图中 1、3、4 的值即可。(图中单位均为 dp)
1：最小宽度基准值，填写设计图的最小宽度值即可。
2：插件默认适配的最小宽度值，即默认情况下会生成如下值的 dimens.xml 文件。
3：需要适配的最小宽度值，即你想生成哪些 dimens.xml 文件。
4：忽略不需要适配的最小宽度值，即忽略掉插件默认生成的 dimens.xml 文件。
配置文件修改完成后，重新执行第 3 步，生成新的 dimens.xml 文件。
当然！如果你的设计图也是标准的 360dp，那么上面的步骤你可以忽略。直接创建 dimens.xml 文件到你的项目即可，默认的 values 文件夹下也需要一份。
通过插件ScreenMatch，会在根目录提供给一份dimens，将里面内容复制到values/dimens.xml中即可
2、根据设计图标注，在布局写上对应的值。
设计图标注多少 dp，布局中就写多少 dp ，非常方便！
大多数 UI 设计师提供设计图有如下几种方式： 上传到蓝湖：显示多少 dp 就写多少 dp。 psd 源文件：用像素大厨查看，显示多少dp 就写多少 dp（注意像素大厨需要选择与设计图对应的dpi 进行显示） dp 单位的设计图：标注多少 dp 就写多少 dp。
px单位的设计图：叫 UI 设计师标注为 dp 单位或跟她要 psd 源文件，如果都不行，那自己算吧！
举例：例如设计图上一个Button 的宽为 360dp，高为 50dp，字体大小为 15 sp，在布局中则这样使用：
代码中动态设置 dp 或 sp：
如果需要在代码中动态设置 dp 或 sp，则需要通过 getDimension()方法获取对应资源文件下的 dp 或 sp 值再设置。如下：
/*获取sp值*/
float pxValue = getResources().getDimension(R.dimen.sp_15);//获取对应资源文件下的sp值
int spValue = ConvertUtils.px2sp(this, pxValue);//将px值转换成sp值
mTvShowParams.setTextSize(spValue);//设置文字大小
/*获取dp值*/
float pxValue2 = getResources().getDimension(R.dimen.dp_360);//获取对应资源文件下的dp值
int dpValue = ConvertUtils.px2dp(this, pxValue2);//将px值转换成dp值3、如何根据设计提供的px标注图，转换为dimens.xml中的dimen变量？
*除以基准值360，压缩到手机可视范围内。
常规的，设计会给宽度为1080或720px的图。
我们假定以宽度755px的图为例。
已知，设计给的图尺寸宽高为755px-1265px，其中一个按钮的像素px值宽高为100px-50px，
怎么在基于360等份的手机上编写按钮的dp值呢？
高度先不说。
基于宽度，设计图755px，要压缩到dp_360的范围内。压缩比例=755/360=2.1(约)。
即设计图内的所有内容，都要压缩2.1倍，才能用上基于dp_360范围的变量。
按钮宽度压缩2.1倍，等于100/2.1=dp_48(约)(变量，不是具体的dp值)
类推，按钮高度，等于50/2.1=dp_24
上面计算的约等于，取整或四舍五入都可以，接近即可。
之所以建议设计给出的设计图为360的倍数，如720或1080，那是因为除以360基准值，得到的压缩比例为整数。那么后续我们在设置控件的宽高时就不用四舍五入得到近似值了。
4、基于宽度适配，忽略高度。
*基于宽度360等份的适配，高度自行使用ScrollView。
上面说到，基于设计图的宽度，压缩到360等份范围的手机屏幕内。
但是注意，设计图上的内容都保留了宽高比不变，即内容不会变形。
那么又有另外一个问题，由于保证了内容宽高比不变，是不是会有些手机的屏幕无法容纳整张设计图内容？
对。！！！！！你自己使用ScrollView滚动吧。我要是限制高度，那么在有些异形手机上必然会出现控件的高度挤压或拉伸。并且上例中，控件的高度计算就不能使用宽度的压缩比例了。这样就更复杂，或者适配出的效果会更恶心了。
总结
以设计图最小宽度（单位为 dp）作为基准值，利用插件生成所有设备对应的 dimens.xml 文件
根据设计图标注，标注多少 dp，布局中就写多少dp，格式为@dimen/dp_XX。
怎么适配其他 module?
问题：在项目的其他 module 中怎么实现适配？难道也要多套 dimens 文件？
解决：并不需要多套 dimens 文件，只需要在 values 文件夹下有一套与 app module 一样的 dimens 文件即可达到适配。因为经过编译，所有 module 中的 dimen 数据都会统一归类到主 module（即 app module）中的 values/dimens.xml 文件中了，然后系统又会根据你设置的值去找对应 values-swxxxdp 文件夹下的dimens.xml 文件中的值。
验证：在项目中建一个 module，然后随便取一个 dimens.xml 文件中的值进行打印，分别运行在不同 widthDP 的设备上（用模拟器即可）观察打印的结果发现确实是这样的。
常见问题汇总
为什么宽度适配了，高度有时候没有完全适配？
因为各种屏幕高宽比并不是固定的，有16:9、4:3，还有全面屏的19.5:9等等，如果强行将宽高都适配那只会导致布局变形。
例如一个控件的宽高为360dp和640dp，如果将它显示在宽高为360dp和640dp的设备上是正常铺满整个屏幕的，但是显示在宽高为360dp和780dp的设备上高度则不能铺满，如果你让高度铺满，而宽度又保持不变，那就会出现变形的情况。所以这也就是为什么目前市面上的屏幕适配方案只能以宽或高一个维度去适配，另一个方向用滑动或权重的方式去适配的原因。
那你为什么说高度也能适配呢？
这里说的高度也能适配指的是在不同分辨率和密度的手机上能达到等比缩放的适配，其他屏幕适配方案也是一样的。
如何同时适配横竖屏？
方案一：（不推荐）
计算出设备宽度和高度的dp值，然后生成对应的宽高 dimens.xml 文件。然后去掉所有 values-swXXXdp 目录上的s，即改为 values-wXXXdp。这样设备不管横竖屏都能找到对应的 values-wXXXdp 目录下的 dimens.xml 文件了。 虽然也能达到一定程度的适配，但是这样会增加很多 dimens.xml 文件，而且使用竖屏的设计图显示出来的效果也不够好。
方案二：（推荐）
因为横屏时宽高变化太大，想要横屏时也能完全适配，那就只能让设计师出一套横屏的设计图，然后单独写一套横屏的布局文件。
注意：smallestWidth 限定符适配的效果是让不同分辨率和密度的设备上能达到以设计图等比缩放的适配，如果设备与设计图相差太大时并不能达到很好的适配效果，需要单独出图，其他屏幕适配方案也是一样的。
如何适配平板、TV？
同横屏道理一样，平板、TV 与手机的宽高差距太大，想要平板、TV 也能完全适配，那就只能让设计师出一套平板、TV 的设计图，然后单独写一套平板、TV 的布局文件。
