版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u011033906/article/details/89336023
笔记用
根据上篇博客的内容来看，主流的屏幕适配方案有两种：
smallestWidth 适配
优点
- 非常稳定，极低概率出现意外
- 不会有任何性能的损耗
- 适配范围可自由控制，不会影响其他三方库
- 在插件的配合下，学习成本低
缺点
- 在布局中引用 dimens 的方式，虽然学习成本低，但是在日常维护修改时较麻烦
- 侵入性高，如果项目想切换为其他屏幕适配方案，因为每个 Layout 文件中都存在有大量 dimens 的引用，这时修改起来工作量非常巨大，切换成本非常高昂
- 无法覆盖全部机型，想覆盖更多机型的做法就是生成更多的资源文件，但这样会增加 App 体积，在没有覆盖的机型上还会出现一定的误差，所以有时需要在适配效果和占用空间上做一些抉择
- 如果想使用 sp，也需要生成一系列的 dimens，导致再次增加 App 的体积。(300kb ~ 800kb 左右)
- 不能自动支持横竖屏切换时的适配，如上文所说，如果想自动支持横竖屏切换时的适配，需要使用 values-wdp 或 屏幕方向限定符 再生成一套资源文件，这样又会再次增加 App 的体积
- 不能以高度为基准进行适配，考虑到这个方案的名字本身就叫 最小宽度限定符适配方案，所以在使用这个方案之前就应该要知道这个方案只能以宽度为基准进行适配，为什么现在的屏幕适配方案只能以高度或宽度其中的一个作为基准进行适配，请看 这里
今日头条屏幕适配方案
优点
- 使用成本非常低，操作非常简单，使用该方案后在页面布局时不需要额外的代码和操作，这点可以说完虐其他屏幕适配方案
- 侵入性非常低，该方案和项目完全解耦，在项目布局时不会依赖哪怕一行该方案的代码，而且使用的还是 Android 官方的 API，意味着当你遇到什么问题无法解决，想切换为其他屏幕适配方案时，基本不需要更改之前的代码，整个切换过程几乎在瞬间完成，会少很多麻烦，节约很多时间，试错成本接近于 0
- 可适配三方库的控件和系统的控件(不止是是 Activity 和 Fragment，Dialog、Toast 等所有系统控件都可以适配)，由于修改的 density 在整个项目中是全局的，所以只要一次修改，项目中的所有地方都会受益
- 不会有任何性能的损耗
缺点
暂时没发现其他什么很明显的缺点，已知的缺点有一个，那就是第三个优点，它既是这个方案的优点也同样是缺点，但是就这一个缺点也是非常致命的
当某个系统控件或三方库控件的设计图尺寸和和我们项目自身的设计图尺寸差距非常大时，这个问题就越严重
解决方案：
- 按 Activity 为单位，取消当前 Activity 的适配效果，改用其他的适配方案
方案对比
具体细节请参考：JessYan --> 今日头条屏幕适配方案终极版正式发布!
SmallestWidth限定符适配方案 主打的是稳定性，在运行过程中极少会出现安全隐患，适配范围也可控，不会产生其他未知的影响.- 今日头条适配方案 主打的是降低开发成本、提高开发效率，使用上更灵活，也能满足更多的扩展需求
- 简单一句话概括就是，这两兄弟，一个求稳，一个求快