专栏首页薄荷前端提示Android屏幕适配方案分析

提示Android屏幕适配方案分析

为什么要屏幕适配

Android开发过程中我们常用的尺寸单位有px、dp,还有一种sp一般是用于字体的大小。但是由于px是像素单位,比如我们通常说的手机分辨例如1920*1080都是px的单位。现在Android屏幕分辨率碎片化720x1280、1080x1920、2280x1080,这就造成例如187px会在各个分辨率的机型上都是显示一样大小的,那肯定不是我们想要的效果,所以用px单位我们是难以达到适配效果的,那么为什么用dp可以呢?

使用px单位从左到右依次为 480 * 800、1080 * 1920、1440 * 2560

使用dp单位从左到右依次为 480 * 800、1080 * 1920、1440 * 2560

屏幕总宽度依次为 320dp、415dp、411dp

那么什么是dp?

dp指的是设备独立像素,以dp为尺寸单位的控件,在不同分辨率和尺寸的手机上代表了不同的真实像素,比如在分辨率较低的手机中,可能1dp=1px,而在分辨率较高的手机中,可能1dp=2px,这样的话,一个187dp高度的控件,在不同的手机中就能表现出差不多的大小了。

dp如何计算成px

android中的dp在渲染前会将dp转为px,计算公式:

  • px = density * dp;
  • density = dpi / 160;
  • px = dp * (dpi / 160);

而dpi是根据屏幕真实的分辨率和尺寸来计算的,每个设备都可能不一样的。

由于density不是固定不变的,所以每个分辨率不同的设备他们的density都肯定不相等,这样就会造成每个设备的宽/高对应的总dp都是不同的,假设480 * 800分辨率的density是1.51080 * 1920分辨率的density是2.61440 * 2560分辨率的density是3.5。那么它们对应的宽度总dp = (宽度px) / density,分别为320dp、415dp、411dp。可以看出单位为dp的时候三个设备之间的差距就不是很大了,但是这样肯定还是不能满足我们对屏幕适配的要求的。下面来看看Android常见的三种比较成熟的屏幕适配方案,并分析这几种方案的优劣。

屏幕适配方案

1.1 宽高限定符适配

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

比如我们的设计图 375 * 667为基准分辨率

  • 宽度为375,将任何分辨率的宽度整分为375份,取值为x1-x375
  • 高度为667,将任何分辨率的高度整分为667份,取值为y1-y667

那么对于1080*1920的分辨率的dimens文件来说,

  • x1=(1080/375)*1=2.88px
  • x2=(1080/375)*2=5.76px
  • y1=(1920/667)*1=2.87px
  • y2=(1920/667)*2=5.75px

当代码里面引用高度为y_187,在APP运行时会根据当前设备分辨率去找对应xml文件中对应的高度,我们就可以按照设计稿上的尺寸填写相对应的dimens引用了,这样基本解决了我们的适配问题,而且极大的提升了我们UI开发的效率。

验证方案

简单通过计算验证下这种方案是否能达到适配的效果,例如设计图上有一个宽187dp的View。

480 * 800

  • 设计图占宽比: 187dp / 375dp = 0.498
  • 实际在480 * 800占宽比 = 187 * 1.28px / 480 = 0.498

1080 * 1920

  • 设计图占宽比: 187dp / 375dp = 0.498
  • 实际在1080 * 1920占宽比 = 187 * 2.88px / 1080 = 0.498
  • 计算高同理

但是这个方案有一个致命的缺陷,那就是需要精准命中才能适配,比如1920x1080的手机就一定要找到1920x1080的限定符,否则就只能用统一的默认的dimens文件了。而使用默认的尺寸的话,UI就很可能变形,简单说,就是容错机制很差。

1.2 smallestWidth适配

smallestWidth适配,或者叫sw限定符适配。指的是Android会识别屏幕可用高度和宽度的最小尺寸的dp值(其实就是手机的宽度值),然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。

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

可以把 smallestWidth 限定符屏幕适配方案 当成这种方案的升级版,smallestWidth 限定符屏幕适配方案 只是把 dimens.xml 文件中的值从 px 换成了 dp,原理和使用方式都是没变的

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

复制代码

验证方案

1920 * 1080分辨率的手机,dpi为420,我们同样设置一个View为187dp宽

  • density = (dpi = 420) / 160 = 2.6
  • 屏幕总宽度dp = 1080 / density = 415
  • 找到文件夹values-sw410dp下的187dp = 204.45dp
  • 通过公式px = density * dp,计算出px = 531.57
  • 算出占屏幕宽度的比例,56.86 / 1080 = 0.492

1440 * 2560分辨率的手机,dpi为560,我们同样设置一个View为187dp宽

  • density = (dpi = 420) / 160 = 3.5
  • 屏幕总宽度dp = 1440 / density = 411
  • 找到文件夹values-sw410dp下的187dp = 204.45dp
  • 通过公式px = density * dp,计算出px = 715.57
  • 算出占屏幕宽度的比例,715.57 / 1440 = 0.496

因为识别的文件夹是values-sw410dp的文件夹,但是屏幕宽度为415dp和411dp,所以最后计算出的占比会有一点点误差,基本可以忽略不计,可以达到相对比较准确的适配效果

优点

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

缺点

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

1.3 今日头条适配方案

今日头条屏幕适配方案的核心原理在于,根据以下公式算出 density

默认px = density * dp,也就是屏幕总宽度dp = 屏幕宽度px / density,这个时候我们假设所有设备上的屏幕总宽度dp会等于我们设计图375dp,那么可以得出一个公式:

density = 屏幕宽度px / 设计图宽度(375dp)

然后我们通过系统api,将density赋值给系统,抛弃掉系统默认计算density的计算公式。

这样可以很巧妙的实现屏幕适配,而且侵入性极低,甚至可以忽略不计。

验证方案

1920 * 1080分辨率的手机,我们同样设置一个View为187dp宽,设计图宽度为375dp

  • density = (屏幕宽度px = 1080) / 375 = 2.88
  • View宽度 = density * 187dp = 538.56
  • 算出占屏幕宽度的比例,57.6 / 1080 = 0.498

1440 * 2560分辨率的手机,我们同样设置一个View为187dp宽,设计图宽度为375dp

  • density = (屏幕宽度px = 1440) / 375 =3.84
  • View宽度 = density * 187dp = 718.08
  • 算出占屏幕宽度的比例,718.08 / 1440 = 0.498

可以看出,这种方案是完全没有误差的,而且侵入性极低,只需要修改系统的density。虽然修改系统的density属性会产生一小部分影响,但是基本都是很好解决的。

优点

  1. 使用成本非常低,操作非常简单
  2. 侵入性非常低
  3. 可适配三方库的控件和系统的控件

缺点

  1. 会全局影响APP的控件大小,例如一些第三方库控件,他们设计的时候可能设计图尺寸并不是像我们一样是375dp,这样就会导致控件大小变形等一些问题。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 浅谈web前端的发展趋势

    相信web前端开发的伙伴们,在职业道路上,十有八九会受到这样的质疑或者嘲讽(大多数其实还是调侃之意)。写几个标签,懂一些HTML CSS 就是程序员? 你们知道...

    用户2356368
  • 前端骨架屏方案小结骨架屏

    最近在项目不时有用到骨架屏的需求,所以抽时间对骨架屏的方案作了一下调研,骨架屏的实践已经有很多了,也有很多人对自己的方案作了介绍.在这里按照个人的理解做了一个汇...

    用户2356368
  • 基于 socket.io 快速实现一个实时通讯应用WebSocket概念实现用socket.io实现一个实时接收信息的例子分析webSocket协议参考文章

    随着web技术的发展,使用场景和需求也越来越复杂,客户端不再满足于简单的请求得到状态的需求。实时通讯越来越多应用于各个领域。

    用户2356368
  • HDUOJ---2546 饭卡

    饭卡 Time Limit: 5000/1000 MS (Java/Others)    Memory Limit: 32768/32768 K (Java/O...

    Gxjun
  • 洛谷P1976 鸡蛋饼

    题目背景 Czyzoiers 都想知道小 x 为什么对鸡蛋饼情有独钟。经过一番逼问,小 x 道出 了实情:因为他喜欢圆。 题目描述 最近小 x 又发现了一个关于...

    attack
  • Android开发笔记(一)像素的单位

    老子曾说“天下难事必作于易,天下大事必作于细”,其实Android开发也是如此。博主一开始学android的时候,对像素单位不知其所以然,只知一根筋的填数字...

    用户4464237
  • Excel如何实现数据多人修订后的追踪与确认?

    具体操作如下:首先利用技巧226,227将工作簿进行共享,并加载“比较合并工作簿”按钮,并保存工作簿为228.xlsx。(下图1,2处)

    砸漏
  • 他们的数据是怎么来的?调研、监测、访谈,解析互联网咨询公司的数据来源

    我们经常会看到一些互联网研究公司发布的研究报告,《2016网购行为报告》、《XX类APP市场占有率报告》、《移动端社交行为报告》等等。 这些公司比较有代表性的如...

    数说君
  • AI时代就业指南-大数据职业发展与规划

    本文分享文档是2017年4月23日在南山云谷举行的《未来已来:AI时代就业指南》沙龙活动嘉宾黄崇远的《大数据职业发展与规划》,查看活动回顾。 ? 想要知道大数据...

    小莹莹
  • Kubernetes集群部署关键知识总结

      Kubernetes集群部署需要安装的组件东西很多,过程复杂,对服务器环境要求很苛刻,最好是能连外网的环境下安装,有些组件还需要连google服务器下载,这...

    欢醉

扫码关注云+社区

领取腾讯云代金券