系列介绍
临时抱佛脚(也说急来抱佛脚) 指平时不烧香,遇到危难时才求佛保佑。比喻事到临头才慌忙想办法应付。
少壮没有努力,所以现在知识不给力。
抱佛脚的目的只有一个,就是斩获自己期望中的offer.
灵魂拷问:你们 Android 开发的时候,对于 UI 稿的 px 是如何适配的?
我只会:dp加上自适应布局以及weight布局比例来适配(也就是传统屏幕适配方案)。
我的ui适配知识深度止步于此。
简直是十分非常太菜了。
名词解释
dpi
:像素密度是屏幕单位面积内的像素数,称为 dpi(每英寸的点数)。通常以尺寸作为手机大小衡量单位,所以dpi计算公式为 : 对角线px/ 手机尺寸 。也就是如下图所示
目录
- 大家都在用的屏幕适配方案
- 今日头条屏幕适配方案学习
- 官方屏幕适配方案
- 头条方案的第三方加强版 AndroidAutoSize
- 总结
一,大家都在用的屏幕适配方案
传统适配方案解释
Android官方提供了 dp单位来适配屏幕,传统适配方案中,我们通常会结合约束布局和weight比例来实现布局的还原。
dp和px的转换
android中的dp在渲染前会将dp转为px,计算公式:
-
px = density * dp;
-
density = dpi / 160;
-
px = dp * (dpi / 160);
屏幕的dpi则是每单位尺寸像素密度。
dpi计算公式查看名词解释部分。
传统方案问题
由dpi计算方式可知,dp可以实现大部分相似宽高屏幕,以及相似比例像素密度的ui适配。但却不是完全的屏幕等比关系。
同样的20dp可能占用屏幕的宽高比例会因手机而异。
这就导致了不同设备之间通过约束和dp适配可能会呈现不同的效果。
如下图demo中所示:
img img<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<ImageView
android:src="@drawable/ic_launcher_background"
android:layout_width="match_parent"
android:scaleType="centerCrop"
android:layout_height="200dp"
app:layout_constraintTop_toTopOf="parent"
android:layout_margin="150dp"/>
</androidx.constraintlayout.widget.ConstraintLayout>
可以看到相同的布局文件,在不同尺寸相同dpi的设备中,表现就十分迥异。
可见对于各种形状和大小的安卓手机,ui展示变得奇怪,也就十分常见了。
传统方案的优势
传统适配方案按照像素密度来做显示适配。这样在同样像素密度,不同屏幕大小的设备中,会有这一致的大小体验。
比如一个小屏手机中的块,在大屏设备中也是相似的大小。
这样就可以在大屏设备中也就能显示更多的内容,在做好多布局适配的情况下,能有更符合美学的展示效果。
而不是粗暴的等比放大。
二,今日头条开源屏幕适配方案使用
方案目标
从文章中可知,今日头条的目标是,以宽度为基准,等比还原设计图。
这样在宽度大同小异的手机设备中,将会有更加优秀的还原体验。
方案原理
该方案是为了以宽度为基准还原ui图。
前面提到 px和dp的转换是 px = dp * density; 而想要让所有手机的宽度都有一样的dp。只需要修改density的值,就能转换出想要的px。
-
计算出density
比如 当以360dp为设计宽度基准的时候。
需要的 density 计算方式如下:
dp
为设计dp
sW
为屏幕宽度px
-
找到要替换density的值对象
通过阅读源码,我们知道布局文件中dp转成px
- 首先会调用 TypedArray#getDimensionPixelSize
- 然后调用 TypedValue#complexToDimensionPixelSize
- 最终调用TypedValue#applyDimension
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;
}
可以看到常用的 dp和sp转换是使用的 metrics.density
和 metrics.scaledDensity
头条文章中也说,还有些其他dp转换的场景,基本都是通过DisplayMetrics 来计算的。不再赘述。
所以我们只需要替换resource.mMetrics 的density 和 densityDpi 以及 scaledDensity 的值就行了
-
替换application和activity的 resource.mMetrics
替换之后,系统转换px的时候自然就会使用该density了,和简单就实现了以屏幕宽度为基准的适配方案。
项目使用
//动态代理减少模板代码
inline fun <reified T> noOpDelegate(): T {
return Proxy.newProxyInstance(
ClassLoader.getSystemClassLoader(),
arrayOf(T::class.java)
) { _, _, _ ->
} as T
}
class App : Application() {
override fun onCreate() {
super.onCreate()
fun setDisplay(resources: Resources) {
with(resources.displayMetrics) {
val originDensityRatio = scaledDensity / density
density = widthPixels / 360f
densityDpi = (density * 160).toInt()
scaledDensity *= originDensityRatio
}
}
///修改app.resources.displayMetrics
setDisplay(resources)
///字体改变回调
registerComponentCallbacks(object : ComponentCallbacks by noOpDelegate() {
override fun onConfigurationChanged(newConfig: Configuration) {
if (newConfig.fontScale > 0) {
setDisplay(resources)
}
}
})
///修改activity.resources.displayMetrics
registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks by noOpDelegate() {
override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {
setDisplay(activity.resources)
}
})
}
}
在添加之后,就可以看到手机完美得以360dp为全屏宽度基准了
用我的小米10演示下适配前后的样子:
img img可以看到效果还是挺不错的。
字体适配
当然文章中还提到了文本大小的适配,也就是 scaledDensity的值计算。
文章中的计算原理如下:
通过计算之前scaledDensity和density的比获得现在的scaledDensity
最后调用 Application#registerComponentCallbacks 注册下 onConfigurationChanged 监听
,在字体变化的时候去更新scaledDensity。
代码参考前面 项目使用 的代码
头条适配问题思考
头条适配方案以宽度为基准,适合手机设备,按宽度比例还原设计图,达到美观的效果。
然后这个方案的问题也很明显。在大屏设备上,也是按照宽度等比还原设计图。
这就导致了app大屏幕运行就只是手机的放大版,完全没有体验性可言。
解决方案:我思考了一下,这就需要在检测屏幕为大屏幕的时候,主动取消该适配方案。并做对应布局更换适配处理。
而更换的大屏适配方案,可以使用 下一节的 smalllest 屏幕适配方案
三,官方屏幕适配方案-限定符 or .9png
首先放上官方说明
smallestWidth 限定符
最小宽度限定符是谷歌官方支持的屏幕多布局多资源方案。
使用“最小宽度”屏幕尺寸限定符,您可以为具有最小宽度(以密度无关像素 dp 或 dip 为度量单位)的屏幕提供备用布局。
比如:
res/layout/main_activity.xml # 用于手机设备 (小于 600dp 屏幕宽度的设备)
res/layout-sw600dp/main_activity.xml # 用于 7寸平板 (600dp 或者更宽屏幕的设备)
最小尺寸参考
最小宽度限定符指定屏幕两侧的最小尺寸,而不考虑设备当前的屏幕方向,因此这是一种指定布局可用的整体屏幕尺寸的简单方法。
下面是其他最小宽度值与典型屏幕尺寸的对应关系:
-
320dp:典型手机屏幕(240x320 ldpi、320x480 mdpi、480x800 hdpi 等)。
-
480dp:约为 5 英寸的大手机屏幕 (480x800 mdpi)。
-
600dp:7 英寸平板电脑 (600x1024 mdpi)。
-
720dp:10 英寸平板电脑(720x1280 mdpi、800x1280 mdpi 等)。
再结合屏幕方向限定符
如下:
res/layout-land/main_activity.xml # For handsets in landscape
res/layout-sw600dp/main_activity.xml # For 7” tablets
这样就能完成大多数场景下的屏幕适配工作
.9 png 九宫格位图
普通位图在放大或者缩小时候,会失真,被拉伸挤压。
解决方案是使用九宫格位图,这种特殊格式的 PNG 文件会指示哪些区域可以拉伸,哪些区域不可以拉伸,以及安全的内容区域。
九宫格位图基本上是一种标准的 PNG 文件,但带有额外的 1 像素边框,指示应拉伸哪些像素(并且带有 .9.png
扩展名,而不只是 .png
)。
安卓框架默认支持。
这种开发者基本上很常用。不再赘述,不清楚的可以百度。
屏幕分辨率限定符(不建议使用)
该限定符官方文档并没有说明,我也找到了一篇文章,从解析源码处入手分析了该限定符的用法和逻辑。链接在这。该作者是个大佬,直接扒了框架的源码,羡慕大佬的厉害中。
本人以前使用的时候也是云里雾里的。
资源文件夹用法如下 :
- values-480x320
- layout-480x320
现在总结一下改文章的结论:
- 分辨率限定的优先级排序十分靠后,仅仅先于平台版本。
- 分辨率限定会排除任一维度大于实际分辨率的配置。比如有 2020x1080、1080x740以及960x540限定的资源。一台1920x1080的手机,会排除掉2020x1080的资源,匹配1080x740或960x540中的一个资源。
限定分辨率总结:
这个限定符生效逻辑十分诡异,有悖常理,不是只适配特定分辨率,而是会影响到所有完全大于该分辨率的屏幕,用了得不偿失,建议不要使用。
四,头条方案的第三方加强版 AndroidAutoSize
首先送上的是作者的介绍文章
AndoridAutoSize库是作者根据头条屏幕适配方案,经过不断的优化和扩展完善的一个屏幕适配库。里面支持了 dp、sp、pt、in、mm 等各种单位进行布局。
因为没有详细查阅该库源码,所以不在这里进行赘述。写在这里作为一个备选方案以备后续使用学习
五,总结
在手机场景下,可以使用头条的适配方案完美还原手机的设计稿。
而在大屏或者特殊屏幕尺寸场景,可以使用sw 和 方向限定符结合,使用不同的layout 或者dimens文件夹,将会有不错的结果。
通过这次屏幕适配方案,我也有不少收获
- 了解了 sw 限定符的规则
- 了解了分辨率限定符的规则
- 了解了今日头条屏幕适配的原理
网友评论