9102年了，再谈屏幕适配！

1前言

众所周知，Android授权的厂商不计其数，生产出的机型也数不胜数，导致尺寸碎片化很严重。

当然，都9102年了，大家逐渐得到了最优解，国内主流机型基本上都在720、1080、1440徘徊，最多高度上各有所长，但是还是保留着不少其他分辨率的手机，先来看一组数据（来源：友盟）——
阿里P6P7【安卓】进阶资料分享+加薪跳槽必备面试题

如图所证上述结论的正确性，但是可以看到，每年都有比例不小的其他尺寸的手机占据着市场份额，更何况那些还在服役的古董机器。我相信，这部分用户群是不可能被产品经理所割舍的。

为了解决这个问题，我们当然可以

1. 善于使用RelativeLayout、Linearlayout、ConstraintLayout；

2. 合理使用wrap_content、match_content；

3. 使用minHeight、minWidth、lines、ellipsize等等属性；

4. 使用dp、sp单位；

5. 以某个页面为单位针对不同的手机使用不同的布局、图片、dimen；

但是我想说，以上种种，只是一个Android开发应该具备的基本素质。

也许有人会问，这些还不够吗？而且dp、sp不已经是官方适配过了的单位吗？下面我们就来逐步剖析。

2为什么官方需要使用设备独立像素适配

设备独立像素（dp、sp），又叫逻辑像素，是一种用缩放因子（scale）计算出来的、和像素有一定的换算比例的、不受设备分辨率和密度（ppi）制约的尺寸单位。

那么什么是分辨率，什么是ppi，什么是dpi。

分辨率是指在手机屏幕中横竖都有多少个像素点，所谓的1080x1920即是指，屏幕的高有1920个像素点，宽有1080个像素点。

当我们继续查看手机参数的时候，会看到下一个指标，叫做ppi（Pixels Per Inch），表示每英寸所包含的像素点个数**，ppi越大，屏幕越细腻，但是超过了肉眼的分辨率是没有多大意义的**，以荣耀10为例，它的分辨率是1080x2280，那么对角线所具有的像素点个数为2522.86，而主屏尺寸是5.84英寸，那么我们可以得出每英寸所包含的像素点个数为431.997≈432，即ppi=432。

**那么dpi又是什么？**dpi（Dots per Inch），字面意思是每英寸包含的点数，但是实际上它现在更多的用于表示显示策略中的一个参数，在Android中，它是可以在系统中设置的、是可变的、是用于计算缩放因子的，也许在很多文章中我们都可以看到ppi就是dpi这样的言论，但是其实它们已经和最初的释义有所差异，具体参照WHAT IS DPI，个人认为这篇文章是讲述比较全面、靠谱、符合事实的。

https://blog.kyleduo.com/2019/06/29/what-is-dpi/

而独立像素，为什么不受分辨率和密度制约？

我们首先明白，当我们假定的认为像素点都是趋于正方形时，密度只能影响视觉呈现的物理大小和精细程度，屏幕上高宽都为x个像素所组成的正方形，在相同分辨率不同密度的手机中，他们只是视觉大小不一样，但是占据屏幕的比例是一致的。

那么我们只需要分析为什么独立像素不受分辨率制约。

我们知道，每个手机出厂时都写好了固定的dpi在手机的系统文件中，而dpi是形成独立像素的一个重要参数，我们可以根据dpi计算出dp和px的换算比例，也就是缩放因子（scale），从官方的文档，我们可以得出一个公式

1dp = 1px * scale = 1px * dpi / 160

也就是说，只要按照相同的规则控制dpi的数值，我们在宽度的纬度上，可以做到将所有分辨率都换算成一个数值的设备独立像素。

打个比方，现在大部分720x1280的手机的dpi都等于320，根据公式可得，宽度为360dp，而1080x1920的手机大部分的dpi都等于480，同样根据公式所得宽度为360dp。

那么相同的设备独立像素可以做什么呢？只要我们设置成宽度为180dp，那么它永远是占据屏幕宽度一半的比例。

而若是我们直接使用像素作为控件的单位，那么是无法保证它在不同分辨率的手机是占据相同的比例。

同样举个例子，在720x1280的手机上我们设置宽度为360px，它将占据一半的屏幕，而在1080x1920的手机上只能占据三分之一的屏幕。

这就是为什么官方推荐我们使用设备独立像素作为尺寸的单位。那么问题来了，既然设备独立像素这么优秀，那么我们——

3为什么要二次适配

上节举例中说到，大部分720x1280、1080x1920的手机宽度都是360dp，而大部分480x800的手机（dpi=240）宽度是320dp，那么当设计稿是360dp的时候，会发生什么。

举个例子，如下图所示，两台设备分辨率一致，但是dpi不一致，前者是480dpi，后者是540dpi（ps：不要问有没有这种机器，nove4e就是这样的），而设计稿是以360dp为基准，热度排名和贡献排名的宽度比例是3:4，则我们可以看到其在320dp下表现比较差，即使我们再如何布局，如何使用属性，它永远是不完美的，因为它的逻辑宽度永远都比设计稿少40dp。

而除了320dp、360dp，单国内手机的逻辑宽度就还有345.6dp、375.6dp、392.7dp、411.4dp、423.5dp等等。当然，理论上来说更多的逻辑宽度应该显示更多的内容，然而现实的情况往往不允许，这意味着——

1. 需要设计多套图；

2. 开发工作繁重、维护困难；

3. 增大包体积，毕竟不像iOS有App Slicing；

总之，就是人力成本太高。但是通过二次适配，我们可以做到一套设计图适配“所有”设备，一套布局“全家”适用。也许这不是最好的方案，但是综合来看这是最合适的方案，是最具性价比的方案。

那么我们要：

4怎么做二次适配

做二次适配的方法有多种，大体可以分为穷举和Hook。

注：因为当下大部分app的应用场景只在于竖屏，即使有横屏的界面也只需要保持高度不变，宽度自适应。退一步讲，真的有个别页面的高度也需要自适应时，可以具体场景具体分析，即使不做二次适配，也是ok的。因此以下的适配方法只从宽度的纬度来讲述。

穷举宽高限定符

我们都知道，宽高限定符的匹配规则是，双边都小于屏幕分辨率的最接近的值。

根据这个规则，我们尽可能的枚举出所有的分辨率（虽然分辨率有很多，但是我们只需要按照宽度来枚举即可，高度设置成略大于宽度）。

而根据testin、wetest云真机的分辨率，我们可以得出文件结构如下：

+-- res
|   +-- values
|   +-- values-330x320
|   +-- values-490x480
|   +-- values-550x540
|   +-- values-650x640
|   +-- values-730x720
|   +-- values-780x768
|   +-- values-810x800
|   +-- values-1100x1080
|   +-- values-1160x1152
|   +-- values-1210x1200
|   +-- values-1450x1440
|   +-- values-2170x2160

然后以1080px为基准，计算出1px在其他分辨率下的等比值 （注：默认values=values-1100x1080），假设目标分辨率的宽为W，则公式为：

px' = W/1080

举个例子，720px的分辨率的dimens值为：

<resources>
    <dimen name="x1">0.66px</dimen>
    <dimen name="x2">1.33px</dimen>
    <dimen name="x3">2.0px</dimen>
    <dimen name="x4">2.66px</dimen>
    <dimen name="x5">3.33px</dimen>
    <dimen name="x6">4.0px</dimen>
    <dimen name="x7">4.66px</dimen>
    <dimen name="x8">5.33px</dimen>
    <dimen name="x9">6.0px</dimen>
    <dimen name="x10">6.66px</dimen>
    .
    .
    .
    <dimen name="x1080">720px</dimen>
</resources>

配置好后，我们从以上分辨率中选择9种采样，看看实际运行效果如何：

由上图可见，运行结果是非常符合我们预期值的，占一半屏幕的还是占一半，热度排名和贡献排名的间距也基本差不多，唯一比较明显的是每行的文字字数±1，这是由于换算之后的像素有小数点造成的，但是这是可以接受的。

然后我们再来分析一下极端情况，首先因为我们是穷举分辨率，所以此处不需要考虑dpi，又因为我们穷举的分辨率的宽是320-2160，所以我们可以从这个角度考虑边界值：

1. 宽低于320px，匹配默认values，此种情况可以认为不存在；

2. 宽等于某一个枚举值（假设为720px），高度恰好小于730px，匹配大一级的values，但是因为我们设置的高度只是略大于宽，可以认为此种情况不存在；

3. 宽大于某一个枚举值，但是小于下一级的宽度（假设为1600px），匹配values-1450x1440；

4. 宽小于某一个枚举值，但是大于上一级的宽度（假设为1300px），匹配values-1210x1200，等同于第3点；

5. 宽大于2160px，匹配values-2170x2160，等同于第3点；

我们再看看3、4、5的运行效果如何：

从结果可以看出，我们出现的极端情况都是比预期值要宽，这是因为我们分辨率限定符是向下匹配的。

综上所述，我们得出结论：

1. 在已知分辨率的设备中，此方法基本可以完美适配机型；

2. 所有地方都建议统一使用px’，包括字体、自定义控件等，否则就会不兼容；

3. 因为字体也需要使用px’，所以app字体大小不会受到系统设置——字体显示大小的影响；

4. 因为使用了px’，代码中动态设置大小间距等等要额外注意单位；

5. 因为非1080px是换算比例，必然存在小数点，因此会存在一丢丢误差；

6. 枚举分辨率太多，导致dimens文件过多，包体积会增大一点，如果1080个px全部做映射的话，以示例中的枚举值大概要多0.5MB左右；

7. 因为存在场外分辨率，即使使用了此适配，依然不可以盲目的用绝对值，还是要配合其他控件属性一并使用；

8. 侵入性比较高，依赖技术人员的素养；

5穷举最小宽度限定符

最小宽度限定符，是指在逻辑宽度上限定使用小于并且最接近于屏幕宽度的资源。而逻辑宽度（W’）可以从分辨率（W）和dpi得知：

W' = W / ( dpi / 160 )

我们可以和穷举分辨率限定符一样，穷举出所有可能的逻辑宽度。为了分析，我们暂定文件结构如下：

+-- res
|   +-- values
|   +-- values-sw320dp
|   +-- values-sw360dp
|   +-- values-sw411dp

然后以360dp为基准，计算出1dp在其他逻辑宽度下的等比值 （注：默认values=values-sw360dp），假设目标逻辑宽度为W，则公式为：

dp' = W/360

同样的举个例子，320dp的逻辑宽度的dimens值为：

<resources>
    <dimen name="dp_1">0.89dp</dimen>
    <dimen name="dp_2">1.78dp</dimen>
    <dimen name="dp_3">2.67dp</dimen>
    <dimen name="dp_4">3.56dp</dimen>
    <dimen name="dp_5">4.44dp</dimen>
    <dimen name="dp_6">5.33dp</dimen>
    <dimen name="dp_7">6.22dp</dimen>
    <dimen name="dp_8">7.11dp</dimen>
    <dimen name="dp_9">8.00dp</dimen>
    <dimen name="dp_10">8.89dp</dimen>
    .
    .
    .
    <dimen name="dp_360">320dp</dimen>
</resources>

我们来看看实际的运行效果：

显而易见，又是符合我们预期的，但是不可避免的是逻辑宽度依旧存在刺头（原因见文章开头——为什么要二次适配），比如384dp（Nexus 4）、392dp（XiaoMi MIX2），所以我们再次来看看极端情况：

1. 逻辑宽度小于320dp，虽然没有数据支撑，但是我们假定的认为这已经是最小的宽度了，或者说，总有一个最小值（后续等统计出来，补上相关数据）；

2. 逻辑宽度位于两个枚举值之间，比如384dp；

3. 逻辑宽度大于411dp；

好了，因为最小宽度限定符依旧是向下匹配的，从而又回到了和上一节一模一样的情况——极端情况比预期值要宽，所以此处我们不再重复贴图。

那么我们总结一下此节：

1. 在已经枚举的逻辑宽度中，基本可以完美匹配设备；

2. xml、代码、包括自定义控件中都需要使用dp’的引用来保持一致；

3. 需要再配置一套TextSize，至于是用dp还是sp，仁者见仁智者见智（微信没有用sp）；

4. 枚举值映射的dp’值比宽高限定符少；

5. 相比宽高限定符兼容性略高，即使有些地方直接写成了dp，也是可以的；

6. 同样因为是换算比例，必然存在小数点，最好应用成px时，也可能存在一丢丢的误差；

7. 包体积和dimens的枚举数量成正比；

8. 同样存在场外dpi，不可以盲目的用绝对值；

9. 侵入性比较高，依赖技术人员的素养；

上面说了如何穷举来进行适配，但是如何穷举的既完整又简洁是一个难点，那么可不可能有一个测量的终点，所有的间距、大小、尺寸都会通过这里，我们在这个终点进行自动化适配就好了？当然是有的。

6选择onMeasure进行Hook

我们知道，view是需要先measure然后layout然后才draw的，那么切入点就来了——onMeasure。

典型的例子是AndroidAutoLayout，它的使用方法详见ReadMe，这里不再赘述。

https://github.com/hongyangAndroid/AndroidAutoLayout

其核心思想是便是通过重写其onMeasure，在调用super.onMeasure(widthMeasureSpec, heightMeasureSpec)之前重新根据屏幕宽度及高度设置了相关属性的值，如padding、margin、height、width、textSize。

当然，AndroidAutoLayout的上一次提交代码已经是在4 yeas ago，在它的设计之初，是假定的认为所有的手机的高宽比都是在一个恰当的范围，比如720x1280，所以它的高宽都分别进行了不同比例的缩放适配。

然而，9102年，手机的高宽比显然已经多种多样。所以，AndroidAutoLayout已经进入了它的局限性。

但是，它依旧是我们可以借鉴的目标，我们只需要将其高按照宽的缩放比例来缩放，或高或矮的手机自适应高度即可。（有兴趣的同学可以尝试一下，这里只讲如何hook~）

那么，onMeasure中怎么hook呢？

在AndroidAutoLayout中，它写了很多的自定义ViewGroup，比如AutoLinearLayout、AutoRelativeLayout、AutoFrameLayout，其实里面的代码都大同小异，我们以AutoLinearLayout为例——

@Override
protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {
    if (!isInEditMode()) { //这句代码不用管，用来判断是否是IDE预览模式的
        mHelper.adjustChildren();
    }
    super.onMeasure(widthMeasureSpec, heightMeasureSpec);
}

可以看到，AndroidAutoLayout在super.onMeasure之前只做了一件事，就是adjustChildren，修改控件属性值。

public void adjustChildren() {
    AutoLayoutConifg.getInstance().checkParams(); //这句话不用管，用来检查库配置的

    for (int i = 0, n = mHost.getChildCount(); i < n; i++) {
        View view = mHost.getChildAt(i);
        ViewGroup.LayoutParams params = view.getLayoutParams();

        if (params instanceof AutoLayoutParams) {
            AutoLayoutInfo info = ((AutoLayoutParams) params).getAutoLayoutInfo();
            if (info != null) {
                info.fillAttrs(view);
            }
        }
    }
}

而adjustChildren中循环取到了所有表层childView的AutoLayoutParams，AutoLayoutParams继承于父类LayoutParams，它也没干啥事，主要是将需要适配的属性（如textSize）存储起来。

public static AutoLayoutInfo getAutoLayoutInfo(Context context,AttributeSet attrs) {
    ...
    //原来设计的时候是和宽度的相关的属性按宽度缩放，和高度相关的属性按高度缩放。但是总有特例，所以baseWidth、baseHeight就是用来强制约束缩放方向的。
    int baseWidth = a.getInt(R.styleable.AutoLayout_Layout_layout_auto_basewidth, 0);
    int baseHeight = a.getInt(R.styleable.AutoLayout_Layout_layout_auto_baseheight, 0);
    ...
    for (int i = 0; i < n; i++) {
        ...
        switch (index) {
            case INDEX_TEXT_SIZE:
                info.addAttr(new TextSizeAttr(pxVal, baseWidth, baseHeight));
                break;
            case INDEX_PADDING:
                info.addAttr(new PaddingAttr(pxVal, baseWidth, baseHeight));
                break;
            ...
        }
    }
    return info;
}

当然，不同的AutoAttr会实现各自的缩放方法，其实就是很简单的计算出设计稿宽高和屏幕宽高的比值，然后和attribute的原始值相乘，得到最终的属性值。

public void apply(View view) {
    int val;
    if (useDefault()) {
        val = defaultBaseWidth() ? getPercentWidthSize() : getPercentHeightSize();
    } else if (baseWidth()) {
        val = getPercentWidthSize();
    } else {
        val = getPercentHeightSize();
    }
    if (val > 0) {
        val = Math.max(val, 1);//for very thin divider
    }
    execute(view, val);//执行缩放，并将其设置到view或者layoutParams中
}

而apply在哪里被调用，其实就是在adjustChildren中的fillAttrs。

这样，hook就完成了。

当然，AutoAttr、Helper、AutoLayoutParams以及内部封装的AutoLayoutActivity、AutoUtils，这些都是设计思想，重要的是实现思路，其实你也可以简单粗暴的糅合在一起，啊哈哈~

既然是完美适配，那就随便贴几个乱七八糟的分辨率吧~

按照惯例，以下是此节总结：

1. 通过onMeasure作为切入点，基本可以完美适配屏幕，并且几乎没有性能损耗；

2. 同样1也是缺点，必须要实现的viewGroup、attribute才支持；

3. 对于自定义控件，适配工作会很繁重；

4. 对于需要修改属性的控件，同3；

5. 目前AndroidAutoLayout对于动态添加的控件不是很友好，需要添加完之后手动调用AutoUtils.auto(view)，这会带来额外的开销，当然使用者可以自行拓展来支持这一点；

6. 侵入性同样比较高，非常依赖技术人员的素养；

7. 原来的库，高宽是以不同比例缩放的，但是现在的手机高宽比差异都比较大，那么依照老规则显示效果会非常差，虽然可以强制指定控件的缩放方向，但是工作量会比较繁琐，因此可能需要自己修改一下源码；

8. 当然，AndroidAutoLayout拦截替换的是px，如有需要，是可以换成拦截dp、sp的，这个不重要，重要的是hook点。

话说回来，其实onMeasure是一个浅层次的hook点，它虽然优点很明显，但是同样的缺点也很明显，那有没有一个切入点，既可以自动适配，又不用写这么多代码，侵入性也不高呢？字节跳动团队给了我们答案。

7选择DisplayMetrics.densityDpi进行Hook

前面有讲到dp和px之间的关系，我们可以知道：

1dp = 1px * dpi / 160

而系统一定有一个地方是用来转换这些单位的，比如TypedValue中：

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;
}

比如BitmapFactory中：

public static Bitmap decodeResourceStream(@Nullable Resources res, @Nullable TypedValue value,@Nullable InputStream is, @Nullable Rect pad, @Nullable Options opts) {
    validate(opts);
    if (opts == null) {
        opts = new Options();
    }

    if (opts.inDensity == 0 && value != null) {
        final int density = value.density;
        if (density == TypedValue.DENSITY_DEFAULT) {
            opts.inDensity = DisplayMetrics.DENSITY_DEFAULT;
        } else if (density != TypedValue.DENSITY_NONE) {
            opts.inDensity = density; 
        }
    }

    //inDensity是指资源所在的drawable文件夹的密度，inTargetDensity是指屏幕密度
    if (opts.inTargetDensity == 0 && res != null) {
        opts.inTargetDensity = res.getDisplayMetrics().densityDpi;
    }

    return decodeStream(is, pad, opts);
}

我们观察可以看到，他们都用到了DisplayMetrics.densityDpi这个属性，那么我们只需要根据屏幕密度来修改这个属性值，就可以假装屏幕永远为360dp的逻辑宽度。

而DisplayMetrics可以从三个地方得到：

// 系统的屏幕尺寸
val systemMetrics = Resources.getSystem().displayMetrics
// application的屏幕尺寸
val applicationMetrics = application.resources.displayMetrics
// activity的屏幕尺寸
val activityMetrics = activity.resources.displayMetrics

我们只需要修改application和activity的就行，system则建议不修改，用于保留一份原始数据，而且即使改了也没什么用，它是用于获取系统资源的。

从上文我们可以很容易的得知当前屏幕的逻辑宽度是：

/**
 *  注意这里widthPixels不要用real width，原因有二：
 *  1.available display width可能会小于real width，虽然大部分实际场景中是一样的；
 *  2.在1的场景中（比如说屏幕左右有个装饰栏？），我们可能会出现，application中应用的是available display width，activity中应用的是real width，
 *  但是如果activity中使用了application.resource，那么此时间距大小会略小，这并没有什么关系。
 *  反过来如果我们修改的时候用的是real width，那么此时就会显示不下。
 */
val widthInDp = resources.displayMetrics.run {
    widthPixels / (densityDpi / 160) 
}

那么我们可以设置densityDpi为：

val targetDpi = resources.displayMetrics.widthPixels * 160 / 360  //360是我们的设计稿的逻辑宽度
val sysMetrics = Resources.getSystem().displayMetrics

resources.displayMetrics.run {
    densityDpi = targetDpi
    density = targetDpi / 160f
    scaledDensity = density * sysMetrics.scaledDensity / sysMetrics.density //因为用户会修改字体大小，因此需要根据原比例来得到新的scaledDensity
}

application.resources.displayMetrics.run {
    densityDpi = targetDpi
    density = targetDpi / 160f
    scaledDensity = density * sysMetrics.scaledDensity / sysMetrics.density
}

恢复的时候使用：

/**
 * 这里直接使用sysMetrics进行恢复，原因有二
 * 1.不用记录中间值
 * 2.在使用应用时如果修改了系统字体大小，sysMetrics会同步修改，不用再监听registerComponentCallbacks
 */
val sysMetrics = Resources.getSystem().displayMetrics

resources.displayMetrics.run {
    densityDpi = sysMetrics.densityDpi
    density = sysMetrics.density
    scaledDensity = sysMetrics.scaledDensity
}

application.resources.displayMetrics.run {
    densityDpi = sysMetrics.densityDpi
    density = sysMetrics.density
    scaledDensity = sysMetrics.scaledDensity
}

看看适配效果~

看起来perfect是不是？代码也很简单是不是？好像也没什么侵入性是不是？

然而万物有利也有弊：

1. 如果我们修改了application.resource，如果三方库有用到，会受影响；

2. 如果我们是通过registerActivityLifecycleCallbacks修改的activity.resource，那么三方库的activity会受影响；

3. 无法控制三方库可能也会同时修改；

4. 系统控件也会受到影响，比如toast，所以特别不建议将设计稿的逻辑宽度设置的比较极端，比如为了从设计稿照抄省事，将其设置成1080dp；

5. webView初始化的时候会还原density的值导致适配失效，需要修改如下：

/**
 * 继承webView，复写此方法
 **/
override fun setOverScrollMode(mode: Int) {
    super.setOverScrollMode(mode)
    adaptDensityDpi()
}

/**
 * 或者复写activity的此方法
 */
override fun getResources(): Resources {
    adaptDensityDpi() //注意避免死循环及重复修改
    return super.getResources() 
}

1. 某些系统可能因为框架修改导致修改DisplayMetrics失效，比如MIUI7 + Android5.1.1；

2. 需要考虑特殊activity不需要适配；

3. 因为fragment其实用的是activity的resource，如果其中一个fragment不需要适配，那么需要考虑切换fragment时适配重置；

所以以上的代码其实只能应用于demo当中，以期证明我们的方向是对的。剩下的我们还需要进一步解决上述列出的这些问题，还需要适配，需要封装，需要提高易用性、健壮性~比如AndroidAutoSize:

https://github.com/JessYanCoding/AndroidAutoSize

收笔

好了，本文到此结束。说了这么多，个人还是比较倾向于最后一种方案。当然，一个方案的成熟是需要成长的，项目也是，人也是。其他的，仁者见仁，智者见智咯。

Demo地址：

https://github.com/timedance/ScreenAdapter

阿里P6P7【安卓】进阶资料分享+加薪跳槽必备面试题