屏幕适配

为什么Android需要进行屏幕适配

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

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

在2012年，OpenSignalMaps（以下简称OSM）发布了第一份Android碎片化报告，统计数据表明，

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

Paste_Image.png

而随着支持Android系统的设备(手机、平板、电视、手表)的增多，设备碎片化、品牌碎片化、系统碎片化、传感器碎片化和屏幕碎片化的程度也在不断地加深。而我们今天要探讨的，则是对我们开发影响比较大的——屏幕的碎片化。

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

Paste_Image.png

下图是2014年初，友盟统计的占比5%以上的6个主流分辨率，可以看出，占比最高的是480800，320480的设备竟然也占据了很大比例，但是和半年前的数据相比较，中低分辨率(320480、480800)的比例在减少，而中高分辨率的比例则在不断地增加。虽然每个分辨率所占的比例在变化，但是总的趋势没变，还是这六种，只是分辨率在不断地提高。

Paste_Image.png

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

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

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

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

Paste_Image.png

屏幕尺寸： 也就是我们平时所说的某某手机是几寸屏， 比如HTC one V这款手机是3.7寸的， 这里的寸说的是英寸（inch），国际上习惯使用的单位，3.7寸指的是屏幕的对角线的长度。

屏幕尺寸指屏幕的对角线的长度，单位是英寸，1英寸=2.54厘米
比如常见的屏幕尺寸有2.4、2.8、3.5、3.7、4.2、5.0、5.5、6.0等 ```


**屏幕分辨率**： 指屏幕的宽和高的像素数， 比如HTC one V是480*800的。

屏幕分辨率是指在横纵向上的像素点数，单位是px，1px=1个像素点。一般以纵向像素横向像素，如19601080。```
屏幕密度： 每inch的像素数，比如HTC one V， 是252 px/inch。

屏幕像素密度是指每英寸上的像素点数，单位是dpi，即“dot per inch”的缩写。屏幕像素密度与屏幕尺寸和屏幕分辨率有关，在单一变化条件下，屏幕尺寸越小、分辨率越高，像素密度越大，反之越小。

dp、dip、dpi、sp、px

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

dip和dp是一个意思，都是Density Independent Pixels的缩写，即密度无关像素，上面我们说过，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-independent pixels，与dp类似，但是可以根据文字大小首选项进行放缩，是设置字体大小的御用单位。

mdpi、hdpi、xdpi、xxdpi

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

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

那么如何区分呢？Google官方指定按照下列标准进行区分：


![Paste_Image.png](http://upload-images.jianshu.io/upload_images/5423625-a23e67ba072a3f87.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

在进行开发的时候，我们需要把合适大小的图片放在合适的文件夹里面。下面以图标设计为例进行介绍。


![Paste_Image.png](http://upload-images.jianshu.io/upload_images/5423625-73598b8547041eed.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

在设计图标时，对于五种主流的像素密度（MDPI、HDPI、XHDPI、XXHDPI 和 XXXHDPI）应按照 2:3:4:6:8 的比例进行缩放。例如，一个启动图标的尺寸为48x48 dp，这表示在 MDPI 的屏幕上其实际尺寸应为 48x48 px，在 HDPI 的屏幕上其实际大小是 MDPI 的 1.5 倍 (72x72 px)，在 XDPI 的屏幕上其实际大小是 MDPI 的 2 倍 (96x96 px)，依此类推。

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

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


![Paste_Image.png](http://upload-images.jianshu.io/upload_images/5423625-20b3cf293ee04c72.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

解决方案

支持各种屏幕尺寸

使用wrap_content、match_parent、weight

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

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

如果使用 “wrap_content” 和 “match_parent” 尺寸值而不是硬编码的尺寸，视图就会相应地仅使用自身所需的空间或展开以填满可用空间。此方法可让布局正确适应各种屏幕尺寸和屏幕方向。

weight的计算方法

android:layout_weight的真实含义是:如果View设置了该属性并且有效，那么该 View的宽度等于原有宽度(android:layout_width)加上剩余空间的占比。

使用相对布局，禁用绝对布局

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

由于各种布局的特点不一样，所以不能说哪个布局好用，到底应该使用什么布局只能根据实际需求来确定。我们可以使用 LinearLayout 的嵌套实例并结合 “wrap_content” 和 “match_parent”，以便构建相当复杂的布局。不过，我们无法通过 LinearLayout 精确控制子视图的特殊关系；系统会将 LinearLayout 中的视图直接并排列出。

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

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


![Paste_Image.png](http://upload-images.jianshu.io/upload_images/5423625-e9e64a454fa56ebc.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

在上面的代码中我们使用了相对布局，并且使用alignXXX等属性指定了子控件的位置，下面是这种布局方式在应对屏幕变化时的表现

在小尺寸屏幕的显示


![Paste_Image.png](http://upload-images.jianshu.io/upload_images/5423625-cff959889dbae1f4.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

在平板的大尺寸上的显示效果


![Paste_Image.png](http://upload-images.jianshu.io/upload_images/5423625-d49be856e2613170.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

虽然控件的大小由于屏幕尺寸的增加而发生了改变，但是我们可以看到，由于使用了相对布局，所以控件之前的位置关系并没有发生什么变化，这说明我们的适配成功了。