阅读 591

Android 屏幕适配剖析

前言

众所周知,Android授权的厂商不计其数,生产出的机型也数不胜数,导致尺寸碎片化很严重。当然,都9102年了,大家逐渐得到了最优解,国内主流机型基本上都在720、1080、1440徘徊,最多高度上各有所长,但是还是保留着不少其他分辨率的手机,先来看一组数据(来源:友盟)——

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

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

  1. 善于使用RelativeLayout、Linearlayout、ConstraintLayout;
  2. 合理使用wrap_content、match_content;
  3. 使用minHeight、minWidth、lines、ellipsize等等属性;
  4. 使用dp、sp单位;
  5. 以某个页面为单位针对不同的手机使用不同的布局、图片、dimen;

但是我想说,以上种种,只是一个Android开发应该具备的基本素质。也许有人会问,这些还不够吗?而且dp、sp不已经是官方适配过了的单位吗?下面我们就来逐步剖析。

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

设备独立像素(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,个人认为这篇文章是讲述比较全面、靠谱、符合事实的。

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

我们首先明白,当我们假定的认为像素点都是趋于正方形时,密度只能影响视觉呈现的物理大小和精细程度,屏幕上高宽都为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的手机上只能占据三分之一的屏幕。

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

为什么要二次适配

上节举例中说到,大部分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;

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

怎么做二次适配

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

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

穷举宽高限定符

我们都知道,宽高限定符的匹配规则是,双边都小于屏幕分辨率的最接近的值。根据这个规则,我们尽可能的枚举出所有的分辨率(虽然分辨率有很多,但是我们只需要按照宽度来枚举即可,高度设置成略大于宽度)。而根据testinwetest云真机的分辨率,我们可以得出文件结构如下:

+-- 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. 侵入性比较高,依赖技术人员的素养;

穷举最小宽度限定符

最小宽度限定符,是指在逻辑宽度上限定使用小于并且最接近于屏幕宽度的资源。而逻辑宽度(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. 侵入性比较高,依赖技术人员的素养;

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

选择onMeasure进行Hook

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

典型的例子是AndroidAutoLayout,它的使用方法详见ReadMe,这里不再赘述。其核心思想是便是通过重写其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点,它虽然优点很明显,但是同样的缺点也很明显,那有没有一个切入点,既可以自动适配,又不用写这么多代码,侵入性也不高呢?字节跳动团队给了我们答案

选择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() 
    }
    复制代码
  6. 某些系统可能因为框架修改导致修改DisplayMetrics失效,比如MIUI7 + Android5.1.1;
  7. 需要考虑特殊activity不需要适配;
  8. 因为fragment其实用的是activity的resource,如果其中一个fragment不需要适配,那么需要考虑切换fragment时适配重置;

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

收笔

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


本文作者: timedance
本文链接: www.tktimedance.com/posts/a5563…
Demo地址: github.com/timedance/S…
版权声明: 本博客所有文章除特别声明外,均采用 BY-NC-ND 许可协议。转载请注明出处!