骚年你的屏幕适配方式该升级了!-SmallestWidth 限定符适配方案

原文地址: www.jianshu.com/p/2aded8bb6…

如下是 骚年你的屏幕适配方式该升级了! 系列文章，欢迎转发以及分享:

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!
• 为何说 AndroidAutoLayout 的设计有问题?

扫描或点击如下二维码，加入技术交流 QQ 群 455850365

前言

ok，根据上一篇文章 骚年你的屏幕适配方式该升级了!-今日头条适配方案 的承诺，本文是这个系列的第二篇文章，这篇文章会详细讲解 smallestWidth 限定符屏幕适配方案

了解个人朋友必定知道，MVPArms 一直使用的是 鸿神 的 AndroidAutoLayout 屏幕适配方案，得益于 AndroidAutoLayout 的便捷，因此我对屏幕适配领域研究的不是不少，AndroidAutoLayout 中止维护后，我也一直在找寻着替代方案，直到 今日头条屏幕适配方案 刷屏，后来又无心间看到了 smallestWidth 限定符屏幕适配方案，这才慢慢的将研究方向转向了屏幕适配领域

最近一个月才开始慢慢恶补 Android 屏幕适配的相关知识，对这两个方案也进行了更深刻的研究，能够说从一个小白慢慢成长而来，因此我明白小白的痛，所以在上一篇文章 骚年你的屏幕适配方式该升级了!-今日头条适配方案 中，把 今日头条屏幕适配方案 讲得很是的细，尽可能把每个知识点都描述清晰，深怕小白漏掉每个细节，这篇文章我也会延续上一篇文章的优良传统，将 smallestWidth 限定符屏幕适配方案 的每个知识点都描述清晰

顺便说一句，感谢你们对 AndroidAutoSize 的支持，我只是在上一篇文章中提了一嘴我刚发布的屏幕适配框架 AndroidAutoSize，还没给出详细的介绍和原理剖析 (原计划在本系列的第三篇文章中发布)，AndroidAutoSize 就被你们推上了 Github Trending，一个多星期就拿了 2k+ stars，随着关注度的增长，我在这段时间里也累坏了，issues 就没断过，不到半个月就提交了 200 屡次 commit，但累并快乐着，在这里要再次感谢你们对 AndroidAutoSize 的承认

谈谈对百分比库的见解

是这样的，在上篇文章中有一些兄弟提了一些观点，我非常认同，可是我站在执行者的角度来看待这个问题，也有一些不一样的观点，如下是我在上篇文章中的回复

你们要注意了！这些观点其实针对的是全部以百分比缩放布局的库，而不仅是今日头条屏幕适配方案，因此这些观点也一样适用于 smallestWidth 限定符屏幕适配方案，这点有不少人存在误解，因此必定要注意！

上图的每个方框都表明一种 Android 设备的屏幕，Android 的 系统碎片化、机型以及屏幕尺寸碎片化、屏幕分辨率碎片化 有多严重你们能够经过 友盟指数 了解一下，有些时候在某些事情的决断标准上，并不能按照事情的对错来决断，大多数状况仍是要分析成本，收益等多种因素，经过利弊来决断，每一个人的利弊标准又都不同，因此每一个人的观点也都会有差异，但也都应该获得尊重，因此我只是说说本身的观点，也不否定任何人的观点

方案是死的人是活的，在某些大屏手机或平板电脑上，您也能够采用其余适配方案和百分比库结合使用，好比针对某个屏幕区间的设备单独出一套设计图以显示比小屏幕手机更多更精细的内容，来达到与百分比库互补的效果，没有一个方案能够说本身是完美的，但咱们能清晰的认识到不一样方案的优缺点，将它们的优势相结合，才能应付更复杂的开发需求，产出最好的产品

友情提示: 下面要介绍的 smallestWidth 限定符屏幕适配方案，原理也一样是按照百分比缩放布局，理论上也会存在上面所说的 大屏手机和小屏手机显示的内容相同 的问题，选择与否请仔细斟酌

简介 smallestWidth 限定符适配方案

这个方案的的使用方式和咱们平时在布局中引用 dimens 无异，核心点在于生成 dimens.xml 文件，可是已经有大神帮咱们作了这 一步

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-800x480
│   ├── ├──values-860x540
│   ├── ├──values-1024x600
│   ├── ├──values-1024x768
│   ├── ├──...
│   ├── ├──values-2560x1440
复制代码

若是有人还记得上面这种 宽高限定符屏幕适配方案 的话，就能够把 smallestWidth 限定符屏幕适配方案 当成这种方案的升级版，smallestWidth 限定符屏幕适配方案 只是把 dimens.xml 文件中的值从 px 换成了 dp，原理和使用方式都是没变的，这些在上面的文章中都有介绍，下面就直接开始剖析原理，smallestWidth 限定符屏幕适配方案 长这样👇

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw360dp
│   ├── ├──values-sw400dp
│   ├── ├──values-sw411dp
│   ├── ├──values-sw480dp
│   ├── ├──...
│   ├── ├──values-sw600dp
│   ├── ├──values-sw640dp
复制代码

原理

其实 smallestWidth 限定符屏幕适配方案 的原理也很简单，开发者先在项目中根据主流屏幕的 最小宽度 (smallestWidth) 生成一系列 values-sw<N>dp 文件夹 (含有 dimens.xml 文件)，当把项目运行到设备上时，系统会根据当前设备屏幕的 最小宽度 (smallestWidth) 去匹配对应的 values-sw<N>dp 文件夹，而对应的 values-sw<N>dp 文件夹中的 dimens.xml 文字中的值，又是根据当前设备屏幕的 最小宽度 (smallestWidth) 而定制的，因此必定能适配当前设备

若是系统根据当前设备屏幕的 最小宽度 (smallestWidth) 没找到对应的 values-sw<N>dp 文件夹，则会去寻找与之 最小宽度 (smallestWidth) 相近的 values-sw<N>dp 文件夹，系统只会寻找小于或等于当前设备 最小宽度 (smallestWidth) 的 values-sw<N>dp，这就是优于 宽高限定符屏幕适配方案 的容错率，而且也能够少生成不少 values-sw<N>dp 文件夹，减轻 App 的体积

什么是 smallestWidth

smallestWidth 翻译为中文的意思就是 最小宽度，那这个 最小宽度 是什么意思呢？

系统会根据当前设备屏幕的 最小宽度 来匹配 values-sw<N>dp，为何不是根据 宽度 来匹配，而要加上 最小 这两个字呢？

这就要说到，移动设备都是容许屏幕能够旋转的，当屏幕旋转时，屏幕的高宽就会互换，加上 最小 这两个字，是由于这个方案是不区分屏幕方向的，它只会把屏幕的高度和宽度中值最小的一方认为是 最小宽度，这个 最小宽度 是根据屏幕来定的，是固定不变的，意思是无论您怎么旋转屏幕，只要这个屏幕的高度大于宽度，那系统就只会认定宽度的值为 最小宽度，反之若是屏幕的宽度大于高度，那系统就会认定屏幕的高度的值为 最小宽度

若是想让屏幕宽度随着屏幕的旋转而作出改变该怎么办呢？能够再根据 values-w<N>dp (去掉 sw 中的 s) 生成一套资源文件

若是想区分屏幕的方向来作适配该怎么办呢？那就只有再根据 屏幕方向限定符 生成一套资源文件咯，后缀加上 -land 或 -port 便可，像这样，values-sw400dp-land (最小宽度 400 dp 横向)，values-sw400dp-port (最小宽度 400 dp 纵向)

smallestWidth 的值是怎么算的

要先算出当前设备的 smallestWidth 值咱们才能知道当前设备该匹配哪一个 values-sw<N>dp 文件夹

ok，仍是按照上一篇文章的叙述方式，如今来举栗说明，帮助你们更好理解

咱们假设设备的屏幕信息是 1920 * 1080、480 dpi

根据上面的规则咱们要在屏幕的高度和宽度中选择值最小的一方做为最小宽度，1080 < 1920，明显 1080 px 就是咱们要找的 最小宽度 的值，但 最小宽度 的单位是 dp，因此咱们要把 px 转换为 dp

帮助你们再巩固下基础，下面的公式必定不能再忘了！

px / density = dp，DPI / 160 = density，因此最终的公式是 px / (DPI / 160) = dp

因此咱们获得的 最小宽度 的值是 360 dp (1080 / (480 / 160) = 360)

如今咱们已经算出了当前设备的最小宽度是 360 dp，咱们晓得系统会根据这个 最小宽度 帮助咱们匹配到 values-sw360dp 文件夹下的 dimens.xml 文件，若是项目中没有 values-sw360dp 这个文件夹，系统才会去匹配相近的 values-sw<N>dp 文件夹

dimens.xml 文件是整个方案的核心所在，因此接下来咱们再来看看 values-sw360dp 文件夹中的这个 dimens.xml 是根据什么原理生成的

dimens.xml 生成原理

由于咱们在项目布局中引用的 dimens 的实际值，来源于根据当前设备屏幕的 最小宽度 所匹配的 values-sw<N>dp 文件夹中的 dimens.xml，因此搞清楚 dimens.xml 的生成原理，有助于咱们理解 smallestWidth 限定符屏幕适配方案

说到 dimens.xml 的生成，就要涉及到两个因数，第一个因素是 最小宽度基准值，第二个因素就是您的项目须要适配哪些 最小宽度，通俗理解就是须要生成多少个 values-sw<N>dp 文件夹

第一个因素

最小宽度基准值 是什么意思呢？简单理解就是您须要把设备的屏幕宽度分为多少份，假设咱们如今把项目的 最小宽度基准值 定为 360，那这个方案就会理解为您想把全部设备的屏幕宽度都分为 360 份，方案会帮您在 dimens.xml 文件中生成 1 到 360 的 dimens 引用，好比 values-sw360dp 中的 dimens.xml 是长这样的

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">1dp</dimen>
	<dimen name="dp_2">2dp</dimen>
	<dimen name="dp_3">3dp</dimen>
	<dimen name="dp_4">4dp</dimen>
	<dimen name="dp_5">5dp</dimen>
	<dimen name="dp_6">6dp</dimen>
	<dimen name="dp_7">7dp</dimen>
	<dimen name="dp_8">8dp</dimen>
	<dimen name="dp_9">9dp</dimen>
	<dimen name="dp_10">10dp</dimen>
	...
	<dimen name="dp_356">356dp</dimen>
	<dimen name="dp_357">357dp</dimen>
	<dimen name="dp_358">358dp</dimen>
	<dimen name="dp_359">359dp</dimen>
	<dimen name="dp_360">360dp</dimen>
</resources>
复制代码

values-sw360dp 指的是当前设备屏幕的 最小宽度 为 360dp (该设备高度大于宽度，则最小宽度就是宽度，因此该设备宽度为 360dp)，把屏幕宽度分为 360 份，恰好每份等于 1dp，因此每一个引用都递增 1dp，值最大的 dimens 引用 dp_360 值也是 360dp，恰好覆盖屏幕宽度

下面再来看看将 最小宽度基准值 定为 360 时，values-sw400dp 中的 dimens.xml 长什么样

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">1.1111dp</dimen>
	<dimen name="dp_2">2.2222dp</dimen>
	<dimen name="dp_3">3.3333dp</dimen>
	<dimen name="dp_4">4.4444dp</dimen>
	<dimen name="dp_5">5.5556dp</dimen>
	<dimen name="dp_6">6.6667dp</dimen>
	<dimen name="dp_7">7.7778dp</dimen>
	<dimen name="dp_8">8.8889dp</dimen>
	<dimen name="dp_9">10.0000dp</dimen>
	<dimen name="dp_10">11.1111dp</dimen>
	...
	<dimen name="dp_355">394.4444dp</dimen>
	<dimen name="dp_356">395.5556dp</dimen>
	<dimen name="dp_357">396.6667dp</dimen>
	<dimen name="dp_358">397.7778dp</dimen>
	<dimen name="dp_359">398.8889dp</dimen>
	<dimen name="dp_360">400.0000dp</dimen>
</resources>
复制代码

values-sw400dp 指的是当前设备屏幕的 最小宽度 为 400dp (该设备高度大于宽度，则最小宽度就是宽度，因此该设备宽度为 400dp)，把屏幕宽度一样分为 360份，这时每份就等于 1.1111dp 了，每一个引用都递增 1.1111dp，值最大的 dimens 引用 dp_360 一样恰好覆盖屏幕宽度，为 400dp

经过两个 dimens.xml 文件的比较，dimens.xml 的生成原理一目了然，方案会先肯定 最小宽度基准值，而后将每一个 values-sw<N>dp 中的 dimens.xml 文件都分配与 最小宽度基准值 相同的份数，再根据公式 屏幕最小宽度 / 份数 (最小宽度基准值) 求出每份占多少 dp，保证无论在哪一个 values-sw<N>dp 中，份数 (最小宽度基准值) * 每份占的 dp 值 的结果都是恰好覆盖屏幕宽度，因此在 份数 不变的状况下，只须要根据屏幕的宽度在不一样的设备上动态调整 每份占的 dp 值，就能完成适配

这样就能保证无论将项目运行到哪一个设备上，只要当前设备能匹配到对应的 values-sw<N>dp 文件夹，那布局中的 dimens 引用就能根据当前屏幕的状况进行缩放，保证能完美适配，若是没有匹配到对应的 values-sw<N>dp 文件夹，也不要紧，它会去寻找与之相近的 values-sw<N>dp 文件夹，虽然在这种状况下，布局中的 dimens 引用的值可能有些许偏差，可是也能保证最大程度的完成适配

说到这里，那你们就应该就会明白我为何会说 smallestWidth 限定符屏幕适配方案 的原理也一样是按百分比进行布局，若是在布局中，一个 View 的宽度引用 dp_100，那无论运行到哪一个设备上，这个 View 的宽度都是当前设备屏幕总宽度的 360分之100，前提是项目提供有当前设备屏幕对应的 values-sw<N>dp，若是没有对应的 values-sw<N>dp，就会去寻找相近的 values-sw<N>dp，这时就会存在偏差了，至于偏差是大是小，这就要看您的第二个因数怎么分配了

其实 smallestWidth 限定符屏幕适配方案 的原理和 今日头条屏幕适配方案 挺像的，今日头条屏幕适配方案 是根据屏幕的宽度或高度动态调整每一个设备的 density (每 dp 占当前设备屏幕多少像素)，而 smallestWidth 限定符屏幕适配方案 一样是根据屏幕的宽度动态调整每一个设备 每份占的 dp 值

第二个因素

第二个因数是须要适配哪些 最小宽度？好比您想适配的 最小宽度 有 320dp、360dp、400dp、411dp、480dp，那方案就会为您的项目生成 values-sw320dp、values-sw360dp、values-sw400dp、values-sw411dp、values-sw480dp 这几个资源文件夹，像这样👇

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw360dp
│   ├── ├──values-sw400dp
│   ├── ├──values-sw411dp
│   ├── ├──values-sw480dp
复制代码

方案会为您须要适配的 最小宽度，在项目中生成一系列对应的 values-sw<N>dp，在前面也说了，若是某个设备没有为它提供对应的 values-sw<N>dp，那它就会去寻找相近的 values-sw<N>dp，但若是这个相近的 values-sw<N>dp 与指望的 values-sw<N>dp 差距太大，那适配效果也就会大打折扣

那是否是 values-sw<N>dp 文件夹生成的越多，覆盖越多市面上的设备，就越好呢？

也不是，由于每一个 values-sw<N>dp 文件夹其实都会占用必定的 App 体积，values-sw<N>dp 文件夹越多，App 的体积也就会越大

因此必定要合理分配 values-sw<N>dp，以越少的 values-sw<N>dp 文件夹，覆盖越多的机型

验证方案可行性

原理讲完了，咱们仍是按照老规矩，来验证一下这个方案是否可行？

假设设计图总宽度为 375 dp，一个 View 在这个设计图上的尺寸是 50dp * 50dp，这个 View 的宽度占整个设计图宽度的 13.3% (50 / 375 = 0.133)

在使用 smallestWidth 限定符屏幕适配方案 时，须要提供 最小宽度基准值 和须要适配哪些 最小宽度，咱们就把 最小宽度基准值 设置为 375 (和 设计图 一致)，这时方案就会为咱们须要适配的 最小宽度 生成对应的 values-sw<N>dp 文件夹，文件夹中的 dimens.xml 文件是由从 1 到 375 组成的 dimens 引用，把全部设备的屏幕宽度都分为 375 份，因此在布局文件中咱们应该把这个 View 的高宽都引用 dp_50

下面就来验证下在使用 smallestWidth 限定符屏幕适配方案 的状况下，这个 View 与屏幕宽度的比例在分辨率不一样的设备上是否还能保持和设计图中的比例一致

验证设备 1

设备 1 的屏幕总宽度为 1080 px，屏幕总高度为 1920 px，DPI 为 480

设备 1 的屏幕高度大于屏幕宽度，因此 设备 1 的 最小宽度 为屏幕宽度，再根据公式 px / (DPI / 160) = dp，求出 设备 1 的 最小宽度 的值为 360 dp (1080 / (480 / 160) = 360)

根据 设备 1 的 最小宽度 应该匹配的是 values-sw360dp 这个文件夹，假设 values-sw360dp 文件夹及里面的 dimens.xml 已经生成，且是按 最小宽度基准值 为 375 生成的，360 / 375 = 0.96，因此每份占的 dp 值为 0.96，dimens.xml 里面的内容是长下面这样的👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">0.96dp</dimen>
	<dimen name="dp_2">1.92dp</dimen>
	<dimen name="dp_3">2.88dp</dimen>
	<dimen name="dp_4">3.84dp</dimen>
	<dimen name="dp_5">4.8dp</dimen>
	...
	<dimen name="dp_50">48dp</dimen>
	...
	<dimen name="dp_371">356.16dp</dimen>
	<dimen name="dp_372">357.12dp</dimen>
	<dimen name="dp_373">358.08dp</dimen>
	<dimen name="dp_374">359.04dp</dimen>
	<dimen name="dp_375">360dp</dimen>
</resources>
复制代码

能够看到这个 View 在布局中引用的 dp_50，最终在 values-sw360dp 中定格在了 48 dp，因此这个 View 在 设备 1 上的高宽都为 48 dp，系统最后会将高宽都换算成 px，根据公式 dp * (DPI / 160) = px，因此这个 View 的高宽换算为 px 后等于 144 px (48 * (480 / 160) = 144)

144 / 1080 = 0.133，View 的实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，因此完成了等比例缩放

某些设备的高宽是和 设备 1 相同的，可是 DPI 可能不一样，而因为 smallestWidth 限定符屏幕适配方案 并无像 今日头条屏幕适配方案 同样去自行修改 density，因此系统就会使用默认的公式 DPI / 160 求出 density，density 又会影响到 dp 和 px 的换算，所以 DPI 的变化，是有可能会影响到 smallestWidth 限定符屏幕适配方案 的

因此咱们再来试试在这种特殊状况下 smallestWidth 限定符屏幕适配方案 是否也能完成适配

验证设备 2

设备 2 的屏幕总宽度为 1080 px，屏幕总高度为 1920 px，DPI 为 420

设备 2 的屏幕高度大于屏幕宽度，因此 设备 2 的 最小宽度 为屏幕宽度，再根据公式 px / (DPI / 160) = dp，求出 设备 2 的 最小宽度 的值为 411.429 dp (1080 / (420 / 160) = 411.429)

根据 设备 2 的 最小宽度 应该匹配的是 values-sw411dp 这个文件夹，假设 values-sw411dp 文件夹及里面的 dimens.xml 已经生成，且是按 最小宽度基准值 为 375 生成的，411 / 375 = 1.096，因此每份占的 dp 值为 1.096，dimens.xml 里面的内容是长下面这样的👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="dp_1">1.096dp</dimen>
	<dimen name="dp_2">2.192dp</dimen>
	<dimen name="dp_3">3.288dp</dimen>
	<dimen name="dp_4">4.384dp</dimen>
	<dimen name="dp_5">5.48dp</dimen>
	...
	<dimen name="dp_50">54.8dp</dimen>
	...
	<dimen name="dp_371">406.616dp</dimen>
	<dimen name="dp_372">407.712dp</dimen>
	<dimen name="dp_373">408.808dp</dimen>
	<dimen name="dp_374">409.904dp</dimen>
	<dimen name="dp_375">411dp</dimen>
</resources>
复制代码

能够看到这个 View 在布局中引用的 dp_50，最终在 values-sw411dp 中定格在了 54.8dp，因此这个 View 在 设备 2 上的高宽都为 54.8 dp，系统最后会将高宽都换算成 px，根据公式 dp * (DPI / 160) = px，因此这个 View 的高宽换算为 px 后等于 143.85 px (54.8 * (420 / 160) = 143.85)

143.85 / 1080 = 0.133，View 的实际宽度与 屏幕总宽度 的比例和 View 在设计图中的比例一致 (50 / 375 = 0.133)，因此完成了等比例缩放

虽然 View 在 设备 2 上的高宽是 143.85 px，比 设备 1 的 144 px 少了 0.15 px，可是偏差很是小，总体的比例并无发生太大的变化，是彻底能够接受的

这个偏差是怎么引发的呢，由于 设备 2 的 最小宽度 的实际值是 411.429 dp，可是匹配的 values-sw411dp 舍去了小数点后面的位数 (切记！系统会去寻找小于或等于 411.429 dp 的 values-sw<N>dp，因此 values-sw412dp 这个文件夹，设备 2 是匹配不了的)，因此才存在了必定的偏差，所以上面介绍的第二个因数是很是重要的，这直接决定偏差是大仍是小

能够看到即便在高宽同样但 DPI 不同的设备上，smallestWidth 限定符屏幕适配方案 也能完成等比例适配，证实这个方案是可行的，若是你们还心存疑虑，也能够再试试其余分辨率的设备，其实到最后得出的比例都是在 0.133 左右，惟一的变数就是第二个因数，若是您生成的 values-sw<N>dp 与设备实际的 最小宽度 差异不大，那偏差也就在能接受的范围内，若是差异很大，那就直接 GG

优势

1. 很是稳定，极低几率出现意外

2. 不会有任何性能的损耗

3. 适配范围可自由控制，不会影响其余三方库

4. 在插件的配合下，学习成本低

缺点

1. 在布局中引用 dimens 的方式，虽然学习成本低，可是在平常维护修改时较麻烦

2. 侵入性高，若是项目想切换为其余屏幕适配方案，由于每一个 Layout 文件中都存在有大量 dimens 的引用，这时修改起来工做量很是巨大，切换成本很是高昂

3. 没法覆盖所有机型，想覆盖更多机型的作法就是生成更多的资源文件，但这样会增长 App 体积，在没有覆盖的机型上还会出现必定的偏差，因此有时须要在适配效果和占用空间上作一些抉择

4. 若是想使用 sp，也须要生成一系列的 dimens，致使再次增长 App 的体积

5. 不能自动支持横竖屏切换时的适配，如上文所说，若是想自动支持横竖屏切换时的适配，须要使用 values-w<N>dp 或 屏幕方向限定符 再生成一套资源文件，这样又会再次增长 App 的体积

6. 不能以高度为基准进行适配，考虑到这个方案的名字自己就叫 最小宽度限定符适配方案，因此在使用这个方案以前就应该要知道这个方案只能以宽度为基准进行适配，为何如今的屏幕适配方案只能以高度或宽度其中的一个做为基准进行适配，请看 这里

使用中的问题

这时有人就会问了，设计师给的设计图只标注了 px，使用这个方案时，那不是还要先将 px 换算成 dp？

其实也能够不用换算的，那这是什么骚操做呢？

很简单，你把设计图的 px 总宽度设置成 最小宽度基准值 就能够了，仍是之前面验证可行性的例子

咱们在前面验证可行性时把 最小宽度基准值 设置成了 375，为何是 375 呢？由于设计图的总宽度为 375 dp，若是换算成 px，总宽度就是 750 px，咱们这时把 最小宽度基准值 设置成 750，而后看看 values-sw360dp 中的 dimens.xml 长什么样👇

<?xml version="1.0" encoding="UTF-8"?>
<resources>
	<dimen name="px_1">0.48dp</dimen>
	<dimen name="px_2">0.96dp</dimen>
	<dimen name="px_3">1.44dp</dimen>
	<dimen name="px_4">1.92dp</dimen>
	<dimen name="px_5">2.4dp</dimen>
	...
	<dimen name="px_50">24dp</dimen>
	...
	<dimen name="px_100">48dp</dimen>
	...
	<dimen name="px_746">358.08dp</dimen>
	<dimen name="px_747">358.56dp</dimen>
	<dimen name="px_748">359.04dp</dimen>
	<dimen name="px_749">359.52dp</dimen>
	<dimen name="px_750">360dp</dimen>
</resources>
复制代码

360 dp 被分红了 750 份，相比以前的 375 份，如今 每份占的 dp 值 正好减小了一半，还记得在验证可行性的例子中那个 View 的尺寸是多少吗？50dp * 50dp，若是设计图只标注 px，那这个 View 在设计图上的的尺寸应该是 100px * 100px，那咱们直接根据设计图上标注的 px，想都不用想直接在布局中引用 px_100 就能够了，由于在 375 份时的 dp_50 恰好等于 750 份时的 px_100 (值都是 48 dp)，因此这时的适配效果和以前验证可行性时的适配效果没有任何区别

看懂了吗？直接将 最小宽度基准值 和布局中的引用都以 px 做为单位就能够直接填写设计图上标注的 px！

总结

关于文中所列出的优缺点，列出的缺点数量确实比列出的优势数量多，但 缺点 3，缺点 4，缺点 5 其实均可以概括于 占用 App 体积 这一个缺点，由于他们均可以经过增长资源文件来解决问题，而 缺点 6 则是这个方案的特点，只能以宽度为基准进行适配，这个从这个方案的名字就能看出

请你们千万不要曲解文章的意思，不要只是单纯的对比优缺点的数量，缺点的数量大于优势的数量就必定是这个方案不行？没有一个方案是完美的，每一个人的需求也都不同，做为一篇科普类文章我只可能把这个方案描述得尽量的全面

这个方案能给你带来什么，不能给你带来什么，我必须客观的描述清楚，这样才有助你作出决定，你应该注重的是在这些优缺点里什么是我能接受的，什么是我不能接受的，是否能为了某些优势作出某些妥协，而不仅是单纯的去看数量，这样毫无心义，有些人就是以为稳定性最重要，其余的均可以作出妥协，那其余缺点对于他来讲都是无所谓的

好了，这个系列的第二篇文章讲完了，这篇文章也是按照上篇文章的优良传统，写的很是详细，哪怕是新手我相信也应该能看懂，为何这么多人都不知道本身该选择什么样的方案，就是由于本身都没搞懂这些方案的原理，懂了原理事后才知道这些方案是不是本身想要的

接下来的第三篇文章会详细讲解两个方案的深刻对比以及该如何选择，并剖析我根据 今日头条屏幕适配方案 优化的屏幕适配框架 AndroidAutoSize 的原理，敬请期待

若是你们想使用 smallestWidth 限定符屏幕适配方案，能够参考 这篇文章，里面提供有自动生成资源文件的插件和 Demo，因为我并无在项目中使用 smallestWidth 限定符屏幕适配方案，因此若是在文章中有遗漏的知识点请谅解以及补充，感谢！

公众号

扫码关注个人公众号 JessYan，一块儿学习进步，若是框架有更新，我也会在公众号上第一时间通知你们

---

如下是 骚年你的屏幕适配方式该升级了! 系列文章，欢迎转发以及分享:

• 骚年你的屏幕适配方式该升级了!（一）-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!（二）-smallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版正式发布!
• 为何说 AndroidAutoLayout 的设计有问题?

---

Hello 我叫 JessYan，若是您喜欢个人文章，能够在如下平台关注我

• 我的主页: jessyan.me
• GitHub: github.com/JessYanCodi…
• 掘金: juejin.im/user/57a9db…
• 简书: www.jianshu.com/u/1d0c0bc63…
• 微博: weibo.com/u/178626251…

-- The end