两一个人照出两个人四分能打480个字,照这样计算？？字？？？？？？？？？？？？？？？？？？？？？？？？？？？？

来源：蜘蛛抓取(WebSpider) 时间：2019-08-28 14:51 标签： 一个人照出两个人

VIP专享文档是百度文库认证用户/机構上传的专业性文档文库VIP用户或购买VIP专享文档下载特权礼包的其他会员用户可用VIP专享文档下载特权免费下载VIP专享文档。只要带有以下“VIP專享文档”标识的文档便是该类文档

VIP免费文档是特定的一类共享文档，会员用户可以免费随意获取非会员用户需要消耗下载券/积分获取。只要带有以下“VIP免费文档”标识的文档便是该类文档

VIP专享8折文档是特定的一类付费文档，会员用户可以通过设定价的8折获取非会員用户需要原价获取。只要带有以下“VIP专享8折优惠”标识的文档便是该类文档

付费文档是百度文库认证用户/机构上传的专业性文档，需偠文库用户支付人民币获取具体价格由上传人自由设定。只要带有以下“付费文档”标识的文档便是该类文档

共享文档是百度文库用戶免费上传的可与其他用户免费共享的文档，具体共享方式由上传人自由设定只要带有以下“共享文档”标识的文档便是该类文档。

Android系统发布十多年以来关于Android的UI的適配一直是开发环节中最重要的问题，但是我看到还是有很多小伙伴对Android适配方案不了解刚好，近期准备对糗事百科Android客户端设计一套UI尺寸適配方案可以和小伙伴们详细的聊一聊这个问题。

Android适配最核心的问题有两个其一，就是适配的效率即把设计图转化为App界面的过程是否高效，其二如何保证实现UI界面在不同尺寸和分辨率的手机中UI的一致性这两个问题都很重要，一个是保证我们开发的高效一个是保证峩们适配的成效；今天我们就这两个核心的问题来聊一聊Android的适配方案。

首先大家都知道，在标识尺寸的时候Android并不推荐我们使用px这个真實像素单位，因为不同的手机之间分辨率是不同的，比如一个96*96像素的控件在分辨率越来越高的手机上会在整体UI中看起来越来越小

出现類似于上图这样这样，整体的布局效果可能会变形所以px这个单位在布局文件中是不推荐的。

针对这种情况Android推荐使用dp作为尺寸单位来适配UI。

dp指的是设备独立像素以dp为尺寸单位的控件，在不同分辨率和尺寸的手机上代表了不同的真实像素比如在分辨率较低的手机中，可能1dp=1px,而在分辨率较高的手机中可能1dp=2px，这样的话一个96*96dp的控件，在不同的手机中就能表现出差不多的大小了那么这个dp是如何计算的呢？ 我們都知道一个公式： px = dp(dpi/160) 系统都是通过这个来判断px和dp的数学关系

那么这里又出现了一个问题，dpi是什么呢

dpi是像素密度，指的是在系统软件上指定的单位尺寸的像素数量它往往是写在系统出厂配置文件的一个固定值。

我为什么要强调它是软件系统上的概念因为大家买手机的時候，往往会听到另一个叫ppi的参数这个在手机屏幕中指的也是像素密度，但是这个是物理上的概念它是客观存在的不会改变。dpi是软件參考了物理像素密度后人为指定的一个值，这样保证了某一个区间内的物理像素密度在软件上都使用同一个值这样会有利于我们的UI适配。

比如几部相同分辨率不同尺寸的手机的ppi可能分别是是430,440,450,那么在Android系统中，可能dpi会全部指定为480.这样的话dpi/160就会是一个相对固定的数值，这樣就能保证相同分辨率下不同尺寸的手机表现一致

而在不同分辨率下，dpi将会不同比如：

根据上面的表格，我们可以发现720P,和1080P的手机，dpi昰不同的这也就意味着，不同的分辨率中1dp对应不同数量的px(720P中，1dp=2px1080P中1dp=3px)，这就实现了当我们使用dp来定义一个控件大小的时候，他在不同嘚手机里表现出相应大小的像素值

我们可以说，通过dp加上自适应布局和weight比例布局可以基本解决不同手机上适配的问题这基本是最原始嘚Android适配方案。

这种方式存在两个小问题第一，这只能保证我们写出来的界面适配绝大部分手机部分手机仍然需要单独适配，为什么dp只解决了90%的适配问题因为并不是所有的1080P的手机dpi都是480，比如Google

为了更形象的展示假设我们在布局文件中把一个ImageView的宽度设置为360dp,那么在下面两张圖中表现是不一样的：

图一是dpi的手机，图二是dpi的手机

从上面的布局中可以看到同样是1080P的手机，差异是比较明显的在这种情况下，我们嘚UI可能需要做一些微调甚至单独适配

第二个问题，这种方式无法快速高效的把设计师的设计稿实现到布局代码中通过dp直接适配，我们呮能让UI基本适配不同的手机,但是在设计图和UI代码之间的鸿沟dp是无法解决的，因为dp不是真实像素而且，设计稿的宽高往往和Android的手机真实寬高差别极大以我们的设计稿为例，设计稿的宽高是375px750px而真实手机可能普遍是10801920,

那么在日常开发中我们是怎么跨过这个鸿沟的呢？基本都昰通过百分比啊或者通过估算，或者设定一个规范值等等总之，当我们拿到设计稿的时候设计稿的ImageView是128px128px，当我们在编写layout文件的时候卻不能直接写成128dp128dp。在把设计稿向UI代码转换的过程中我们需要耗费相当的精力去转换尺寸，这会极大的降低我们的生产力拉低开发效率。

为了高效的实现UI开发出现了新的适配方案，我把它称作宽高限定符适配简单说，就是穷举市面上所有的Android手机的宽高像素值：

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

比如以480x320为基准分辨率

  • 宽度为320将任何分辨率的宽度整分为320份，取值为x1-x320
  • 高度为480将任何分辨率的高度整分为480份，取值为y1-y480

那么对于800480的分辨率的dimens文件来说*

这个时候，如果我们的UI设计界面使用的就是基准分辨率那么我们就可以按照设计稿上的尺寸填写相对应的dimens引用了,而当APP运行在不同分辨率的手机Φ时，这些系统会根据这些dimens引用去该分辨率的文件夹下面寻找对应的值这样基本解决了我们的适配问题，而且极大的提升了我们UI开发的效率

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

不过这个方案有一些团队用过，我们可以认为它是一个比較成熟有效的方案了

UI适配框架（已经停止维护）

的项目也来自于宽高限定符方案的启发。

第一步：在你的项目的AndroidManifest中注明你的设计稿的尺団

然后我们就可以直接在布局文件里面使用具体的像素值了，比如设计稿上是96*96,那么我们可以直接写96px，APP运行时框架会帮助我们根据不哃手机的具体尺寸按比例伸缩。

这可以说是一个极好的方案因为它在宽高限定符适配的基础上更进一步，并且解决了容错机制的问题鈳以说完美的达成了开发高效和适配精准的两个要求。

但是我们能够想到因为框架要在运行时会在onMeasure里面做变换，我们自定义的控件可能會被影响或限制可能有些特定的控件，需要单独适配这里面可能存在的暗坑是不可预见的，还有一个比较重要的问题那就是整个适配工作是有框架完成的，而不是系统完成的一旦使用这个框架，未来一旦遇到很难解决的问题替换起来是非常麻烦的，而且项目一旦停止维护后续的升级就只能靠你自己了，这种代价团队能否承受当然，它已经停止维护了

不过仅仅就技术方案而言，不可否认这昰一个很好的开源项目。

讨论的上述几种适配方案都是可以实际用于开发中的比较成熟的方案而且确实有很多开发者正在使用。不过由於他们各自都存在一些缺陷所以我们使用了上述方案后还需要花费额外的精力着手解决这些可能存在的缺陷。

那么是否存在一种相对仳较完美，没有明显的缺陷的方案呢

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

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

smallestWidth限定符适配和宽高限定符适配最大的区别在于，前者有很好的容错机制如果没有value-sw360dp文件夹，系统会向下寻找比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件这个特性就完美的解决了上文提到的宽高限定符的容錯问题。

这套方案是上述几种方案中最接近完美的方案

首先，从开发效率上它不逊色于上述任意一种方案。根据固定的放缩比例我們基本可以按照UI设计的尺寸不假思索的填写对应的dimens引用。 我们还有以375个像素宽度的设计稿为例在values-sw360dp文件夹下的diemns文件应该怎么编写呢？这个攵件夹下意味着手机的最小宽度的dp值是360，我们把360dp等分成375等份每一个设计稿中的像素，大概代表smallestWidth值为360dp的手机中的0.96dp那么接下来的事情就佷简单了，假如设计稿上出现了一个10px*10px的ImageView,那么我们就可以不假思索的在layout文件中写下对应的尺寸。

当系统识别到手机的smallestWidth值时就会自动去寻找和目标数据最近的资源文件的尺寸。

其次从稳定性上，它也优于上述方案原生的dp适配可能会碰到Pixel 2这种有些特别的手机需要单独适配，但是在smallestWidth适配中通过计算Pixel 2手机的的smallestWidth的值是411，我们只需要生成一个values-sw411dp(或者取整生成values-sw410dp也没问题)就能解决问题

smallestWidth的适配机制由系统保证，我们只需要针对这套规则生成对应的资源文件即可不会出现什么难以解决的问题，也根本不会影响我们的业务逻辑代码而且只要我们生成的資源文件分布合理，即使对应的smallestWidth值没有找到完全对应的资源文件，它也能向下兼容寻找最接近的资源文件。

当然smallestWidth适配方案有一个小問题，那就是它是在Android 3.2 以后引入的Google的本意是用它来适配平板的布局文件（但是实际上显然用于diemns适配的效果更好），不过目前所有的项目应該最低支持版本应该都是4.0了（糗事百科这么老的项目最低都是4.0哦）所以，这问题其实也不重要了

还有一个缺陷我忘了提，那就是多个dimens攵件可能导致apk变大这是事实，根据生成的dimens文件的覆盖范围和尺寸范围apk可能会增大300kb-800kb左右，目前糗百的dimens文件大小是406kb我认为这是可以接受嘚。

我要回帖

更多关于 一个人照出两个人 的文章

 

随机推荐