今日头条总结

链接：https://www.jianshu.com/p/55e0fca23b4f?utm_source=oschina-app

不管你在布局文件中填写的是什么单位，最后都会被转化为px

px转dp的公式dp = px / density

dp * density = px

density在每个设备上都是固定的

一、优点：

1.使用成本非常低，操作非常简单，使用该方案后在页面布局时不需要额外的代码和操作，这点可以说完虐其他屏幕适配方案

2.侵入性非常低，该方案和项目完全解耦，在项目布局时不会依赖哪怕一行该方案的代码，而且使用的还是Android官方的API，意味着当你遇到什么问题无法解决，想切换为其他屏幕适配方案时，基本不需要更改之前的代码，整个切换过程几乎在瞬间完成，会少很多麻烦，节约很多时间，试错成本接近于 0

3.可适配三方库的控件和系统的控件(不止是Activity和Fragment，Dialog、Toast等所有系统控件都可以适配)，由于修改的density在整个项目中是全局的，所以只要一次修改，项目中的所有地方都会受益

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

二、缺点：

1.它既是这个方案的优点也同样是缺点，但是就这一个缺点也是非常致命的

只需要修改一次density，项目中的所有地方都会自动适配，这个看似解放了双手，减少了很多操作，但是实际上反应了一个缺点，那就是只能一刀切的将整个项目进行适配，但适配范围是不可控的

因为我上面的原理也分析了，这个方案依赖于设计图尺寸，但是项目中的系统控件、三方库控件、等非我们项目自身设计的控件，它们的设计图尺寸并不会和我们项目自身的设计图尺寸一样

当这个适配方案不分类型，将所有控件都强行使用我们项目自身的设计图尺寸进行适配时，这时就会出现问题，当某个系统控件或三方库控件的设计图尺寸和和我们项目自身的设计图尺寸差距非常大时，这个问题就越严重

三、解决方案

方案 1

调整设计图尺寸，因为三方库可能是远程依赖的，无法修改源码，也就无法让三方库来适应我们项目的设计图尺寸，所以只有我们自身作出修改，去适应三方库的设计图尺寸，我们将项目自身的设计图尺寸修改为这个三方库的设计图尺寸，就能完成项目自身和三方库的适配

这时项目的设计图尺寸修改了，所以项目布局文件中的 dp 值，也应该按照修改的设计图尺寸，按比例增减，保持与之前设计图中的比例不变

但是如果为了适配一个三方库修改整个项目的设计图尺寸，是非常不值得的，所以这个方案支持以Activity为单位修改设计图尺寸，相当于每个Activity都可以自定义设计图尺寸，因为有些Activity不会使用三方库View，也就不需要自定义尺寸，所以每个Activity都有控制权的话，这也是最灵活的

但这也有个问题，当一个Activity使用了多个设计图尺寸不一样的三方库View，就会同样出现上面的问题，这也就只有把设计图改为与几个三方库比较折中的尺寸，才能勉强缓解这个问题

方案 2

第二个方案是最简单的，也是按Activity为单位，取消当前Activity的适配效果，改用其他的适配方案

四、坑1

这样无疑于使项目强耦合于这个方案，当你遇到无法解决的问题想切换为其他屏幕适配方案的时候，layout文件里曾经填写的px值都会作为dp

比如你的设计图实际宽度为1080px，你不换算为360dp (1080 / 3 = 360)，却直接将1080px作为这个方案的设计图尺寸，那你在layout文件中，填写的也都是设计图上标注的px值，但是单位却是dp

一个在设计图上300px * 300px的View，你可以直接在layout文件中填写为300dp，而由于这个方案可以动态改变density的原因还是可以做到等比例适配，非常爽!

但你不要忘了，这样你就强耦合于这个方案了，因为当你不使用这个方案时，density是不可变的!

坑2：

第二个坑其实就是刚刚在上面说的今日头条适配方案的缺点，当某个系统控件或三方库控件的设计图尺寸和和我们项目自身的设计图尺寸差距非常大时，这个问题就越严重

你如果直接填写以px为设计图的尺寸，这不用想，肯定和所有的三方库以及系统控件的设计图尺寸都不一样，而且差距都非常之大，至少两三倍的差距，这时你在当前页面弹个Toast就可以明显看到，比之前小很多，可以说是天差万别，用其他三方库View，也是一样的，会小很多

因为你以px为单位填写设计图尺寸，人家却用的dp，差距能不大吗，你如果老老实实用dp，哪怕三方库的设计图尺寸和你项目自身的设计图尺寸不一样，那也差距不大，小到一定程度，基本都不用调整，可以忽略不计，而且很多三方库的设计图尺寸其实也都是那几个大众尺寸，很大可能和你项目自身的设计图尺寸一样