屏幕适配

前言

由于Android系统的开放性，任何用户、开发者、硬件厂商、运营商都可以对Android系统和硬件进行定制，修改成他们想要的样子。 那么这种“碎片化”到达什么程度呢？

以上每一个矩形都代表一种机型，且它们屏幕尺寸、屏幕分辨率大相径庭。随着Android设备的增多，设备碎片化、系统碎片化、屏幕尺寸碎片化、屏幕碎片化的程度也在不断加深。

当 Android 系统、屏幕尺寸、屏幕密度出现碎片化的时候，就很容易出现同一元素在不同手机上显示不同的问题。试想一下这么一个场景： 为 4.3 寸屏幕准备的 UI 设计图，运行在 5.0 寸的屏幕上，很可能在右侧和下侧存在大量的空白；而 5.0 寸的 UI 设计图运行到 4.3 寸的设备上，很可能显示不下。

为了保证用户获得一致的用户体验效果,使得某一元素在 Android 不同尺寸、不同分辨率的、不同系统的手机上具备相同的显示效果，能够保持界面上的效果一致,我们需要对各种手机屏幕进行适配！

基本概念

像素（px）：

单位：px（pixel），像素就是手机屏幕的最小构成单元

分辨率

px（pixel），1px = 1像素点，手机在横向、纵向上的像素点数总和 一般描述成 宽高 ，即横向像素点个数 纵向像素点个数（如1080 x 1920）。

屏幕尺寸

单位 英寸（inch），手机对角线的物理尺寸

屏幕像素密度

单位：dpi，每英寸的像素点数。 例如每英寸内有 160 个像素点，则其像素密度为 160dpi。计算公式：像素密度 = 像素 / 尺寸 （dpi = px / in）

密度无关像素

density-independent pixel，叫dp或dip，与终端上的实际物理像素点无关。单位：dp，可以保证在不同屏幕像素密度的设备上显示相同的效果，是安卓特有的长度单位。dp 与 px 的转换：1dp = （dpi / 160 ） * 1px

独立比例像素

scale-independent pixel，叫sp或sip。单位：sp，字体大小专用单位 Android开发时用此单位设置文字大小。

DPI 的存在，不就是为了让大屏能显示更多的内容

适配方案

今日头条

参考项目地址：https://github.com/JessYanCoding/AndroidAutoSize

今日头条适配方案默认项目中只能以高或宽中的一个作为基准。

density 是 DisplayMetrics 中的成员变量，而 DisplayMetrics 实例通过 Resources#getDisplayMetrics 可以获得，而Resouces 通过 Activity 或者 Application 的 Context 获得。

如果每个 View 的 dp 值是固定不变的，那我们只要保证每个设备的屏幕总 dp 宽度不变，就能保证每个 View 在所有分辨率的屏幕上与屏幕的比例都保持不变，从而完成等比例适配，并且这个屏幕总 dp 宽度如果还能保证和设计图的宽度一致的话，那我们在布局时就可以直接按照设计图上的尺寸填写 dp 值

屏幕的总 px 宽度 / density = 屏幕的总 dp 宽度

在这个公式中我们要保证 屏幕的总 dp 宽度 和 设计图总宽度 一致，并且在所有分辨率的屏幕上都保持不变，我们需要怎么做呢？屏幕的总 px 宽度 每个设备都不一致，这个值是肯定会变化的，这时今日头条的公式就派上用场了

当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) = density

这个公式就是把上面公式中的 屏幕的总 dp 宽度 换成 设计图总宽度，原理都是一样的，只要 density 根据不同的设备进行实时计算并作出改变，就能保证 设计图总宽度 不变，也就完成了适配。

布局文件中 dp 的转换，最终都是调用 TypedValue#applyDimension(int unit, float value, DisplayMetrics metrics) 来进行转换:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public static float applyDimension(int unit, float value, DisplayMetrics metrics){
    switch (unit) {
        case COMPLEX_UNIT_PX:
            return value;
        case COMPLEX_UNIT_DIP:
            return value * metrics.density;
        case COMPLEX_UNIT_SP:
            return value * metrics.scaledDensity;
        case COMPLEX_UNIT_PT:
            return value * metrics.xdpi * (1.0f/72);
        case COMPLEX_UNIT_IN:
            return value * metrics.xdpi;
        case COMPLEX_UNIT_MM:
            return value * metrics.xdpi * (1.0f/25.4f);
        }
    return 0;
}

这里用到的 DisplayMetrics 正是从 Resources 中获得的。图片的decode，也是通过 DisplayMetrics 中的值来计算的。

当然还有些其他 dp 转换的场景，基本都是通过 DisplayMetrics 来计算的，这里不再详述。因此，想要满足上述需求，我们只需要修改 DisplayMetrics 中和 dp 转换相关的变量即可。

适配后的 density = 设备真实宽(单位px) / 360，接下来只需要把我们计算好的 density 在系统中修改下即可，代码实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

private static float sNonCompatDensity;
private static float sNonCompatScaledDensity;

private static void setCustomDensity(@NonNull Activity activity, @NonNull final Application application) {
    // 设计图宽度
    int customWidth = 360;
    final DisplayMetrics appDisplayMetrics = application.getResources().getDisplayMetrics();

    if (sNonCompatDensity == 0) {
        sNonCompatDensity = appDisplayMetrics.density;
        sNonCompatScaledDensity = appDisplayMetrics.scaledDensity;
        // 监听系统字体变化
        application.registerComponentCallbacks(new ComponentCallbacks() {
            @Override
            public void onConfigurationChanged(Configuration newConfig) {
                if (newConfig != null && newConfig.fontScale > 0) {
                    sNonCompatScaledDensity = application.getResources().getDisplayMetrics().scaledDensity;
                }
            }

            @Override
            public void onLowMemory() {

            }
        });
    }

    final float targetDensity = appDisplayMetrics.widthPixels / customWidth;
    final float targetScaledDensity = targetDensity * (sNonCompatScaledDensity / sNonCompatDensity);
    final int targetDensityDpi = (int) (160 * targetDensity);

    appDisplayMetrics.density = targetDensity;
    appDisplayMetrics.scaledDensity = targetScaledDensity;
    appDisplayMetrics.densityDpi = targetDensityDpi;

    DisplayMetrics activityDisplayMetrics = activity.getResources().getDisplayMetrics();
    activityDisplayMetrics.density = targetDensity;
    activityDisplayMetrics.scaledDensity = targetScaledDensity;
    activityDisplayMetrics.densityDpi = targetDensityDpi;
}

优点

• 使用成本非常低，操作非常简单，使用该方案后在页面布局时不需要额外的代码和操作，这点可以说完虐其他屏幕适配方案。
• 侵入性非常低，该方案和项目完全解耦，在项目布局时不会依赖哪怕一行该方案的代码，而且使用的还是 Android 官方的 API，意味着当你遇到什么问题无法解决，想切换为其他屏幕适配方案时，基本不需要更改之前的代码，整个切换过程几乎在瞬间完成，会少很多麻烦，节约很多时间，试错成本接近于 0。
• 可适配三方库的控件和系统的控件(不止是是 Activity 和 Fragment，Dialog、Toast 等所有系统控件都可以适配)，由于修改的 density 在整个项目中是全局的，所以只要一次修改，项目中的所有地方都会受益。
• 不会有任何性能的损耗

缺点

会影响第三方控件

解决方案：

1. 我们自身作出修改，去适应三方库的设计图尺寸，我们将项目自身的设计图尺寸修改为这个三方库的设计图尺寸，就能完成项目自身和三方库的适配
2. 按 Activity 为单位，取消当前 Activity 的适配效果，改用其他的适配方案

SmallestWidth

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

1
2
3
4
5
6
7
8
9

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

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

1
2
3
4
5
6
7
8
9
10
11

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

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

如果系统根据当前设备屏幕的 最小宽度 (smallestWidth) 没找到对应的 values-swdp 文件夹，则会去寻找与之 最小宽度 (smallestWidth) 相近的 values-swdp 文件夹，系统只会寻找小于或等于当前设备 最小宽度 (smallestWidth) 的 values-swdp，这就是优于 宽高限定符屏幕适配方案 的容错率，并且也可以少生成很多 values-swdp 文件夹，减轻 App 的体积。

优点

1. 非常稳定，极低概率出现意外
2. 不会有任何性能的损耗
3. 适配范围可自由控制，不会影响其他三方库
4. 在插件的配合下，学习成本低

缺点

1. 在布局中引用 dimens 的方式，虽然学习成本低，但是在日常维护修改时较麻烦
2. 侵入性高，如果项目想切换为其他屏幕适配方案，因为每个 Layout 文件中都存在有大量 dimens 的引用，这时修改起来工作量非常巨大，切换成本非常高昂
3. 无法覆盖全部机型，想覆盖更多机型的做法就是生成更多的资源文件，但这样会增加 App 体积，在没有覆盖的机型上还会出现一定的误差，所以有时需要在适配效果和占用空间上做一些抉择
4. 如果想使用 sp，也需要生成一系列的 dimens，导致再次增加 App 的体积
5. 不能自动支持横竖屏切换时的适配，如上文所说，如果想自动支持横竖屏切换时的适配，需要使用 values-wdp 或 屏幕方向限定符 再生成一套资源文件，这样又会再次增加 App 的体积
6. 不能以高度为基准进行适配，考虑到这个方案的名字本身就叫 最小宽度限定符适配方案，所以在使用这个方案之前就应该要知道这个方案只能以宽度为基准进行适配，为什么现在的屏幕适配方案只能以高度或宽度其中的一个作为基准进行适配

AndroidAutoSize

根据 今日头条屏幕适配方案 优化的屏幕适配框架。

其他方案

UI适配框架

例如 Android 屏幕适配方案，不过已经停止维护

宽高限定符适配

1
2
3
4
5
6
7
8
9

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

Android 屏幕适配终结者

Android 屏幕适配终结者 ，也是基于头条的原理，不过是操作 pt，所以不是改 DisplayMetrics#density，而是 DisplayMetrics#xdpi，由于适配不会失效

参考资料

• Android 目前稳定高效的UI适配方案
• 骚年你的屏幕适配方式该升级了!-今日头条适配方案
• 骚年你的屏幕适配方式该升级了!-SmallestWidth 限定符适配方案
• 今日头条屏幕适配方案终极版
• Android 屏幕适配方案
• Android 屏幕适配终结者
• Android 屏幕适配从未如斯简单(8月10日最终更新版)