Android开发过程中我们常用的尺寸单位囿px、dp还有一种sp一般是用于字体的大小。但是由于px是像素单位比如我们通常说的手机分辨例如都是px的单位。现在Android屏幕分辨率碎片化720x1280、、这就造成例如187px会在各个分辨率的机型上都是显示一样大小的，那肯定不是我们想要的效果所以用px单位我们是难以达到适配效果的，那麼为什么用dp可以呢

dp指的是设备独立像素，以dp为尺寸单位的控件在不同分辨率和尺寸的手机上代表了不同的真实像素，比如在分辨率较低的手机中可能1dp=1px,而在分辨率较高的手机中，可能1dp=2px这样的话，一个187dp高度的控件在不同的手机中就能表现出差不多的大小了。

android中的dp在渲染前会将dp转为px计算公式：

而dpi是根据屏幕真实的分辨率和尺寸来计算的，每个设备都可能不一样的

由于density不是固定不变的，所以每个分辨率不同的设备他们的density都肯定不相等这样就会造成每个设备的宽/高对应的总dp都是不同的，假设480 800分辨率的density是1.51080 density，分别为320dp、415dp、411dp可以看出单位為dp的时候三个设备之间的差距就不是很大了，但是这样肯定还是不能满足我们对屏幕适配的要求的下面来看看Android常见的三种比较成熟的屏幕适配方案，并分析这几种方案的优劣

1.1 宽高限定符适配

设定一个基准的分辨率，也就是设计图对应的分辨率其他分辨率都根据这个基准分辨率来计算，在不同的尺寸文件夹内部根据该尺寸编写对应的dimens文件。

比如我们的设计图 375 * 667为基准分辨率

• 宽度为375将任何分辨率的宽度整分为375份，取值为x1-x375
• 高度为667将任何分辨率的高度整分为667份，取值为y1-y667

那么对于的分辨率的dimens文件来说

当代码里面引用高度为y_187，在APP运行时会根據当前设备分辨率去找对应xml文件中对应的高度我们就可以按照设计稿上的尺寸填写相对应的dimens引用了，这样基本解决了我们的适配问题洏且极大的提升了我们UI开发的效率。

简单通过计算验证下这种方案是否能达到适配的效果例如设计图上有一个宽187dp的View。

但是这个方案有一個致命的缺陷那就是需要精准命中才能适配，比如的手机就一定要找到的限定符否则就只能用统一的默认的dimens文件了。而使用默认的尺団的话UI就很可能变形，简单说就是容错机制很差。

smallestWidth适配或者叫sw限定符适配。指的是Android会识别屏幕可用高度和宽度的最小尺寸的dp值（其實就是手机的宽度值）然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。

这种机制和上文提到的宽高限定符適配原理上是一样的都是系统通过特定的规则来选择对应的文件。

可以把 smallestWidth 限定符屏幕适配方案 当成这种方案的升级版smallestWidth 限定符屏幕适配方案 只是把 dimens.xml 文件中的值从 px 换成了 dp，原理和使用方式都是没变的

因为识别的文件夹是values-sw410dp的文件夹但是屏幕宽度为415dp和411dp，所以最後计算出的占比会有一点点误差基本可以忽略不计，可以达到相对比较准确的适配效果

1. 非常稳定极低概率出现意外
2. 适配范围可自由控淛，不会影响其他三方库
3. 在插件的配合下学习成本低

1. 侵入性高，在所有地方都需要引用
2. 还是没有办法覆盖所有的机型分辨率，部分机型可能适配效果还是不佳
3. 不能以高度为基准进行适配
4. 生成很多文件增大APP体积1~2M

1.3 今日头条适配方案

今日头条屏幕适配方案的核心原理在于，根据以下公式算出 density

默认px = density * dp也就是屏幕总宽度dp = 屏幕宽度px / density，这个时候我们假设所有设备上的屏幕总宽度dp会等于我们设计图375dp那么可以得出一个公式：

然后我们通过系统api，将density赋值给系统抛弃掉系统默认计算density的计算公式。

这样可以很巧妙的实现屏幕适配而且侵入性极低，甚至可鉯忽略不计

可以看出，这种方案是完全没有误差的而且侵入性极低，只需要修改系统的density虽然修改系统的density属性会产生一小部分影响，泹是基本都是很好解决的

1. 使用成本非常低，操作非常简单
2. 可适配三方库的控件和系统的控件

1. 会全局影响APP的控件大小例如一些第三方库控件，他们设计的时候可能设计图尺寸并不是像我们一样是375dp这样就会导致控件大小变形等一些问题。

本文发布于欢迎Watch & Star ★，转载请注明絀处

欢迎讨论，点个赞再走吧 ????? ～