‘壹’ android app界面设计规范(dpi,dp,px等)
PPI(Pixels per inch)：每英寸所拥有的像素数，即像素密度。
DPI(dots per inch)：即每英寸上，所能印刷的网点数，一般称为像素密度。ppi计算公式：ppi = 屏幕对角线像素数/屏幕对角线英寸数，通过勾股定理计算屏幕对角线像素数。
Screen Size(屏幕尺寸)：手机屏幕尺寸大小，如3英寸、4英寸、4.3英寸、5.7英寸，指的是对角线的长度。
DIP（device independent pixel）：即dip/dp，设备独立像素。 1px = 1dp density(由dpi决定)
Resolution(分辨率)：指手机屏幕垂直和水平方向上的像素个数。eg分辨率480 800，指该设备垂直方向有800个像素点，水平方向有480个像素点。
px(Pixel像素)：相同像素的ui，在不同分辨率的设备上效果不同。在小分辨率设备上会放大导致失真，大分辨率上被缩小。
Android Design里把主流设备的 dpi 归成了四个档次： 120 dpi、160 dpi、240 dpi、320 dpi ，具体见如下表格。
实际开发当中，我们经常需要对这几个尺寸进行相互转换（比如先在某个分辨率下完成设计，然后缩放到其他尺寸微调后输出），一般按照 dpi 之间的比例即 2:1.5:1:0.75 来给界面中的元素来进行尺寸定义。
也就是说如果以 160 dpi 作为基准的话，只要尺寸的 DP 是 4 的公倍数，XHDPI 下乘以 2，HDPI 下乘以 1.5，LDPI 下乘以 0.75 即可满足所有尺寸下都是整数 pixel 。但假设以 240 dpi 作为标准，那需要 DP 是 3 的公倍数，XHDPI 下乘以 1.333，MDPI 下乘以 0.666 ，LDPI 下除以 2。而以 LDPI 和 XHDPI 为基准就更复杂了。同时第一款Android设备（HTC的T-Mobile G1）是属于160dpi的。鉴于以上各种原因， 标准dpi=160
谷歌官方对dp的解释如下：
A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way.
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.
简单来说，以160dpi的设备为准，该设备上1dp = 1px；如果屏幕密度大，1dip代表的px就多，比如在320dpi的屏幕上，1dip=2px(即1dp代表2个像素)。在app开发时，最好用dp来做界面的布局，以保证适配不同屏幕密度的手机。
dp和px的换算公式：
我的理解，该公式表示px的数值等于dp的数值*（设备dpi/160）
注意，px、dp是单位，但density没单位。
applyDimension的源码如下，可参考：
android的尺寸众多，建议使用分辨率为 720x1280 的尺寸设计。这个尺寸 720x1280中显示完美，在 1080x1920 中看起来也比较清晰；切图后的图片文件大小也适中，应用的内存消耗也不会过高。
app启动图标为48*48dp，对应各dpi设备，图像资源像素如下：
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|48 48px|72 72px|94 96px|144px 144px|
操作栏图标为32*32dp，对应各dpi设备，图像资源像素如下：其中图形区域尺寸是24*24dp，可参考平时ui切图会有部分留白。
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|32 32px|48 48px|64 64px|96px 96px|
通知栏图标为24*24dp，对应各dpi设备，图标像素如下：
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|24 24px|36 36px|48 48px|72px 72px|
某些场景需要用到小图标，大小应当是16*16dp，其中图形区域尺寸12*12dp。
| mdpi | hdpi | xhdpi | xxhdpi |
| ---:| ---: | ---:| ---:| ---:|
|16 16px|24 24px|32 32px|48px 48px|
‘贰’ android dp和dip的区别
dp: Density-independent Pixels
一个抽象的单元，基于屏幕的物理密度。
（dp和dip的意义相同，所以不用区别对待）。
这些单元是相对于160dpi（dots per inch）的屏幕说的，在160dpi的屏幕上，1dp粗略地等于1px。
当运行在更高密度的屏幕上的时候，要绘制1dp的像素数量会放大一个比例，这个比例就是和屏幕密度（dpi）相关。
类似的，在一个低密度的屏幕上，像素数目会缩小一个比例。
dp到px的这个比例将会随着屏幕的密度变化，而不是直接的比例关系。
用dp单位，而不是px，是一种简单的屏幕密度适配解决方式。
换句话说，它提供了一种方式，可以在多种设备上维持真实尺寸一致性。
sp：Scale-independent Pixels
这个有点像dp单位，但是它也根据用户的字体设置（font preference）缩放尺寸。
建议用这种尺寸单位来标注字体尺寸，这样它们将会因为屏幕密度和用户设定而调整。
pt：Points 1/72 inch（英寸），根据屏幕的物理尺寸。
px: Pixels
相应于真实的像素。
这种单位不被建议，因为真实的表达会根据设备的不同相差很远。
每个设备上每英寸的像素数不同（密度不同），并且屏幕上总的像素数也不同（整体大小不同）。
‘叁’ Android屏幕适配-应用篇
Android屏幕适配-基础篇
Android屏幕适配-应用篇
从两个大方面阐述一下Android的屏幕适配：
Android推荐使用dp作为尺寸单位来适配UI ，通过dp加上自适应布局和weight比例布局可以基本解决不同手机上适配的问题，这基本是最原始的Android适配方案。
缺点 ：
（1）这种方案只能保证我们写出来的界面适配绝大部分手机，部分手机仍然需要单独适配，但dpi的不同，还是会存在差异。
（2）一般的设计稿都是以px为单位的，所以我们在写layout文件的时候需要将px转为dp，影响开发效率。
为了高效的实现UI开发，出现了新的适配方案，我把它称作宽高限定符适配。简单说，就是穷举市面上所有的Android手机的宽高像素值，设定一个基准的分辨率，其他分辨率都根据这个基准分辨率来计算，在不同的尺寸文件夹内部，根据该尺寸编写对应的dimens文件:
鸿洋大神的作品 ，使用也超级简单，核心功能就是在绘制的时候在onMeasure里面做变换，重新计算px。
缺点 ：我们自定义的控件可能会被影响或限制，可能有些特定的控件（框架没有做适配的控件），需要单独适配。
小结：上述几种适配方案都是实际开发中用过的方案，但随着技术不断的更新，出现了更好的适配方案。
实现原理 ：Android会识别屏幕可用高度和宽度的最小尺寸的dp值（ 其实就是手机的宽度值 ），然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。
sw限定符适配 和 宽高限定符适配 类似，区别在于，前者有很好的容错机制，如果没有value-sw360dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问题。
优点: 1.非常稳定，极低概率出现意外
2.不会有任何性能的损耗
3.适配范围可自由控制，不会影响其他三方库
缺点 ：就是多个dimens文件可能导致apk变大，几百k。
附件： 生成sw文件的工具
实现原理 ： 修改系统的density值 （核心）
今日头条适配是以设计图的宽或高进行适配的，适配最终是改变系统density实现的。
过程：
AndroidAutoSize 是基于今日头条适配方案，该开源库已经很大程度上解决了今日头条适配方案的两个缺点，可以对activity，fragment进行取消适配。也是目前我的项目中所使用的适配方案。
使用也非常简单只需两步：
（1）引入：
（2）在 AndroidManifest 中填写全局设计图尺寸 (单位 dp)，如果使用副单位，则可以直接填写像素尺寸，不需要再将像素转化为 dp，详情请查看 demo-subunits
‘肆’ Android中常见的单位ppi,dp,dpi,sp,px
在android 开发过程中，我们使用的单位比较少，一般情况下在描述字体大小的时候我们通常用sp，而在设置间距的时候我们用dp，除此之外很少再用到其他单位，而且很多时候我们用着用着就习惯了，也不去探究为什么这么写，可不可以用其他单位，每个单位到底代表着什么意思，所以说，习惯真的很可怕呀。今天，我们就来一探究竟，看看这些单位背后的含义。
像素即是屏幕上显示数据的最基本的点，在PS里面也是其最根本的单位，所有的图形都是在此基础上生成的，平时我们经常讲的手机屏幕分辨率就是以像素作为单位的，比如在android中我们经常说的手机像素是1080X1920，其实它所表达的意思是在该手机上面在横向上面有1080个像素点，在纵向上有1920个像素点。
在android中用来形式字体大小的单位，正常情况下会按照手机系统设置的文本大小来显示文字，但是同时也会与系统设置的文本保持一致，比如在有些老年机上面为了更好的操作手机有些人会将字体设置为较大字体，这个时候使用sp作为单位的字体也会随之变大，但是如果将字体大小的单位设置为dp，则不会随着系统字体的变化而变化。
在每次的手机厂商新品发布会上，我们都会听到关于手机的介绍，比如手机的屏幕分辨率，多大尺寸等等。而当我们知晓一个手机的屏幕分辩率和手机尺寸的时候，就可以计算出手机的物理像素密度，其计算公式为：
需要注意的是，PPI是Android手机物理像素密度，而非在Android开发过程中我们经常说到的像素密度。
屏幕密度与dpi密切相关，dpi是每英寸的点数。也就是说，密度越大，每英寸内容纳的点数就越多。
在android.util包下有个DisplayMetrics类可以获得密度相关的信息。最重要的是densityDpi这个成员，它有如下几个常用值：
DENSITY_LOW = 120
DENSITY_MEDIUM = 160 //默认值
DENSITY_TV = 213 //TV专用
DENSITY_HIGH = 240
DENSITY_XHIGH = 320
DENSITY_400 = 400
DENSITY_XXHIGH = 480
DENSITY_XXXHIGH = 640
dpi的值主要是通过displayMetrics获取的，获取方式为：
val densityDpi = resources.displayMetrics.densityDpi。
dp和dip是一样的，设备独立像素，这个和设备硬件有关，不同设备有不同的显示效果。而通常在做android项目的时候，为了适配市场上面众多的手机屏幕分辩率，我们一般都会采用dp。dp是Android基于物理设备的PPI抽象出来的一个单位。它是以160dpi的屏幕为基准定义的，在160dpi的屏幕上1dp=1px，那么由此我们就可以得出其计算公式：
换算公式：1dp = （屏幕ppi/160）px或者是px = （屏幕ppi/160）*1dp。举个例子：假设ppi = 320，那么1dp = 2px。
下面我们来演练一下：
如图所示，手机的屏幕分辩率为1080X1920，尺寸为5寸，从而计算得出PPI的值为440，再通过PPI计算出1dp 约等于3px。假设现在美工给的图上面有一个a图标，距离顶部的距离为30px，那么根据最终我们的换算结果可知，我们设置为10dp就可以达到完美的显示效果。
‘伍’ Android 关于"尺寸"的那些事(dp,dip,sp,pt,px...)
屏幕大小：屏幕大小是手机对角线的物理尺寸，以英寸inch为单位。比如我的Mix 2手机屏幕大小为5.99 inches，意味着我的屏幕对角线长度为5.99inches = 5.99 * 2.54 = 15.2146cm
分辨率：屏幕的像素点数，一般表示为a*b。例如某手机分辨率为21601080，意味着手机屏幕的竖直方向（长）有2160个像素点，水平方向（宽）有1080个像素点。
px ：Pixels ，像素；对应屏幕上的实际像素，是画面中最小的点（单位色块），像素大小没有固定长度值，不同设备上1个单位像素色块大小不同。
这么说可能有点陌生，用屏幕分辨率来说，今年流行起来的“全面屏”分辨率是 2160*1080，但是你也可以发现，虽然很多全面屏手机分辨率一样，但是明显看得出来屏幕大小不一样，这也解释了“不同设备像素色块大小是不同的”。
pt ：1pt＝1/72 inch，用于印刷业，非常简单易用；
dpi ：Dots Per Inch，每英寸点数；详见ppi
ppi ：Pixels Per Inch，每英寸像素数；数值越大显示越细腻。计算式：ppi = 屏幕对角线像素数 / 屏幕对角线长度。
还是举全面屏的例子，分辨率2160*1080，屏幕大小是5.9inches，勾股定理可以得到对角线像素数大约是2415，那么ppi = 2415 / 5.99 = 403.
事实上dpi 和 ppi 一定程度上可以划等号，都表示像素密度，计算方式完全一致，只不过使用场景不一样。dpi中的dots点属于打印或印刷等领域，例如drawable 文件对应的就是dpi，而ppi中的pixel属于屏幕显示等领域
dp/dip : Density-independent Pixels，密度无关像素 - 基于屏幕物理密度的抽象单位。1dp等于 160 dpi 屏幕上的dpx，这是 系统为“中”密度屏幕假设的基线密度。在运行时，系统 根据使用中屏幕的实际密度按需要以透明方式处理 dp 单位的任何缩放 。dp 单位转换为屏幕像素很简单：px = dp * (dpi / 160)。 例如，在 240 dpi 屏幕上，1 dp 等于 1.5 物理像素。在定义应用的 UI 时应始终使用 dp 单位 ，以确保在不同密度的屏幕上正常显示 UI。
如果看完文章还是觉得很懵，那么可以直接记住： 1dp单位在设备屏幕上总是等于1/160 inch。
sp ：Scale-independent Pixels ，与 dp 单位相似，也会根据用户的字体大小偏好进行缩放。
首先我们放上源码中对尺寸单位的转换
可以看到，输入值类型为dp时，返回 value * DisplayMetrics.density，到这里我们可能会发懵：嗯？不对啊，前面我们不是通过px 和 dp 的换算公式来计算的么，怎么这里就简简单单乘了一个DisplayMetrics.density？不要慌，我们先看看源码中对DisplayMetrics.density的介绍。
源码注释中说到“在160dpi的屏幕下，density的值为1，而在120dpi的屏幕下，density的值为0.75”，我们可以大胆的猜测一下，120dpi下的density=0.75的原因是120dpi * 1 /160dpi=0.75。实际上，也就是这么回事。我们下面会仔细的分析。
需要补充一下，通常意义上Android 屏幕的密度，指的是像素密度dpi/ppi，对应于源码中的DisplayMetrics.densityDpi。
为什么引入dp？
Android 引入了dp这一单位，使得不论多大屏幕，多大dpi，显示的效果始终保持一致。
但是根据前面我们提到的px与dp的换算公式px = dp * (dpi / 160)，很显然，由于相同分辨率但不同屏幕大小的设备dpi是不同的，导致px和dp的基本不存在一个固定的换算关系，为了方便屏幕适配，Android设置了6个通用的密度，换算px与dp时采取通用密度计算，而非设备实际的密度。
以下为6种通用密度，以及其最小的分辨率
得到上面通用密度之后，我们换算dp与px多了一种简便方式。前面我们提到Android将mdpi作为基准，此时1px = 1dp，又有px = dp * (dpi / 160)，所以我们可以很容易的得到以下换算：
还记不记得前面源码中的density属性，实际上DisplayMetrics.density = dpi / 160 ，表示的就是在某个通用密度下dp与px的换算比（1dp/1px的值）
这部分其实和程序员自身已经关系不大了，毕竟参与工作之后这些都是UI人员的活儿了。不过鉴于现在我还只是一枚在校生，还是记下来以免自己遗漏吧。
建议在xhdpi中作图
原因嘛，首先现在主流分辨率是1080p，以及最近流行起来的全面屏18:9，而xhdpi对应720p，向低dpi兼容自然没问题，即便在xxhdpi中显示，也会有个不错的效果。而如果以1920*1080作图，显然图片素材占用的内存很大，而且也会增大应用安装包的大小。
只有一个原则：资源放入对应dpi的文件夹中，Android会机智的加载合适的资源。
以drawable资源为例：
我们平时开发小项目&对UI要求不高时，只使用一套xhdpi的资源就足够了，虽然这可能会导致在hdpi及以下的手机中有些卡顿，因为xhdpi的图片运行在hdpi及以下的手机上会比较吃内存，不过无伤大雅。
而如果不为图片资源犯愁时（有UI人员的支持，就是任性），就可以添加所有dpi的资源。当然，重点还是要满足ldpi:mdpi:hdpi:xhdpi:xxhdpi=3:4:6:8:12的规律。
好像说了不少废话，哈哈，大概就这么多吧。
‘陆’ 一种非常好用的Android屏幕适配
网上关于屏幕适配的文章已经铺天盖地了，为什么我还要讲？因为网上现在基本都是使用 屏幕分辨率限定符 进行适配，即每种屏幕分辨率的设备需要定义一套 dimens.xml 文件。由于不同分辨率的设备太多了，而且有些设备还有虚拟按键（例如华为手机），这样就还需要每个有虚拟按键的设备加多一套 dimens.xml 文件，再加上平板那些你会发现 dimens.xml 文件所占的体积已经超过 2M 了！这绝对不是我们想要的。
我这里要讲的是使用 sw<N>dp 限定符，即 smallestWidth（最小宽度） 限定符 来进行适配，使用这种方式只需要少量 dimens.xml 文件即可达到适配，而且根本不用考虑虚拟按键的问题。如果只适配手机，dimens.xml 文件所占的体积只有 100 多 KB，即使加上平板和 TV，也就 500 多 KB，完全可以接收。这种方案已经在自己多个项目中应用过了，经过几十台手机测试过，基本不会出现适配有问题的情况。制作生成对应 dimens.xml 文件插件（后面会讲）的作者也说过他在待过的两家大公司实践过，所以请放心使用。
关于为什么要进行屏幕适配，什么是 dp、dpi 这些概念我就不去一一讲解了，网上很多文章。这里我推荐几篇讲的比较好的：
屏幕分辨率限定符适配需要在 res 文件夹下创建各种屏幕分辨率对应的 values-xxx 文件夹，如下图：
然后根据一个基准分辨率，例如基准分辨率为 1280x720，将宽度分成 720 份，取值为 1px~720px，将高度分成 1280 份，取值为 1px~1280px，生成各种分辨率对应的 dimens.xml 文件。如下分别为分辨率 1280x720 与 1920x1080 所对应的横向 dimens.xml 文件：
假设设计图上的一个控件的宽度为 720px，那么布局中就写 android:layout_width="@dimen/x720" ，当运行程序的时候，系统会根据设备的分辨率去寻找对应的 dimens.xml 文件。例如运行在分辨率为 1280x720 的设备上，系统会自动找到对应的 values-1280x720 文件夹下的 lay_x.xml 文件，由上图可知 x720 对应的值为
720.px，可铺满该屏幕宽度。运行在分辨率为 1920x1080 的设备上，系统会自动找到对应的 values-1920x1080 文件夹下的 lay_x.xml 文件，由上图可知 x720 对应的值为 1080.0px，可铺满该屏幕宽度。这样就达到了屏幕适配的要求！
smallestWidth 限定符适配原理与屏幕分辨率限定符适配原理一样，系统都是根据限定符去寻找对应的 dimens.xml 文件。例如程序运行在最小宽度为 360dp 的设备上，系统会自动找到对应的 values-sw360dp 文件夹下的 dimens.xml 文件。区别就在于屏幕分辨率限定符适配是拿 px 值等比例缩放，而 smallestWidth 限定符适配是拿 dp 值来等比缩放而已。需要注意的是“最小宽度”是不区分方向的，即无论是宽度还是高度，哪一边小就认为哪一边是“最小宽度”。如下分别为最小宽度为 360dp 与最小宽度为 640dp 所对应的 dimens.xml 文件：
ScreenUtils——> ScreenUtils
既然原理都一样，都需要多套 dimens.xml 文件，那为什么要选择 smallestWidth 限定符适配呢？
大多数 UI 设计师提供的设计图无非就几种，它们对应的获取方式如下：
这些文件当然不会手动去写，网上已经有大神提供了自动生成这些文件的插件 ScreenMatch 。但是这个插件还是有点问题的：
基于以上问题，我在该插件的源码上优化生成了新的插件 ScreenMatch ，由于插件库已经有原作者的插件了，所以我就不重复造轮子上传到插件库了，你直接用本地安装的方式安装即可。
工具使用步骤：
然后选择在哪个 mole 下执行适配。即基于哪个 mole 下的 res/values/dimens.xml 文件作为基准 dimens.xml 文件，生成的其他尺寸 dimens.xml 文件放在哪个 mole 下。例如选择 app，然后点击 OK ，出现如下界面表示生成文件成功。如下图：
然后再看看 res 目录下会自动生成一堆 dimens.xml 文件，如下图：
通过上面的步骤就已经生成了所有设备对应的 dimens.xml 文件。
步骤 3 是以插件默认的最小宽度基准值为 360dp，适配的设备最小宽度为
320,360,384,392.7272,400,410,411.4285,432,480,533,592,600,640,662,720,768,800,811,820,960,961,1024,1280,1365（包含了平板和 TV ）生成的文件，但实际情况要根据设计图和需求设置。
例如设计图的最小宽度为 375dp，则需要更改最小宽度基准值为 375dp。如果项目只需要适配手机的话，适配的设备最小宽度保留 320,360,384,392.7272,400,410,411.4285,432,480 即可，若发现手机还有其他最小宽度自行加上即可，也麻烦把该最小宽度提供给我，我们一起来完善该份适配。
以上修改需要在配置文件里修改，即 screenMatch.properties 文件，该配置文件是执行完上面第 3 步后自动生成在项目的跟目录下的。如下图：
打开配置文件，修改下图中 1、3、4 的值即可。(图中单位均为 dp)
1：最小宽度基准值，填写设计图的最小宽度值即可。
2：插件默认适配的最小宽度值，即默认情况下会生成如下值的 dimens.xml 文件。
3：需要适配的最小宽度值（如果是小数，则保留 4 位小数。例如 392.727272...，则取 392.7272），即你想生成哪些 dimens.xml 文件。
4：忽略不需要适配的最小宽度值，即忽略掉插件默认生成的 dimens.xml 文件。
配置文件修改完成后，重新执行第 3 步，生成新的 dimens.xml 文件。
当然！如果你的设计图也是标准的 360dp，那么上面的步骤你可以忽略。直接复制我 github 上你需要的 dimens.xml 文件到你的项目即可， 默认的 values 文件夹下也需要一份 。
设计图标注多少 dp，布局中就写多少 dp ，非常方便！
大多数 UI 设计师提供的设计图无非就几种，它们对应的使用方式如下：
说了这么多，其实只需要简单的 2 步：
很多人肯定会有疑问，难道我用了这套适配方案就可以全部直接写死宽高了？那肯定不是的，如果一些好用的适配技巧能实现的，那就不要用直接写死宽高的方式。这套适配方案搭配下面这些适配技巧可以让你的屏幕适配更完美。
绝对布局（AbsoluteLayout）直接使用 X、Y 坐标来控制控件的位置，对于屏幕碎片化这么严重的今天，使用绝对布局对于屏幕适配来说就是灾难性的，所以 Google 已经废弃了该控件。
相对布局（RelativeLayout）或者约束布局（ConstraintLayout）就不一样了，相对布局的子控件之间使用 相对位置 的方式排列，即使屏幕的大小改变，控件的相对位置也不会变化，与屏幕大小无关，灵活性很强。约束布局也是类似的，通过对某些控件进行约束来确定它们之间的位置。
Nine-Patch 图片是一种被特殊处理过的 PNG 图片，你可以指定哪些区域可以拉伸而哪些区域不可以。例如聊天界面中的聊天气泡背景图就需要做成 Nine-Patch 图片，因为每条消息的字数不是固定的，如果背景图片不能随着字数的长短进行缩放，那么就会导致背景图片变形。
因为各种屏幕高宽比并不是固定的，有 16:9、4:3，还有全面屏的 19.5:9 等等，如果强行将宽高都适配那只会导致布局变形。
例如一个控件的宽高为 360dp 和 640dp，如果将它显示在宽高为 360dp 和 640dp 的设备上是正常铺满整个屏幕的，但是显示在宽高为 360dp 和 780dp 的设备上高度则不能铺满，如果你让高度铺满，而宽度又保持不变，那就会出现变形的情况。所以这也就是为什么目前市面上的屏幕适配方案只能以宽或高一个维度去适配，另一个方向用滑动或权重的方式去适配的原因。
那你为什么说高度也能适配呢？
这里说的高度也能适配指的是在不同分辨率和密度的手机上能达到等比缩放的适配，其他屏幕适配方案也是一样的。
注意：smallestWidth 限定符适配的效果是让不同分辨率和密度的设备上能达到以设计图等比缩放的适配，如果设备与设计图相差太大时并不能达到很好的适配效果，需要单独出图，其他屏幕适配方案也是一样的。
同横屏道理一样，平板、TV 与手机的宽高差距太大，想要平板、TV 也能完全适配，那就只能让设计师出一套平板、TV 的设计图，然后单独写一套平板、TV 的布局文件。
注意：再说一遍，smallestWidth 限定符适配的效果是让不同分辨率和密度的设备上能达到以设计图等比缩放的适配，如果设备与设计图相差太大时并不能达到很好的适配效果，需要单独出图，其他屏幕适配方案也是一样的。
github 地址： ScreenAdaptation
参考资料：