Android系统发布十多年以来，关于Android的UI的适配一直是开发环节中最重要的问题，现在总结下目前主流的适配方案。

适配方案一 宽高限定符适配

适配原理

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

如果我们的UI设计界面使用的就是基准分辨率，那么我们就可以按照设计稿上的尺寸填写相对应的 dimens 引用了，而当 APP 运行在不同分辨率的手机中时，这些系统会根据这些 dimens 引用去该分辨率的文件夹下面寻找对应的值。这样基本解决了我们的适配问题。

优点

暂无明显优点

缺点

这个方案有一个致命的缺陷，那就是需要精准命中才能适配。

比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。

而使用默认的尺寸的话，UI就很可能变形，简单说，就是容错机制很差。

其他

容错机制较差，在我们的项目中放弃。

适配方案二 AndroidAutoLayout

原理

详见： AndroidAutoLayout

优点

集成简单，在宽高限定符适配的基础上更进一步，并且解决了容错机制的问题，可以说完美的达成了开发高效和适配精准的两个要求。

缺点

但是我们能够想到，因为框架要在运行时会在 onMeasure 里面做变换，我们自定义的控件可能会被影响或限制，可能有些特定的控件，需要单独适配，这里面可能存在的暗坑是不可预见的，还有一个比较重要的问题，那就是整个适配工作是由框架完成的，而不是系统完成的，一旦使用这个框架，未来一旦遇到很难解决的问题，替换起来是非常麻烦的，而且项目一旦停止维护，后续的升级就只能靠你自己，这种代价团队能否承受？当然，它已经停止维护了。

适配方案三 smallestWidth 适配

适配原理

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

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

举个例子，小米5的 dpi 是480,横向像素是 1080px，根据 px=dp(dpi/160)，横向的 dp 值是1080/(480/160),也就是 360dp ,系统就会去寻找是否存在 value-sw360dp 的文件夹以及对应的资源文件。

优点

1、smallestWidth 的适配机制由系统保证，我们只需要针对这套规则生成对应的资源文件即可，不会出现什么难以解决的问题，也根本不会影响我们的业务逻辑代码，而且只要我们生成的资源文件分布合理，即使对应的 smallestWidth 值没有找到完全对应的资源文件，它也能向下兼容，寻找最接近的资源文件

2、有生成 dimens文件的demo ，可以作为详细参考 demo

缺点

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

适配方案四 DisplayMetrics

通过 DisplayMetrics 中相关的值 计算适配，也是今日头条的适配方案

适配原理

通过修改 density 值，强行把所有不同尺寸分辨率的手机的宽度dp值改成一个统一的值，这样就解决了所有的适配问题。

比如，设计稿宽度是360px，那么开发这边就会把目标 dp 值设为 360dp，在不同的设备中，动态修改 density 值，从而保证(手机像素宽度) px/density 这个值始终是 360dp,这样的话，就能保证 UI 在不同的设备上表现一致了

一种极低成本的Android屏幕适配方式

优点

这个方案侵入性很低，而且也没有涉及私有 API，应该也是极不错的方案，暂时也想不到强行修改 density 是否会有其他影响，既然有今日头条的大厂在用，稳定性应当是有保证的

缺点

这套方案对老项目是不太友好的，因为修改了系统的 density 值之后，整个布局的实际尺寸都会发生改变，如果想要在老项目文件中使用，恐怕整个布局文件中的尺寸都可能要重新按照设计稿修改一遍才行。

由于头条的方案是直接修改 DisplayMetrics#density 的 dp 适配，这样会导致系统 View 尺寸和原先不一致，比如 Dialog、Toast、 尺寸，同样，三方 View 的大小也会和原先效果不一致。

适配方案五 DisplayMetrics ++

通过 DisplayMetrics 中相关的值，计算适配，进一步优化

适配原理

详见： blankj

优点

1、无侵入性 2、灵活性高 3、不会影响系统 View 和三方 View 的大小 4、不会失效

新 老项目 都可以用

缺点

无成熟项目使用 参考

适配方案六 calces.screen

使用 calces.screen 快速实 Smalles Widths 适配方案

适配原理

详见： calces-screen

优点

通过 Gradle 插件来自动处理 sw 比例计算与文件生成、位图自动缩放，来实现一个相对更好的适配方案。

缺点

对 老项目不太友好

适配方案七 AndroidAutoSize 屏幕适配框架

适配原理

详见： AndroidAutoSize

优点

新老项目可用 灵活性高 集成简单

缺点

activity, fragnemt，有代码侵入

适配方案八 Android hdpi, xhdpi, xxhdpi 等屏幕适配

适配原理

根据手机分辨率，系统会根据这些 dimens 引用去该密度类型的文件夹下面寻找对应的值

优点

这个是我们先现有老项目使用 方便修改

缺点

因密度（hdpi，xhdpi）是像素密度范围，尺寸有偏差