Android系统发布十多年以来，关于Android的UI的适配一直是开发环节中最重要的问题，但是我看到还是有很多小伙伴对Android适配方案不了解。刚好，近期准备对糗事百科Android客户端设计一套UI尺寸适配方案，可以和小伙伴们详细的聊一聊这个问题。
Android适配最核心的问题有两个，其一，就是适配的效率，即把设计图转化为App界面的过程是否高效，其二如何保证实现UI界面在不同尺寸和分辨率的手机中UI的一致性。这两个问题都很重要，一个是保证我们开发的高效，一个是保证我们适配的成效；今天我们就这两个核心的问题来聊一聊Android的适配方案。
image
首先，大家都知道，在标识尺寸的时候，Android并不推荐我们使用px这个真实像素单位，因为不同的手机之间，分辨率是不同的，比如一个96*96像素的控件在分辨率越来越高的手机上会在整体UI中看起来越来越小。
image
出现类似于上图这样这样，整体的布局效果可能会变形，所以px这个单位在布局文件中是不推荐的。
dp直接适配
针对这种情况，Android推荐使用dp作为尺寸单位来适配UI.
那么什么是dp？dp指的是设备独立像素，以dp为尺寸单位的控件，在不同分辨率和尺寸的手机上代表了不同的真实像素，比如在分辨率较低的手机中，可能1dp=1px,而在分辨率较高的手机中，可能1dp=2px，这样的话，一个96*96dp的控件，在不同的手机中就能表现出差不多的大小了。那么这个dp是如何计算的呢？ 我们都知道一个公式： px = dp(dpi/160) 系统都是通过这个来判断px和dp的数学关系，
那么这里又出现了一个问题，dpi是什么呢？
dpi是像素密度，指的是在系统软件上指定的单位尺寸的像素数量，它往往是写在系统出厂配置文件的一个固定值。
我为什么要强调它是软件系统上的概念？因为大家买手机的时候，往往会听到另一个叫ppi的参数，这个在手机屏幕中指的也是像素密度，但是这个是物理上的概念，它是客观存在的不会改变。dpi是软件参考了物理像素密度后，人为指定的一个值，这样保证了某一个区间内的物理像素密度在软件上都使用同一个值。这样会有利于我们的UI适配。
比如，几部相同分辨率不同尺寸的手机的ppi可能分别是是430,440,450,那么在Android系统中，可能dpi会全部指定为480.这样的话，dpi/160就会是一个相对固定的数值，这样就能保证相同分辨率下不同尺寸的手机表现一致。
| ... | 1080*720 | 1920*1080 |
|---|---|---|
| dpi | 320 | 480 |
| dpi/160 | 2 | 3 |
而在不同分辨率下，dpi将会不同，比如：
| ... | 1080*720 | 1920*1080 |
|---|---|---|
| dpi | 320 | 480 |
| dpi/160 | 2 | 3 |
根据上面的表格，我们可以发现，720P,和1080P的手机，dpi是不同的，这也就意味着，不同的分辨率中，1dp对应不同数量的px(720P中，1dp=2px，1080P中1dp=3px)，这就实现了，当我们使用dp来定义一个控件大小的时候，他在不同的手机里表现出相应大小的像素值。
image
我们可以说，通过dp加上自适应布局和weight比例布局可以基本解决不同手机上适配的问题，这基本是最原始的Android适配方案。
这种方式存在两个小问题，第一，这只能保证我们写出来的界面适配绝大部分手机，部分手机仍然需要单独适配，为什么dp只解决了90%的适配问题，因为并不是所有的1080P的手机dpi都是480，比如Google 的Pixel2（1920*1080）的dpi是420，也就是说，在Pixel2中，1dp=2.625px,这样会导致相同分辨率的手机中，这样，一个100dp*100dp的控件，在一般的1080P手机上，可能都是300px,而Pixel 2 中 ，就只有262.5px,这样控件的实际大小会有所不同。
为了更形象的展示，假设我们在布局文件中把一个ImageView的宽度设置为360dp,那么在下面两张图中表现是不一样的：
图一是1080P,480dpi的手机，图二是1080P,420dpi的手机
1080P,480dpi的手机
1080P,420dpi的手机
从上面的布局中可以看到，同样是1080P的手机，差异是比较明显的。在这种情况下，我们的UI可能需要做一些微调甚至单独适配。
第二个问题，这种方式无法快速高效的把设计师的设计稿实现到布局代码中，通过dp直接适配，我们只能让UI基本适配不同的手机,但是在设计图和UI代码之间的鸿沟，dp是无法解决的，因为dp不是真实像素。而且，设计稿的宽高往往和Android的手机真实宽高差别极大，以我们的设计稿为例，设计稿的宽高是375px*750px，而真实手机可能普遍是1080*1920,
那么在日常开发中我们是怎么跨过这个鸿沟的呢？基本都是通过百分比啊，或者通过估算，或者设定一个规范值等等。总之，当我们拿到设计稿的时候，设计稿的ImageView是128px*128px，当我们在编写layout文件的时候，却不能直接写成128dp*128dp。在把设计稿向UI代码转换的过程中，我们需要耗费相当的精力去转换尺寸，这会极大的降低我们的生产力，拉低开发效率。
宽高限定符适配
为了高效的实现UI开发，出现了新的适配方案，我把它称作宽高限定符适配。简单说，就是穷举市面上所有的Android手机的宽高像素值：
image
设定一个基准的分辨率，其他分辨率都根据这个基准分辨率来计算，在不同的尺寸文件夹内部，根据该尺寸编写对应的dimens文件。
比如以480x320为基准分辨率
- 宽度为320，将任何分辨率的宽度整分为320份，取值为x1-x320
- 高度为480，将任何分辨率的高度整分为480份，取值为y1-y480
那么对于800*480的分辨率的dimens文件来说，
x1=(480/320)*1=1.5px
x2=(480/320)*2=3px
...
image
这个时候，如果我们的UI设计界面使用的就是基准分辨率，那么我们就可以按照设计稿上的尺寸填写相对应的dimens引用了,而当APP运行在不同分辨率的手机中时，这些系统会根据这些dimens引用去该分辨率的文件夹下面寻找对应的值。这样基本解决了我们的适配问题，而且极大的提升了我们UI开发的效率，
但是这个方案有一个致命的缺陷，那就是需要精准命中才能适配，比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。而使用默认的尺寸的话，UI就很可能变形，简单说，就是容错机制很差。
不过这个方案有一些团队用过，我们可以认为它是一个比较成熟有效的方案了。
UI适配框架（已经停止维护）
鸿洋大佬的适配方案的项目也来自于宽高限定符方案的启发。
使用方法也很简单：
第一步：
在你的项目的AndroidManifest中注明你的设计稿的尺寸。
<meta-data android:name="design_width" android:value="768">
</meta-data>
<meta-data android:name="design_height" android:value="1280">
</meta-data>
第二步：
让你的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的文件夹以及对应的资源文件。
image
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文件中写下对应的尺寸。
image
而这种diemns引用，在不同的values-sw<N>dp文件夹下的数值是不同的，比如values-sw360dp和values-sw400dp,
image
image
当系统识别到手机的smallestWidth值时，就会自动去寻找和目标数据最近的资源文件的尺寸。
其次，从稳定性上，它也优于上述方案。原生的dp适配可能会碰到Pixel 2这种有些特别的手机需要单独适配，但是在smallestWidth适配中，通过计算Pixel 2手机的的smallestWidth的值是411，我们只需要生成一个values-sw411dp(或者取整生成values-sw410dp也没问题)就能解决问题。
smallestWidth的适配机制由系统保证，我们只需要针对这套规则生成对应的资源文件即可，不会出现什么难以解决的问题，也根本不会影响我们的业务逻辑代码，而且只要我们生成的资源文件分布合理，，即使对应的smallestWidth值没有找到完全对应的资源文件，它也能向下兼容，寻找最接近的资源文件。
当然，smallestWidth适配方案有一个小问题，那就是它是在Android 3.2 以后引入的，Google的本意是用它来适配平板的布局文件（但是实际上显然用于diemns适配的效果更好），不过目前所有的项目应该最低支持版本应该都是4.0了（糗事百科这么老的项目最低都是4.0哦），所以，这问题其实也不重要了。
福利赠送
生成diemns文件的过程以及数据计算方法上面已经讲清楚了，大家完全可以自己去生成这些文件，我在这里附赠生成values-sw<N>的项目代码，大家直接拿去用，是Java工程。点击这里获取项目地址
网友评论
(480 / 160) = 640.那么要做适配的话,是不是生成640 - 790 之间的文件尺寸,790是我按 640 + 150自己得出的. 但是按文中的意思,每台1920 x 1080 的dpi 不一定是480.那我应该如何准确的生成屏幕横屏时的文件呢?
/**
* 设计稿尺寸(根据自己设计师的设计稿的宽度填入)
*/
private static final int DESIGN_WIDTH = 375;
大概明白了这个方案，我看有很多人没理解，以下是我的理解，若有不对请指出
简单拿今日头条的方案做对比，今日头条的方案， 核心原理在于:
当前设备总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density
density 的意思就是 1 dp 占当前设备多少像素
假设设计图总宽度为 375 dp, 设备总宽度为 1080 px，根据上面的公式 1080 / 375 = 2.88 (density)
一个 View 在设计图上的尺寸是 50dp * 50dp，所以在所有总宽度为 1080 px 的设备上，这个 View 的高宽都是 50 * 2.88 = 144 px (根据公式 dp * density = px)
这个 View 的高宽，在设计图上占总宽度的比例是 (50 / 375 = 0.1333)，在实际设备上占实际设备总宽度的比例是 (144 / 1080 = 0.1333)，该 View 在设计图和实际设备上的比例是相同，所以完成了等比例缩放，该适配方案有效
至于上文中提到的某些设备总宽度为 1080 px，但是 dpi 不同的设备，其实这个方案根本没有根据 dpi 求出 density，是根据自己的公式求出的 density， 所以这对今日头条的方案没有影响
在 1920*1080，dpi 为 480 的设备上，设计图上 50 * 50 的 view 最终高宽都为 144 px
在 1920*1080，dpi 为 420 的设备上，设计图上 50 * 50 的 view 最终高宽都为 144.375 px
可以看到虽然 dpi 不一样但最后的结果却是差不多的，所以即使在高宽一样，dpi 不一样的设备上 smallestWidth 方案也能完成等比例适配，所以这个方案是可行的
根据我上面的计算，可以看出两个方案的最终原理其实差别不是太大，都是通过各种 dp，px，dpi 的换算来达到设计图的等比例缩放
今日头条精确度是最完美的，但有一个问题所有地方都是一刀切，会影响老项目和三方库（可以选择某个 Activity 取消适配来缓解这个问题），但是使用起来非常简单，根本不需要什么成本，侵入性也低
smallestWidth 的方案精确度稍微低一点，你需要使用了就自行引用 dimens，效果和范围都可控，不会像今日头头条一样一刀切，影响其他不需要的地方，使用上比今日头条的方案投入成本更高，侵入性略高，某些页面要实现以高为基准进行适配，或者项目中一些页面需要以高为基准，一些又要一宽为基准，实现上应该比较复杂
所以这两个方案都是现阶段比较棒的方案，都可以达到等比例适配的效果，大家需要在投入成本和收益之间做出取舍，选择一个目前最适合自己项目的方案
smallestWidth 方案的核心原理在于:
当前设备总宽度 （单位为 dp）/ 设计图总宽度 (至于是 dp 还是 px 都不重要) = value (设计图上每个单位占当前设备多少 dp)
然后根据这个 value 算出对应资源文件的 dimens，然后在项目中引用 dimens，系统会选择最合适的宽度的资源文件下的 dimens
还是以上面的例子:
假设设计图总宽度为 375，设备总宽度为 360 dp， 根据上面的公式 360 / 375 = 0.96 (意思是在当前设备上设计图的一个单位等于 0.96 dp，求出的结果也与上文中的截图一致)
一个 View 在设计图上的尺寸是 50 * 50，使用这个方案我们直接在 layout 中引用 @dimen/qb_px_10，系统会选择 sw360dp 的资源文件，根据公式 50 * 0.96 = 48 dp，在当前设备上这个 View 的高宽都为 48 dp
然后系统会根据公式 (dp * density = px) 把 dp 换算成 px
测试设备总宽度为 1080 像素，dpi 为480，根据公式 dpi / 160 = density，480 / 160 = 3，求出 density 等于 3
48 dp 会被系统换算成 144 px (48 * 3 = 144)，这个这个 View 的最终高宽都是 144 px
这个 View 的高宽，在设计图上占总宽度的比例是 (50 / 375 = 0.1333)，在实际设备上占实际设备总宽度的比例是 (144 / 1080 = 0.1333)，该 View 在设计图和实际设备上的比例是相同，所以完成了等比例缩放
但这个方案由于没有自己强制更改 density，所以是系统根据 dpi 来求出 density，然后在根据公式 (dp * density = px) 来将 dp 换算成 px，所以这个方案的效果会受 dpi 影响的
上文中提到过，同样的 1920*1080 的设备，虽然大部分的 dpi 为 480，但有些设备的 dpi 可能是不一样，比如 Pixel 2 的 dpi 为 420
上面求出的 144 px 是在 1920*1080，dpi 为 480 的设备上
现在我们试试高宽同样为 1920*1080，但是 dpi 为 420 的 Pixel 2 手机上是否也能完成等比例缩放
根据公式 px / (dpi / 160) = dp, 1080 / (420 / 160) = 411.429 dp
设备总宽度为 411.429 dp，使用 smallestWidth 方案生成 sw411dp 对应的资源文件
根据公式 411 / 375 = 1.10，在当前 dpi 为 420 的设备上设计图的一个单位等于 1.10 dp
一个在设计图上 50 * 50 的 View，在 dpi 为 420 的设备上，使用 sw411dp 得到的实际尺寸是 50 * 1.10 = 55 dp
然后系统会根据公式 dp * density = px，把 dp 换算成 px
55 * （420 / 160） = 144.375 px，这个 View 的最终高宽都是 144.375 px
我不太明白怎么去生成文件，您可以再给我讲解一下嘛？
final float targetDensity = appDisplayMetrics.widthPixels / 360;
结果都是整数，感觉对最终的适配有些影响，能改成appDisplayMetrics.widthPixels*1.0f / 360 吗
DisplayMetrics metric = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(metric);
int width = metric.widthPixels; // 屏幕宽度（像素）
int height = metric.heightPixels; // 屏幕高度（像素）
float density = metric.density; // 屏幕密度
这个获取的不会变化吗？
在 1920*1080，dpi 为 480 的设备上，设计图上 50 * 50 的 view 最终高宽都为 144 px
在 1920*1080，dpi 为 420 的设备上，设计图上 50 * 50 的 view 最终高宽都为 144.375 px
可以看到虽然 dpi 不一样但最后的结果却是差不多的，所以即使在高宽一样，dpi 不一样的设备上 smallestWidth 方案也能完成等比例适配，所以这个方案是可行的
根据我上面的计算，可以看出两个方案的最终原理其实差别不是太大，都是通过各种 dp，px，dpi 的换算来达到设计图的等比例缩放
今日头条精确度是最完美的，但有一个问题所有地方都是一刀切，会影响老项目和三方库（可以选择某个 Activity 取消适配来缓解这个问题），但是使用起来非常简单，根本不需要什么成本，侵入性也低
smallestWidth 的方案精确度稍微低一点，你需要使用了就自行引用 dimens，效果和范围都可控，不会像今日头头条一样一刀切，影响其他不需要的地方，使用上比今日头条的方案投入成本更高，侵入性略高，某些页面要实现以高为基准进行适配，或者项目中一些页面需要以高为基准，一些又要一宽为基准，实现上应该比较复杂
所以这两个方案都是现阶段比较棒的方案，都可以达到等比例适配的效果，大家需要在投入成本和收益之间做出取舍，选择一个目前最适合自己项目的方案
smallestWidth 方案的核心原理在于:
当前设备总宽度 （单位为 dp）/ 设计图总宽度 (至于是 dp 还是 px 都不重要) = value (设计图上每个单位占当前设备多少 dp)
然后根据这个 value 算出对应资源文件的 dimens，然后在项目中引用 dimens，系统会选择最合适的宽度的资源文件下的 dimens
还是以上面的例子:
假设设计图总宽度为 375，设备总宽度为 360 dp， 根据上面的公式 360 / 375 = 0.96 (意思是在当前设备上设计图的一个单位等于 0.96 dp，求出的结果也与上文中的截图一致)
一个 View 在设计图上的尺寸是 50 * 50，使用这个方案我们直接在 layout 中引用 @dimen/qb_px_10，系统会选择 sw360dp 的资源文件，根据公式 50 * 0.96 = 48 dp，在当前设备上这个 View 的高宽都为 48 dp
然后系统会根据公式 (dp * density = px) 把 dp 换算成 px
测试设备总宽度为 1080 像素，dpi 为480，根据公式 dpi / 160 = density，480 / 160 = 3，求出 density 等于 3
48 dp 会被系统换算成 144 px (48 * 3 = 144)，这个这个 View 的最终高宽都是 144 px
这个 View 的高宽，在设计图上占总宽度的比例是 (50 / 375 = 0.1333)，在实际设备上占实际设备总宽度的比例是 (144 / 1080 = 0.1333)，该 View 在设计图和实际设备上的比例是相同，所以完成了等比例缩放
但这个方案由于没有自己强制更改 density，所以是系统根据 dpi 来求出 density，然后在根据公式 (dp * density = px) 来将 dp 换算成 px，所以这个方案的效果会受 dpi 影响的
上文中提到过，同样的 1920*1080 的设备，虽然大部分的 dpi 为 480，但有些设备的 dpi 可能是不一样，比如 Pixel 2 的 dpi 为 420
上面求出的 144 px 是在 1920*1080，dpi 为 480 的设备上
现在我们试试高宽同样为 1920*1080，但是 dpi 为 420 的 Pixel 2 手机上是否也能完成等比例缩放
根据公式 px / (dpi / 160) = dp, 1080 / (420 / 160) = 411.429 dp
设备总宽度为 411.429 dp，使用 smallestWidth 方案生成 sw411dp 对应的资源文件
根据公式 411 / 375 = 1.10，在当前 dpi 为 420 的设备上设计图的一个单位等于 1.10 dp
一个在设计图上 50 * 50 的 View，在 dpi 为 420 的设备上，使用 sw411dp 得到的实际尺寸是 50 * 1.10 = 55 dp
然后系统会根据公式 dp * density = px，把 dp 换算成 px
55 * （420 / 160） = 144.375 px，这个 View 的最终高宽都是 144.375 px
大概明白了这个方案，我看有很多人没理解，以下是我的理解，若有不对请指出
简单拿今日头条的方案做对比，今日头条的方案， 核心原理在于:
当前设备总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density
density 的意思就是 1 dp 占当前设备多少像素
假设设计图总宽度为 375 dp, 设备总宽度为 1080 px，根据上面的公式 1080 / 375 = 2.88 (density)
一个 View 在设计图上的尺寸是 50dp * 50dp，所以在所有总宽度为 1080 px 的设备上，这个 View 的高宽都是 50 * 2.88 = 144 px (根据公式 dp * density = px)
这个 View 的高宽，在设计图上占总宽度的比例是 (50 / 375 = 0.1333)，在实际设备上占实际设备总宽度的比例是 (144 / 1080 = 0.1333)，该 View 在设计图和实际设备上的比例是相同，所以完成了等比例缩放，该适配方案有效
至于上文中提到的某些设备总宽度为 1080 px，但是 dpi 不同的设备，其实这个方案根本没有根据 dpi 求出 density，是根据自己的公式求出的 density， 所以这对今日头条的方案没有影响