android屏幕适配读完这篇就够了.docx

android屏幕适配读完这篇就够了.docx

《android屏幕适配读完这篇就够了.docx》由会员分享，可在线阅读，更多相关《android屏幕适配读完这篇就够了.docx（9页珍藏版）》请在冰豆网上搜索。

android屏幕适配读完这篇就够了

Android屏幕适配—读完这篇就够了

由于Android系统的开放性，任何用户、开发者、OEM厂商、运营商都可以对Android进行定制，修改成他们想要的样子。

Android屏幕适配出现的原因在我们学习如何进行屏幕适配之前，我们需要先了解下为什么Android需要进行屏幕适配。

由于Android系统的开放性，任何用户、开发者、OEM厂商、运营商都可以对Android进行定制，修改成他们想要的样子。

但是这种“碎片化”到底到达什么程度呢？

在2012年，OpenSignalMaps（以下简称OSM）发布了第一份Android碎片化报告，统计数据表明，2012年，支持Android的设备共有3997种。

2013年，支持Android的设备共有11868种。

2014年，支持Android的设备共有18796种。

下面这张图片所显示的内容足以充分说明当今Android系统碎片化问题的严重性，因为该图片中的每一个矩形都代表着一种Android设备。

而随着支持Android系统的设备（手机、平板、电视、手表）的增多，设备碎片化、品牌碎片化、系统碎片化、传感器碎片化和屏幕碎片化的程度也在不断地加深。

而我们今天要探讨的，则是对我们开发影响比较大的——屏幕的碎片化。

下面这张图是Android屏幕尺寸的示意图，在这张图里面，蓝色矩形的大小代表不同尺寸，颜色深浅则代表所占百分比的大小。

而与之相对应的，则是下面这张图。

这张图显示了IOS设备所需要进行适配的屏幕尺寸和占比。

当然，这张图片只是4,4s,5,5c,5s和平板的尺寸，现在还应该加上新推出的iphone6和plus，但是和Android的屏幕碎片化程度相比而言，还是差的太远。

详细的统计数据请到这里查看。

现在你应该很清楚为什么要对Android的屏幕进行适配了吧？

屏幕尺寸这么多，为了让我们开发的程序能够比较美观的显示在不同尺寸、分辨率、像素密度（这些概念我会在下面详细讲解）的设备上，那就要在开发的过程中进行处理，至于如何去进行处理，这就是我们今天的主题了。

但是在开始进入主题之前，我们再来探讨一件事情，那就是Android设备的屏幕尺寸，从几寸的智能手机，到10寸的平板电脑，再到几十寸的数字电视，我们应该适配哪些设备呢？

其实这个问题不应该这么考虑，因为对于具有相同像素密度的设备来说，像素越高，尺寸就越大，所以我们可以换个思路，将问题从单纯的尺寸大小转换到像素大小和像素密度的角度来。

下图是2014年初，友盟统计的占比5%以上的6个主流分辨率，可以看出，占比最高的是480*800，320*480的设备竟然也占据了很大比例，但是和半年前的数据相比较，中低分辨率（320*480、480*800）的比例在减少，而中高分辨率的比例则在不断地增加。

虽然每个分辨率所占的比例在变化，但是总的趋势没变，还是这六种，只是分辨率在不断地提高。

所以说，我们只要尽量适配这几种分辨率，就可以在大部分的手机上正常运行了。

当然了，这只是手机的适配，对于平板设备（电视也可以看做是平板），我们还需要一些其他的处理。

好了，到目前为止，我们已经弄清楚了Android开发为什么要进行适配，以及我们应该适配哪些对象，接下来，终于进入我们的正题了！

首先，我们先要学习几个重要的概念。

重要概念什么是屏幕尺寸、屏幕分辨率、屏幕像素密度？

什么是dp、dip、dpi、sp、px？

他们之间的关系是什么？

什么是mdpi、hdpi、xdpi、xxdpi？

如何计算和区分？

在下面的内容中我们将介绍这些概念。

屏幕尺寸屏幕尺寸指屏幕的对角线的长度，单位是英寸，1英寸=2.54厘米比如常见的屏幕尺寸有2.4、2.8、3.5、3.7、4.2、5.0、5.5、6.0等屏幕分辨率屏幕分辨率是指在横纵向上的像素点数，单位是px，1px=1个像素点。

一般以纵向像素*横向像素，如1960*1080。

屏幕像素密度屏幕像素密度是指每英寸上的像素点数，单位是dpi，即“dotperinch”的缩写。

屏幕像素密度与屏幕尺寸和屏幕分辨率有关，在单一变化条件下，屏幕尺寸越小、分辨率越高，像素密度越大，反之越小。

dp、dip、dpi、sp、pxpx我们应该是比较熟悉的，前面的分辨率就是用的像素为单位，大多数情况下，比如UI设计、Android原生API都会以px作为统一的计量单位，像是获取屏幕宽高等。

dip和dp是一个意思，都是DensityIndependentPixels的缩写，即密度无关像素，上面我们说过，dpi是屏幕像素密度，假如一英寸里面有160个像素，这个屏幕的像素密度就是160dpi，那么在这种情况下，dp和px如何换算呢？

在Android中，规定以160dpi为基准，1dip=1px，如果密度是320dpi，则1dip=2px，以此类推。

假如同样都是画一条320px的线，在480*800分辨率手机上显示为2/3屏幕宽度，在320*480的手机上则占满了全屏，如果使用dp为单位，在这两种分辨率下，160dp都显示为屏幕一半的长度。

这也是为什么在Android开发中，写布局的时候要尽量使用dp而不是px的原因。

而sp，即scale-independentpixels，与dp类似，但是可以根据文字大小首选项进行放缩，是设置字体大小的御用单位。

mdpi、hdpi、xdpi、xxdpi其实之前还有个ldpi，但是随着移动设备配置的不断升级，这个像素密度的设备已经很罕见了，所在现在适配时不需考虑。

mdpi、hdpi、xdpi、xxdpi用来修饰Android中的drawable文件夹及values文件夹，用来区分不同像素密度下的图片和dimen值。

那么如何区分呢？

Google官方指定按照下列标准进行区分：

在进行开发的时候，我们需要把合适大小的图片放在合适的文件夹里面。

下面以图标设计为例进行介绍。

在设计图标时，对于五种主流的像素密度（MDPI、HDPI、XHDPI、XXHDPI和XXXHDPI）应按照2:

3:

4:

6:

8的比例进行缩放。

例如，一个启动图标的尺寸为48x48dp，这表示在MDPI的屏幕上其实际尺寸应为48x48px，在HDPI的屏幕上其实际大小是MDPI的1.5倍（72x72px），在XDPI的屏幕上其实际大小是MDPI的2倍（96x96px），依此类推。

虽然Android也支持低像素密度（LDPI）的屏幕，但无需为此费神，系统会自动将HDPI尺寸的图标缩小到1/2进行匹配。

下图为图标的各个屏幕密度的对应尺寸：

解决方案支持各种屏幕尺寸使用wrap_content、match_parent、weight要确保布局的灵活性并适应各种尺寸的屏幕，应使用“wrap_content”和“match_parent”控制某些视图组件的宽度和高度。

使用“wrap_content”，系统就会将视图的宽度或高度设置成所需的最小尺寸以适应视图中的内容，而“match_parent”（在低于API级别8的级别中称为“fill_parent”）则会展开组件以匹配其父视图的尺寸。

如果使用“wrap_content”和“match_parent”尺寸值而不是硬编码的尺寸，视图就会相应地仅使用自身所需的空间或展开以填满可用空间。

此方法可让布局正确适应各种屏幕尺寸和屏幕方向。

下面是一段示例代码下图是在横纵屏切换的时候的显示效果，我们可以看到这样可以很好的适配屏幕尺寸的变化。

weight是线性布局的一个独特的属性，我们可以使用这个属性来按照比例对界面进行分配，完成一些特殊的需求。

但是，我们对于这个属性的计算应该如何理解呢？

首先看下面的例子，我们在布局中这样设置我们的界面我们在布局里面设置为线性布局，横向排列，然后放置两个宽度为0dp的按钮，分别设置weight为1和2，在效果图中，我们可以看到两个按钮按照1：

2的宽度比例正常排列了，这也是我们经常使用到的场景，这是时候很好理解，Button1的宽度就是1/（1+2）=1/3，Button2的宽度则是2/（1+2）=2/3，我们可以很清楚的明白这种情景下的占比如何计算。

但是假如我们的宽度不是0dp（wrap_content和0dp的效果相同），则是match_parent呢？

下面是设置为match_parent的效果我们可以看到，在这种情况下，占比和上面正好相反，这是怎么回事呢？

说到这里，我们就不得不提一下weight的计算方法了。

android:

layout_weight的真实含义是:

如果View设置了该属性并且有效，那么该View的宽度等于原有宽度（android:

layout_width）加上剩余空间的占比。

从这个角度我们来解释一下上面的现象。

在上面的代码中，我们设置每个Button的宽度都是match_parent，假设屏幕宽度为L，那么每个Button的宽度也应该都为L，剩余宽度就等于L-（L+L）=-L。

Button1的weight=1，剩余宽度占比为1/（1+2）=1/3，所以最终宽度为L+1/3*（-L）=2/3L，Button2的计算类似，最终宽度为L+2/3（-L）=1/3L。

这是在水平方向上的，那么在垂直方向上也是这样吗？

下面是测试代码和效果如果是垂直方向，那么我们应该改变的是layout_height的属性，下面是0dp的显示效果下面是match_parent的显示效果，结论和水平是完全一样的虽然说我们演示了match_parent的显示效果，并说明了原因，但是在真正用的时候，我们都是设置某一个属性为0dp，然后按照权重计算所占百分比。

使用相对布局，禁用绝对布局在开发中，我们大部分时候使用的都是线性布局、相对布局和帧布局，绝对布局由于适配性极差，所以极少使用。

由于各种布局的特点不一样，所以不能说哪个布局好用，到底应该使用什么布局只能根据实际需求来确定。

我们可以使用LinearLayout的嵌套实例并结合“wrap_content”和“match_parent”，以便构建相当复杂的布局。

不过，我们无法通过LinearLayout精确控制子视图的特殊关系；系统会将LinearLayout中的视图直接并排列出。

如果我们需要将子视图排列出各种效果而不是一条直线，通常更合适的解决方法是使用RelativeLayout，这样就可以根据各组件之间的特殊关系指定布局了。

例如，我们可以将某个子视图对齐到屏幕左侧，同时将另一个视图对齐到屏幕右侧。

下面的代码以官方Demo为例说明。

在上面的代码中我们使用了相对布局，并且使用alignXXX等属性指定了子控件的位置，下面是这种布局方式在应对屏幕变化时的表现在小尺寸屏幕的显示在平板的大尺寸上的显示效果虽然控件的大小由于屏幕尺寸的增加而发生了改变，但是我们可以看到，由于使用了相对布局，所以控件之前的位置关系并没有发生什么变化，这说明我们的适配成功了。

使用限定符使用尺寸限定符上面所提到的灵活布局或者是相对布局，可以为我们带来的优势就只有这么多了。

虽然这些布局可以拉伸组件内外的空间以适应各种屏幕，但它们不一定能为每种屏幕都提供最佳的用户体验。

因此，我们的应用不仅仅只实施灵活布局，还应该应针对各种屏幕配置提供一些备用布局。

如何做到这一点呢？

我们可以通过使用配置限定符，在运行时根据当前的设备配置自动选择合适的资源了，例如根据各种屏幕尺寸选择不同的布局。

很多应用会在较大的屏幕上实施“双面板”模式，即在一个面板上显示项目列表，而在另一面板上显示对应内容。

平板电脑和电视的屏幕已经大到可以同时容纳这两个面板了，但手机屏幕就需要分别显示。

因此，我们可以使用以下文件以便实施这些布局：

res/layout/main.xml，单面板（默认）布局：

res/layout-large/main.xml，双面板布局：

请注意第二种布局名称目录中的large限定符。

系统会在属于较大屏幕（例如7英寸或更大的平板电脑）的设备上选择此布局