一、概述
可以使用match_parent和LinearLayout均分模式解决的不在探讨之列。
二、dp概念知识回顾
ppi:这是通过计算获得的,具体计算方法,可以通过百度搜索。之所以在这里引出来,是想说明,ppi和dpi是有区别的
dpi:这个数据和物理尺寸其实没有任何关系,这是手机厂商写入手机的,由于有这个数值的存在,手机才能将我们设置的虚拟密度dp,换成真实的像素px。换算方法:px=dp*dpi/160;
资源文件夹:各drawable文件夹分别对应不同的dpi 对应关系如下:drawable-xxhdpi(480dpi) drawable-xhdpi(320dpi) 以此类推,作用是相应的dpi的手机获取资源的时候会去相应的资源文件夹
获取。但是如,相关dpi手机找不到相对应的文件夹会怎么办?比如比较常见的420dpi的手机,这时候它会去就近的文件夹中获取也就是xxhdpi。但是,获取过来图片显示是先换算成dp,再显示的。
举例:如果有一张宽1080px的图片,放入了xxhdpi,如果有一部手机是1080p的dpi为480dpi,那这图片如果使用wrap_content显示,是满屏宽显示的。如果有一部手机1080p的dpi为420dpi,这时候
你会发现,图片并不是满屏宽显示,明明图片是1080的为什么在1080的手机上wrap_content无法满屏显示。这就是我上面提到的计算问题了,由于是先计算为dp,1080的图片在xxhdpi中,对应的dp
宽为:dp=px160/dpi=1080160/480=360dp.而420dpi的手机的满屏宽为:dp=1080*160/420=411dp。所以图片在这手机上并不能满屏显示。如图:
![](https://img.haomeiwen.com/i8014044/cd0171d7d0879f3c.png)
![](https://img.haomeiwen.com/i8014044/2f163fb2f8db61bd.png)
![](https://img.haomeiwen.com/i8014044/ef718c78dc802231.png)
![](https://img.haomeiwen.com/i8014044/7ca260f249f11e95.png)
![](https://img.haomeiwen.com/i8014044/200acb15c7df7927.png)
三、不使用方案可能出现的问题
如果我们不使用任何的方案,单纯的使用dp布局,在不同的手机上由于dpi的不同,就会产生不一样的显示,最终和设计稿产生较大的差异。比如:设计稿上有个540px*540px大小的按钮(我们的设
计稿一般是1080p(即宽是1080px)的),所以我们在布局这个按钮的时候用dp布局一般就会布局成180dp*180dp。如果在正常的(1080p)480dpi的手机上,根据上面的算法,换算成px,这个按钮
大小是540px540px,和设计稿是相符合的,但是如果在(1080p)420dpi的手机上,这个按钮就是472.5px472.5px就和设计稿不符合了。
三、主流方案对比
1.采用px作为值(我以前有个app采用了此方法,在这里为了说明距离采用的是网络图片)。如下图:微博参考https://blog.csdn.net/lmj623565791/article/details/45460089
![](https://img.haomeiwen.com/i8014044/785a3cb81c73a717.jpg)
![](https://img.haomeiwen.com/i8014044/fa3735c53e07a069.jpg)
这个方案是根据不同分辨率,采用不同的px,这样就直接跳过了dp这层,以达到适配的目的。
缺点和不足:1.维护非常的麻烦,由于手机种类繁多,会导致各种分别率非常多,需要不停添加。2.由于这个思想是将设计稿根据不同的手机分比率进行缩放,而非等比缩放,比如设计稿是1080*1920,如果有个
手机分辨率为1080*2160,这时候如果采用lay_y里面的值来布局高度就会形成拉伸,当然也可以解决,就是高度也采用lay_x里的数据。
2.采用适配框架,适配原理和上面的适配方案类似,不过是根据框架然后获得手机的分辨率和设计稿的尺寸进行对比然后将布局的文件的值进行重新计算(而上述方案是将手机分辨率先准备好,值也先计算好)。
github地址:https://github.com/hongyangAndroid/AndroidAutoLayout(此项目不维护了)推荐转移到https://github.com/JessYanCoding/AndroidAutoSize
缺点和不足:1.包含上述适配的缺点,因为是将设计稿尺寸和先手机分辨率进行计算然后缩放,所以会出现拉伸问题,而且采用第三方框架,需要作者的维护,如果作者停止维护,会对自己项目造成影响,而且使用
的时候要采用他们的自定义布局,所以用起来也不方便
好处:可以解决一些极端问题。比如:我以前遇到一个需求(图找不到了),需要将一个一个金币(含有不同颜色的状态),显示在背景的轨道上,而背景是一张全屏的图片(允许拉伸,但是金币位置要准确在轨道上),
这时候要是采用这种方法,然后准确按照设计稿的标注进行布局,由于在不同分辨率的手机上进行了重新拉伸计算,所以可以进行完美适配,就相当于将设计稿拉伸在全屏显示。
3.Java代码适配,采用Java代码重新计算可以解决一切适配问题。缺点:维护起来太麻烦了,而且都去计算也很麻烦,如果某个布局需要更改值,就需要在java代码中找到相应的代码进行修改,很是不方便。
所以,非难解决的问题,不建议采用此方法进行适配。
4.ScreenMatch插件(推荐使用)。ScreenMatch插件实际也是生成一些资源,类似第一种方案(原理不同),但是它是根据swdp来生成的,里面相应的值也是dp,如图:
![](https://img.haomeiwen.com/i8014044/dc022a1557862f9c.png)
我们知道方案一是采用px进行布局的,所以跳过了dp,直接关联上手机的分辨率。而这个方案是采用了根据不用的swdp采用不同的资源,这样实际就跳过了手机的实际分辨率,因为我们上面说到了dpi是手机厂商设置在手机
里的,和手机的物理尺寸并没有关系,dp数据是通过dpi换算成px的。而且是根据宽采用不同的dp,从而是等比缩放的,不会出现拉伸的情况。维护起来也很方便
缺点:无法解决上诉金币布局问题,需要拉伸的情况。
四、ScreenMatch插件的使用方法
Setting->Plugins 中下载ScreenMatch插件,完成后,在项目里右键点击ScreenMatch,这时候会生成一个配置文件和一个demo dimens。将这个demo里的值,放入dimens.xml中(名字不能变)。在screenMatch.properties配置文件中
写入参考标准,一般是360不需要去更改,然后插件已经默认有生成的值,如果缺少你需要的可以match_dp=填写,如果有想不要的也可以通过ignore_dp=忽略。具体如图:
![](https://img.haomeiwen.com/i8014044/8183d77e890d8aca.png)
![](https://img.haomeiwen.com/i8014044/028059f876f9ae13.png)
![](https://img.haomeiwen.com/i8014044/fc2f803e409da911.png)
配置完之后,重新右键项目点击ScreenMatch,就可以重新生成了。然后引用里面相关资源进行布局就可以。
网友评论