宽高限定符适配
为了高效的实现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-sw400dp,
当系统识别到手机的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哦），所以，这问题其实也不重要了。
还有一个缺陷我忘了提，那就是多个dimens文件可能导致apk变大，这是事实，根据生成的dimens文件的覆盖范围和尺寸范围，apk可能会增大300kb-800kb左右，目前糗百的dimens文件大小是406kb，我认为这是可以接受的。
今日头条适配方案
文章链接，之前确实没有接触过，我简单看了一遍，可以说，这也是相对比较完美的方案，我先简单说一下这个方案的思路，它是通过修改density值，强行把所有不同尺寸分辨率的手机的宽度dp值改成一个统一的值，这样就解决了所有的适配问题。
比如，设计稿宽度是360px，那么开发这边就会把目标dp值设为360dp，在不同的设备中，动态修改density值，从而保证(手机像素宽度)px/density这个值始终是360dp,这样的话，就能保证UI在不同的设备上表现一致了。
这个方案侵入性很低，而且也没有涉及私有API，应该也是极不错的方案，我暂时也想不到强行修改density是否会有其他影响，既然有今日头条的大厂在用，稳定性应当是有保证的。
但是根据我的观察，这套方案对老项目是不太友好的，因为修改了系统的density值之后，整个布局的实际尺寸都会发生改变，如果想要在老项目文件中使用，恐怕整个布局文件中的尺寸都可能要重新按照设计稿修改一遍才行。因此，如果你是在维护或者改造老项目，使用这套方案就要三思了。
关于一些问题
Q: 该适配方案怎么用？
A:点击进入上文的github项目，下载到本地，然后运行该Java工程，会在本地根目录下生成相应的文件，如果需要生成更多尺寸，在DimenTypes 文件中填写你需要的尺寸即可。
Q： 是否有推荐的尺寸？
A 300,320,360,411，450，这几个尺寸是比较必要的，然后在其中插入一些其他的尺寸即可，如果不放心，可以在300-450之间，以10为步长生成十几个文件。
Q:平板适配的问题？
A: 这个可以分成两个问题，第一，团队有没有专门针对平板设计UI?第二，才是如何对平板适配。如果团队内部没有针对平板设计UI,那么大家对于App在平板上运行的要求大抵也就是不要太难看即可。针对这种情况的适配方法是被动适配，即不要生成480以上的适配文件，这样在平板上，系统就会使用480这个尺寸的dimens文件，这样效果比主动适配更好；而如果团队主动设计了平板的UI，那么我们就需要主动生成平板的适配文件，大概在600-800之间，关键尺寸是640,768。然后按照UI设计的图来写即可。
Q：用了这套方案是否就不需要使用wrap_content等来布局了？
A:这是绝对错误的做法！如果UI设计上明显更适合使用wrap_content,match_parent,layout_weight等,我们就要毫不犹豫的使用，而且在高这个维度上，我们要依照情况设计为可滑动的方式，或者match_parent,尽量不要写死。总之，所有的适配方案都不是用来取代match_parent,wrap_content的，而是用来完善他们的。
后记
糗百app几天内会发布11.2.0的UI全新改版的新版本，里面就大范围用到了sw适配，到时候大家可以用各种Android手机试用，看看适配效果，如果哪里适配有问题可评论留言。
好了，文章到这里就结束了，如果你觉得文章写得不错就给个赞呗？如果你觉得那里值得改进的，请给我留言。一定会认真查询，修正不足。谢谢。
希望读到这的您能转发分享和关注一下我，以后还会更新技术干货，谢谢您的支持！
转发+点赞+关注，第一时间获取最新知识点
Android架构师之路很漫长，一起共勉吧！
以下墙裂推荐阅读！！！
Android学习笔记参考（敲黑板！！）“寒冬未过”，阿里P9架构分享Android必备技术点，让你offer拿到手软！毕业3年，我是如何从年薪10W的拖拽工程师成为30W资深Android开发者！腾讯T3大牛带你了解 2019 Android开发趋势及必备技术点！八年Android开发，从码农到架构师分享我的技术成长之路，共勉！
如果你觉得还算有用的话，不妨把它们推荐给你的朋友~
先自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频
如果你觉得这些内容对你有帮助，可以扫码领取！！！！
最后
为了方便有学习需要的朋友，我把资料都整理成了视频教程（实际上比预期多花了不少精力）
当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。
无论你现在水平怎么样一定要 持续学习 没有鸡汤，别人看起来的毫不费力，其实费了很大力，这四个字就是我的建议！！我希望每一个努力生活的IT工程师，都会得到自己想要的，因为我们很辛苦，我们应得的。
当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。
无论你现在水平怎么样一定要 持续学习 没有鸡汤，别人看起来的毫不费力，其实费了很大力，没有人能随随便便成功。
加油，共勉。 《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可免费领取！
升中甩开同龄人。
无论你现在水平怎么样一定要 持续学习 没有鸡汤，别人看起来的毫不费力，其实费了很大力，没有人能随随便便成功。
加油，共勉。 《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可免费领取！
相关文章
您阅读本篇文章共花了：
发表评论