android分辨率适配

㈠ android 屏幕适配基础知识

最近参考 今日头条算法 ，优化了项目的屏幕适配策略。下面是适配过程中的一些心得，部分内容来源于网络。

举个例子：屏幕分辨率为：1920*1080，屏幕尺寸为5吋的话，那么dpi为440。

dp就是密度自适应的像素。1dp表示 在dpi为160的设备上的一颗像素
px与dp的换算公式px = dp * (dpi / 160)，很显然，由于相同分辨率但不同屏幕大小的设备dpi是不同的，导致px和dp的基本不存在一个固定的换算关系，为了方便屏幕适配，Android设置了6个通用的密度，换算px与dp时采取通用密度计算，而非设备实际的密度。

以下为6种通用密度，以及其最小的分辨率

得到上面通用密度之后，我们换算dp与px多了一种简便方式。Android系统用mdpi(160dpi)作为基准，此时1px = 1dp，又有px = dp * (dpi / 160)，所以我们可以很容易的得到以下换算：

sp在dp的基础上引入了scaleFactor变量，一般用于字号，可在系统设置里调大。

同一张图片放到以上4个分辨率类型的文件夹里，在页面上呈现的效果如下

实际呈现的算法为： 图片尺寸 * 系统density / 文件夹 density
因为图片尺寸、系统density都是固定的，因此图片最终尺寸表现为： 图片放的位置越"low"，呈现的尺寸越大

比如 图片宽度200px，系统 density =3，则图片宽度

下面是详细的解释

我们知道，不管在布局文件中填写的是什么单位，它最后都会被系统转化为 px。系统的转换算法如下：

可以看到 px = dp*density 。

横向适配的最终目的：让100dp的宽度，在各个机型上，在屏幕上所占的 比例相同 。
其核心算法是px = dp* density。通过修改density这个变量，我们可以让px和画布标注的px值一致，达到适配的效果。

美工同学提供的画布宽度为 750px（iphone6） ，开发中，我们对这些px标注 除2 得到dp值进行使用。
那么density如何求出呢？ 根据系统算法px = dp*density，反推 density =px/dp
拿横向适配画布， density对于不同分辨率的手机修改后如下：

375是我们拿UI画布横向分辨率750/2得出。

㈡ Android 屏幕分辨率适配

Android屏幕分辨率千奇百怪，怎么让app在不同的分辨率的设备上“看起来一样”呢？
你也许还有以下疑惑：

这篇文章将会针对以上问题一一解答。

Pixels 我们看到屏幕上的图像由一个个像素组成，像素里包含色彩信息。
如常说的手机分辨率：1080 x 1920 指的是手机宽度可展示1080像素，高度可展示1920像素。

Pixels Per Inch 每英寸长度所具有的像素个数，单位面积内像素越多，图像显示越清晰。
ppi一般用在显示器、手机、平板等描述屏幕精细度。

Dots Per Inch 每英寸长度所具有的点数。
dpi一般用来描述打印（书本、杂志、电报）的精细度

density-independent pixels (device-independent pixels 我查了一下，官网更多时候使用前者，有的时候也显示后者），dip是缩写，也可以更简单些称作dp。该单位的目的是屏蔽不同设备密度差异，后面细说。

Scalable pixels 用于设置字体，在用户更改字体大小时候会适配。

澄清了基本概念，我们现在从一个例子开始说明以上单位之间的区别与联系。

布局文件里有个View，长宽都是200px，分别在分辨率为480(宽)x800(高）简称A设备、1080(宽)x1920(高）简称B设备，效果如下:

左边是A设备，右边是B设备。问题出来了，同样长宽都是200px，为啥A设备显示很大，B设备显示很小呢？你可能会说B设备的横向分辨率1080比A设备的480大，所以在B设备上看起来比较小。来看看A、B设备横向到底是多少英寸，怎么来计算呢？这时候就需要用到ppi了，既然知道横向的像素点个数，也知道每英寸能容纳的像素点，当然可以得知横向的尺寸了。

其中一种方式获取DisplayMetrics对象：

A设备宽度尺寸：480(px)/240(ppi)=2inch
B设备宽度尺寸：1080(px)/420(ppi)=2.5inch
可以看出，A、B设备尺寸差别不大。A设备ppi=240 B设备ppi=420，明显地看出B设备单位长度上比A设备能够容纳更多的像素，因此同样的200px，B设备只需要较小的尺寸就能够显示，因此在B设备上的view看起来比A设备小很多。
知道了问题的原因，然而显示的效果却不能接受。

我们总不能自己判断每个设备的ppi，然后计算实际需要多少像素，再动态设置view的大小吧，那layout里的静态布局大小就无法动态更改适应了。想当然的能有一个统一的地方替我们转换，没错！Android系统已经帮我们实现了转换。接下来就是dpi、dp出场了。

Android系统使用dpi来描述屏幕的密度，使用dp来描述密度与像素的关系。
A设备dpi=240
B设备dpi=420
Android系统最终识别的单位是px，怎么将dpi和px关联起来呢？，答案是dp。
Android规定当dpi=160时，1dp=1px，当dpi=240时，1dp=1.5px，依此类推，并且给各个范围的dpi取了简易的名字加以直观的识别，如120<dpi<=160，称作为mdpi，120<dpi<=240 称作hdpi，最终形成如下规则：

现在知道了dp能够在不同dpi设备上对应不同px，相当于中间转换层，我们只需要将view长宽单位设置为合适的dp，就无需关注设备之间密度差异，系统会帮我们完成dp-px转换。将我们之前的例子稍微更改，再看看效果验证一下：

通过上面对dp的了解，我们知道在设定view大小、间距时使用dp能最大限度地屏蔽设备密度之间的差异。可能你就会问了，那bitmap展示的时候如何适配不同密度的设备呢？

自定义view从磁盘上加载一张图片，并将之显示在view上，view的大小决定于bitmap大小。依旧以上述A、B设备为例，展示结果如下：

左边是A设备，右边是B设备。
明显地看出，在A设备显示比B设备大很多，实际上和我们之前用px来描述view的大小原理是一样的，bitmap的宽、高都是px在描述，而bitmap决定了view的宽、高，最终导致A设备和B设备上的view大小（宽、高像素）是一样的，而它们屏幕密度又不相同，因此产生了差异。
那不会每次都需要我们自己根据屏幕密度来转换bitmap大小吧？幸运的是，Android已经为我们考虑到了。

生成不同密度的目录有什么作用？
A设备dpi=240，根据dpi范围，属于hdpi
B设备dpi=420，根据dpi范围，属于xxhdpi
图片原始尺寸：photo1.jpg(宽高 172px-172px)
当我们想要在不同密度设备上显示同一张图片并且想要“看起来一样大时”。假设设计的时候以hdpi为准，放置photo1.jpg为172*172，那么根据计算规则在xxhdpi上需要设置photo1.jpg为:

现在hdpi和xxhdpi目录下分别存放了同名图片：photo1.jpg，只是大小不同。当程序运行的时候：

来看看效果：

左边A设备，右边B设备
针对不同的密度设计不同的图片大小，最大限度保证了同一图片在不同密度设备上表现“看起来差不多大”。
来看看A、B设备上图片占内存大小：

说明在B设备上显示photo1.jpg需要更多的内存。
上边只是列举了hdpi、xxhdipi，同理对于mdpi、xhdpi、xxxhdpi根据规则放入相应大小的图片，程序会根据不同的设备密度从对应的mipmap文件夹下加载资源。如此一来，我们无需关注bitmap在不同密度设备上显示问题了。

在mipmap各个文件夹下都放置同一套资源的不同尺寸文件似乎有点太占apk大小，能否只放某个密度下图片，其余的靠系统自己适配呢？
现在只保留hdpi下的photo1.jpg图片，看看在A、B设备上运行情况如何：

看起来和上张图差不多，说明系统会帮我们适配B设备上的图片。
再来看看A、B设备上图片占内存大小：
先看A设备：

对比photo1.jpg 分别放在hdpi、xxhdpi和只放在hdpi下可以看出：B设备上图片所占内存变小了。为什么呢？接下来从源码里寻找答案。

A、B设备同样加载hdpi/photo1.jpg，返回的bitmap大小不相同，我们从这方法开始一探究竟。

上面涉及到的关键点是density，分别是TypedValue的density和Options的density。
先来看看TypedValue density:

再来看看Options density

现在分析B设备加载hdpi/photo1.jpg如何做的:

和我们之前调试的结果一致。

B设备是怎么决定使用hdpi下的图片资源呢？
根据实验（尝试找了源码，没怎么看懂，因此只是做了实验，可能在不同密度设备上找寻规则不一样）：B设备先找属于自己密度范围文件夹下的图片，B设备属于xxhdpi，先查看xxhdpi有没有photo1.jpg，如果没有则往更高的密度找，比它高的密度是xxxhdpi，还是没有，则往低密度找，找xhdpi，没有再找hdpi，找到了则返回构造好的TypedValue，剩下的就是我们前面分析的。
既然我们只想放某个密度下的一份切图，该放哪个密度下呢？从系统寻找规则看，更推荐放置在更高密度下的，因为如果放在低密度下，那么当运行在高密度设备上时，图片会进行放大，可能导致不清晰。我一般习惯放在xxhdpi下。

Android Studio默认创建了不同密度的mipmap文件夹，默认放置了ic_launcher.png。我们普通的切图该放drawable还是mipmap下呢？对于这个问题网上也是众说纷纭，实际上对于我们来说，关注的重点是图片放在drawable或者mipmap，加载出来bitmap是否有差异，如果没有差异放在哪就看习惯了。通过实践，普通的切图放drawable和mipmap下加载出来的bitmap是没有差异的，只不过用drawable的话需要自己创建不同密度的文件夹。我习惯于放在drawable下(启动图标logo还是放在mipmap下）。

前边 [注1] 留了个问题，我们使用dp来表示view的大小了，为啥两个看起来还是有些差距？下面我们更加直观地看一个例子。
A设备dpi=240 密度1.5 分辨率(宽高px)：480 * 800
B设备dpi=420 密度2.625 分辨率(宽高px)：1080 * 1794
换算成dp
A设备分辨率：320dp * 533dp
B设备分辨率：411dp * 683dp
依旧是上边的例子：

将view宽高分别设置为320dp，看看效果：

左边A设备，右边B设备
可以看出同样的320dp大小，A设备铺满了屏幕，而B设备没有。这效果显然是不能接受的，Android考虑到不同设备宽高不同，推出了"宽高限定符"。以A、B设备为例：
在res文件夹下创建文件夹：

假设设计师出图是按照800x480，那么我们创建dimen文件的时候

该文件放在values-800x480文件夹下。
根据分辨率比例算出1794x1080的dimen值

这样子，A、B设备加载资源的时候使用对应分辨率限定符下的px，如果找不到再找默认值，可以在一定程度上解决屏幕宽高碎片化适配问题。
但是这样子的限定比较严格，需要测试各种分辨率，后来Android又推出了"smallest-width"简称最小宽度限制。
A设备宽320dp
B设备宽411dp
假设设计师切图标准屏幕宽是320dp(A设备），那么可以定义如下dimen.xml文件

该文件放在values-sw320dp文件夹下
根据规则，计算B设备dimen.xml

现在我们继续来看之前的view

通过对dimen引用，A设备寻找和自己宽度一样的dimen文件，找到values-sw320dp，dp320=320dp。B设备寻找和自己宽度一样的dimen文件，找到values-sw411dp，dp320=410dp。这样子同样的dp320，得出不同的值，就适配了屏幕宽度不同的问题。
看看效果：

这次B设备也铺满了屏宽。

综上，为了适配不同屏幕大小，推荐使用dp+smallest-width。

获取设备dpi最终都是从这方法获取的，实际上就是读取系统的配置文件。因此我们也可以通过adb shell 获取：

可以看出dpi是系统配置好的，当然有些手机是可以设置分辨率的，设置之后我们查看分辨率：

分辨率变低了，dpi也变小了。

㈢ Android-屏幕适配全攻略（绝对详细）（一）

关键字： 屏幕适配 px dp dpi sp large限定符 .9.png

前言： 这篇文章依然是我在 [慕课网 ][h]学习 凯子哥 的同名视频 Android-屏幕适配全攻略 ，所记录下来的笔记---凯子哥讲得真的超详细。
[h]: http://www.imooc.com/ "MOOC"

从上图可以看出，主流的分辨率是前六种：1280×720、1920×1080、800×480、854×480、960×540、1184×720，不过我们有解决方案。看完这篇文章，想必你就可以解决常见的屏幕适配问题。

接下来正式进入正题。

介绍几个在Android屏幕适配上非常重要的名词：

屏幕尺寸 是指屏幕对角线的长度。单位是英寸，1英寸=2.54厘米
屏幕分辨率 是指在横纵向上的像素点数，单位是px，1px=1像素点，一般是纵向像素横向像素，如1280×720
屏幕像素密度 是指每英寸上的像素点数，单位是dpi，即“dot per inch”的缩写，像素密度和屏幕尺寸和屏幕分辨率有关

dip： Density Independent Pixels（密度无关像素）的缩写。以 160dpi 为基准，1dp=1px
dp： 同 dip
dpi： 屏幕像素密度的单位，“dot per inch”的缩写

px： 像素，物理上的绝对单位

sp： Scale-Independent Pixels的缩写，可以根据文字大小首选项自动进行缩放。Google推荐我们使用12sp以上的大小，通常可以使用12sp，14sp，18sp，22sp，最好不要使用奇数和小数。

用于区分不同的像素密度。

在Google官方开发文档中，说明了 ** mdpi：hdpi：xhdpi：xxhdpi：xxxhdpi=2：3：4：6：8 ** 的尺寸比例进行缩放。例如，一个图标的大小为48×48dp，表示在mdpi上，实际大小为48×48px，在hdpi像素密度上，实际尺寸为mdpi上的1.5倍，即72×72px，以此类推。

我们可以通过以下几种方式来支持各种屏幕尺寸：

wrap_content： 根据控件的内容设置控件的尺寸
math_parent： 根据父控件的尺寸大小设置控件的尺寸
weight： 权重，在线性布局中可以使用weight属性设置控件所占的比例

例如，我们要实现下图所显示的效果：当屏幕尺寸改变时，new reader控件两边的控件大小不变，new reader控件会占完剩余的空间。

具体布局文件如下：

小插曲： 关于 android:layout_weight 属性

一般情况，我们都是设置要进行比例分配的方向的宽度为0dp，然后再用权重进行分配。如下：

效果为：

效果为：

button1宽度=L+（L-2L）×1/3=2/3L
button2宽度=L+（L-2L）×2/3=1/3L

当然，还有其他的方式，都可以运用此公式进行计算。
在实际开发中，我们一般使用0dp的方式，而不使用其他方式。

简单的布局一般都使用 线性布局 ，而略微复杂点的布局，我们使用 相对布局 ，大多数时候，我们都是使用这两种布局的嵌套。

我们使用 相对布局 的原因是， 相对布局 能在各种尺寸的屏幕上保持控件间的相对位置。

res/layout/main.xml 单面板：

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

如果这个程序运行在屏幕尺寸大于7inch的设备上，系统就会加载 res/layout-large/main.xml 而不是 res/layout/main.xml ，在小于7inch的设备上就会加载 res/layout/main.xml 。

需要注意的是，这种通过 large 限定符分辨屏幕尺寸的方法，适用于android3.2之前。在android3.2之后，为了更精确地分辨屏幕尺寸大小，Google推出了最小宽度限定符。

res/layout-sw600dp/main.xml ，双面板布局： Small Width 最小宽度

这种方式是不区分屏幕方向的。这种最小宽度限定符适用于android3.2之后，所以如果要适配android全部的版本，就要使用 large 限定符和 sw600dp 文件同时存在于项目 res 目录下。

这就要求我们维护两个相同功能的文件。为了避免繁琐操作，我们就要使用布局别名。

由于后两个文具文件一样，我们可以用以下两个文件代替上面三个布局文件：

res/layout/main.xml 单面板布局
res/layout/main_twopanes.xml 双面板布局

然后在 res 下建立
res/values/layout.xml 、
res/values-large/layout.xml 、
res/values-sw600dp/layout.xml 三个文件。

默认布局
res/values/layout.xml :

Android3.2之前的平板布局
res/values-large/layout.xml :

Android3.2之后的平板布局
res/values-sw600dp/layout.xml :

这样就有了 main 为别名的布局。
在activity中 setContentView(R.layout.main);

这样，程序在运行时，就会检测手机的屏幕大小，如果是平板设备就会加载 res/layout/main_twopanes.xml ，如果是手机设备，就会加载 res/layout/main.xml 。我们就解决了只使用一个布局文件来适配android3.2前后的所有平板设备。

如果我们要求给横屏、竖屏显示的布局不一样。就可以使用 屏幕方向限定符 来实现。
例如，要在平板上实现横竖屏显示不用的布局，可以用以下方式实现。
res/values-sw600dp-land/layouts.xml :横屏

res/values-sw600dp-port/layouts.xml :竖屏

自动拉伸位图，即android下特有的 .9.png 图片格式。

当我们需要使图片在拉伸后还能保持一定的显示效果，比如，不能使图片中的重要像素拉伸，不能使内容区域受到拉伸的影响，我们就可以使用 .9.png 图来实现。

要使用 .9.png ，必须先得创建 .9.png 图片，androidSDK给我们提供了的工具就包含 .9.png 文件的创建和修改工具。双击 SDK安装目录 oolsdraw9patch.bat ，就会打开下图所示的窗口。

下面是一个例子：

Button属性设置：

如果我们选择的内容区域偏差太大，可能就不会显示出text值 BUTTON 。

好了，这篇文章写的有点多了，剩下的内容放在 下篇文章 记录吧。
内容提要：
解决方案-支持各种屏幕密度
解决方案-实施自适应用户界面流程

未完待续

㈣ Android 屏幕适配

1： dp: android 尺寸的基本单位。 在不同的分辨率的手机里面，1dp对应着不同数量的px, 这样就实现了dp定义一个控件大小的时候，在不同分辨率手机里表现出相应大小的像素值。
2： 屏幕分辨率： 1080下160, 表示宽度有1080个像素点而高度有2160个像素点。常见的分辨率有320x480， 480x800, 720x1280, 1080x1920等。
3： 屏幕尺寸： 以寸为单位， Android设备对角线的长度
4： 像素密度: 每英寸的像素点
5： 屏幕尺寸， 分辨率，像素密度 三者之间的关系：
密度（dpi）= √（宽2 + 高2）/屏幕尺寸

6： px：像素，是屏幕上显示数据的最基本的点
7： dpi：屏幕像素密度，每英寸上的像素点数
8： sp：与dp类似，通常用于指定字体的大小，当用户修改手机显示的字体时，字体大小会随之改变。

1： dp适配方案： Android自带的原始的适配方案， 在不同的分辨率手机里面表现出相应大小的像素点。
缺点： Android的碎片化严重， 如果生产厂家没有根据屏幕尺寸、分辨率和像素密度的关系来规则定义， 或者出一些乱七八糟的屏幕大小，这样的适配方案就不在适合了。

2： 宽高限定符：枚举所有的屏幕宽高像素值，根据等比缩放去适配。如果没有找到对应的屏幕， 则取默认的。 目前这种方案已经被弃用。

缺点：
1： 占用资源大，会增加APK的体积。
2： 容错机制大需要精准命中资源文件才能适配，比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。而使用默认的尺寸的话，UI就很可能变形。

3：AndroidAutoLayout适配方案（停止维护）

4: SW限定符适配方案：（smallestWidth最小宽度适配）
Android 会去识别屏幕可用高度或者宽度的最小尺寸的dp值。然后根据识别到的结果去对应的资源文件里面去找寻相应的结果。
如何生成：ScreenMatch插件

此方案跟宽高限定的适配方案相比，有很好的容错机制， 如果没有找到对应的适配宽度， 那么会在vlues文件里面去找跟他最接近的宽度。

5：今日头条适配方案：
1>: px 转 dp 的公式 dp = px / density.不管我们设定的单位是什么， 最终我们都会将这些单位长度转化为px的。density就是他们的转化比， 所以，动态改变这个转化比也是可以达到我们适配屏幕的目的的。
2>: 通过修改density值，强行把所有不同尺寸分辨率的手机的宽度dp值改成一个统一的值（在清单文件中定义），这样就解决了所有的适配问题。
3>: Density = 当前设备屏幕总宽度（单位为像素）/ 设计图总宽度（单位为 dp) ；
4>：引入了AndroidAutoSize屏幕适配框架：
https://github.com/JessYanCoding/AndroidAutoSize

最后， 最重要的................
点赞 点赞 点赞， 不重要的事情也就说3遍......

㈤ Android机型适配总结

分辨率对应DPI

ldpi  QVGA (240×320)

mdpi  HVGA (320×480)

hdpi  WVGA (480×800),FWVGA (480×854)

xhdpi  720P（1280*720）

xxhdpi 1080p（1920*1080 ）

xxxhdpi 4K（3840×2160）

机型适配方面常规处理方法：

1、开发之前UI给出不同尺寸标准的多套素材，一般情况下给出：hdpi、xhdpi、xxxhdpi 三种尺寸类型的素材。

2、特殊类型图片使用Android Studio内置draw9path工具进行制作，例如聊天界面中内容背景图片。

3、布局编写时尽量使用 Linearlayout 与  RelativeLayout，LinearLayout内部可以使用weight（权重）属性将子控件的尺寸按比例进行设置。RelativeLayout 内部可以使用layout_align...(相对于xxx)属性将子控件的尺寸相对于父控件或相对于其他子控件进行设置。

4、设置尺寸的时候长度单位  布局使用 dp  字符使用  sp。 其实字体大小的尺寸使用  dp 也可以，但是sp的情况下 用户使用系统设置字体大小的时候可以改变控件中字体的大小，但是使用dp设置的字体就不会产生变化。

5、针对每一个屏幕的尺寸生成一套px与dp的转换方案，详情见博客： Android机型适配方案 。

6、google推出了一个百分比布局库，可以使用百分比的方式进行布局尺寸的设置，详情见博客： Android百分比布局库（percent-support-lib）解析与扩展

7、利用自定义View的方式去解决，其实原理也是，在绘制View的时候，获取屏幕的尺寸然后按照一定的比例去设置控件的尺寸

还有一些琐碎知识点需要了解并记住：

1. px (pixels)像素 ：

一个像素通常被视为图像的最小的完整采样，这个用的比较多,特别是web开发,页面基本都是使用像素作为单位的.

2.dp：

这个是最常用但也最难理解的尺寸单位。它与“像素密度”密切相关，所以首先我们解释一下什么是像素密度。假设有一部手机，屏幕的物理尺寸为1.5英寸x2英寸，屏幕分辨率为240x320，则我们可以计算出在这部手机的屏幕上，每英寸包含的像素点的数量为240/1.5=160dpi（横向）或320/2=160dpi（纵向），160dpi就是这部手机的像素密度，像素密度的单位dpi是Dots Per Inch的缩写，即每英寸像素数量。横向和纵向的这个值都是相同的，原因是大部分手机屏幕使用正方形的像素点。

不同的手机/平板可能具有不同的像素密度，例如同为4寸手机，有480x320分辨率的也有800x480分辨率的，前者的像素密度就比较低。Android系统定义了四种像素密度：低（120dpi）、中（160dpi）、高（240dpi）和超高（320dpi），它们对应的dp到px的系数分别为0.75、1、1.5和2，这个系数乘以dp长度就是像素数。例如界面上有一个长度为“80dp”的图片，那么它在240dpi的手机上实际显示为80x1.5=120px，在320dpi的手机上实际显示为80x2=160px。如果你拿这两部手机放在一起对比，会发现这个图片的物理尺寸“差不多”。

3.dip：

与dp完全相同，只是名字不同而已。在早期的Android版本里多使用dip，后来为了与sp统一就建议使用dp这个名字了。

4.sp：

与缩放无关的抽象像素（Scale-independent Pixel）。sp和dp很类似但唯一的区别是，Android系统允许用户自定义文字尺寸大小（小、正常、大、超大等等），当文字尺寸是“正常”时1sp=1dp=0.00625英寸，而当文字尺寸是“大”或“超大”时，1sp>1dp=0.00625英寸。类似我们在windows里调整字体尺寸以后的效果——窗口大小不变，只有文字大小改变。

还有一些详细的情况需要了解，都在这个博客里： 点击进入

㈥ Android设备的界面适配设计

Android设备App设计中有一个问题可能会被设计师忽略，在各种分辨率各种尺寸“杂屏”的界面适配。可能产出的界面稿在常用的720*1280的分辨率中是完美，但一到各个不同分辨率不同尺寸的设备后

这里就谈谈适配，了解适配让设计从PS、sketch到移动设备上都能完美呈现。

如此繁杂的安卓设备，采用哪个标准设计呢？

1.选择一种尺寸一种分辨率作为基准。

2.选择2-3款主流的Android设备，制定一套适配规则。（国内主流设备、分辨率可参考友盟指数）

3.部分极端效果特别注释说明。

目前移动端设计师多采用iPhone 5与6的分辨率设计，这两个分辨率也最接近Android xhdpi的720*1280，设计之后再做等比适配（不做设计元素等比适配会导致Android设备上视觉呈现较小）。

我则倾向于选取720*1280的分辨率设计。优点是处于常用分辨率的中间值，对小分辨率大分辨率调整也较容易。另外iOS@1x的320与720刚好是2.25的倍率关系，使用sketch等比输出快捷多了。（如果时间成本允许的话可以将Android的标注单位用dp，具体的设备尺寸、分辨率知识这里不详描述，可见文章最后面的“Android基础知识”）

案例说明：

雅虎新闻为各个dpi做了优化，图片等比缩放，文字区域等比缩放，并且考虑到在低dpi下会被推移至第二屏，就减小图片了高度，保持文字区域最小高度。

老司机都不会忘记的，仅提醒下新手，每个图标记得输出多个比例。并且记得查看各个比例下图标的显示效果。

案例说明：

还是拿一个雅虎新闻的例子，大家感受下。

Android设备的系统各个厂商都做了定制化，默认的字体库可能不同，且字体占空间大小可能不同。不同设备显示文字会出现不同效果。设计时考虑3点：

多采用流式布局，不对单行做字数限制（如“单行显示多少个字”“文本宽度多少”），而是定义文本容器的高宽，超出则用“…”“渐隐”或者“遮挡”等方式省略。

若较长的文本需要完整显示，设计时预留换行空间。

若文本需要在单行完整显示（如提示类文字），尽量控制字数（建议16字内），避免小屏不够放置。

案例说明：

图文混排同一行显示时，图片等比固定在右侧显示，文字部分区域宽度会因设备不同出现较大的差异，预留文字多行高度。如下图不同设备下文字的展示空间有差异，需要考虑小分辨率下预留多行文字空间。如图2第二条新闻标题文字溢出的丑陋展示，建议设定一个文字区域最大高度，超出部分则隐藏。

单行出现多个文字符素时，注意元素在低dpi下的显示层级，提前说明好该情况的覆盖或者隐藏规则。如下图第一个用户名称，在低dpi下，避免各元素交错，而省略了超出的用户名称。

图片常用的方式有固定宽度dp等比缩放高度（用于非通栏图片）；固定高度dp等比缩放宽度（用于横向滚动图片，如全屏相册中的纵向图片）；根据屏幕宽度等比缩放（横向通栏图片）。设计时考虑3点：

注意图片占用的宽高比，避免大屏设备上占据大量空间，导致内容比例不协调同时降低了屏幕利用率。

考虑到设备屏幕密度不同，输出图片时别忘了输出多个分辨率。

考虑图片宽高比过大的缩略图处理（最常见的处理方式：高度远大于宽度时，是给出最大区域，让图片等宽居中填充该区域，只显示该区域；宽度远大于高度时，与展示区域等高居中取部分显示。当然也可能出现特殊显示要求，需要根据具体情况具体处理。）

案例说明：

网易游戏相册的全屏浏览中，大于设备宽高比的宽图按照最大宽度放置，小于设备宽高比的高度按照最大高度放置。

一行多张图片要考虑图片的在不同设备下等比缩放带来显示效果的差异。排列时会有两种情况：

1.要求在一行内显示完，根据图片的显示效果决定放置的数量，超过则不显示（如下图1第二条新闻）

2.流式布局，当图片宽度小于设定值时自动换行（如下图2相册展示，低dpi低分辨率设备一行显示3张，高的显示4-5张，且按比例撑满屏幕宽度）。

宽高比超出设计区域时的处理，如网络贴吧中列表的小图模式，给出了正方形区域，当图片非正方形时，根据宽高中的短边等比撑满正方形区域后，截取了图片居中的部分显示。

在固定区域内多元素混合放置时，文字一般采取流式布局，图片多采用等比缩放，图标元素多采用 弹性布局，即元素内容本身规格不变，考虑水平、垂直方向的间距做相应扩展。设备屏幕越大，在扩展方向上可以显示更多内容，发挥了大屏幕的优势。

弹性布局需要给出哪一个元素dp不变，哪一个元素缩放的策略。

弹性布局下部分距离标注采用百分比标注。

当有两个等比缩放元素时考虑避免重叠的情况。

案例说明：

网易游戏的新闻列表样式，每一条新闻区域，要求图片dp不变，而文字区域进行弹性缩放。

下图网易游戏专区中间的幽灵按钮图标为确保点按效果，按照固定dp显示，中间间隔的宽度按照设备宽度的百分比来确定

网易游戏求交往的界面，中间卡片区域大小根据设备等比缩放，如中间用户头像与“同喜欢2款游戏”的文字，在设计时需要考虑产品的目标设备中最小设备下的布局显示效果，避免出现重叠的情况。而纵向的元素数量也需要如此考虑。

Android界面适配的案例说明就写到这里啦。

设计时多考虑各个元素（图标、文本、图片、区域）在不同设备的情况。当然，做设计时也不是死板的按照建议来实现，特别是固定区域下的元素放置，根据实际情况来处理即可。

Android系统的UI也在不断进化完善，随着设计趋势的改变，Android除了常见的卡片、列表、浮层外，可能会有更多的展示方式，而Android设备也是逐渐淘汰ldpi与mdpi，设备的分辨率逐渐变大。也就要求我们需要不断的去了解尝试新的设计趋势，产出最好的方案。

这不是彩蛋哈，仅仅补充安卓设备的基础知识，老司机完全可以忽略，供新手参考阅读。

为展示设备的多样化，贴出Android屏幕尺寸示意图（蓝色矩形的大小代表不同尺寸，颜色深浅则代表所占百分比的大小。）

屏幕大小以屏幕尺寸来衡量，指屏幕的对角线的长度，单位是英寸，1英寸=2.54厘米

目前的主流尺寸：5.0" ~ 5.5" (有继续往更大尺寸发展的趋势，但趋于稳定)

常见的设备尺寸： 4" ~ 10" 。

手机适配参考尺寸： 4" ~ 6"

手机 + 平板适配参考尺寸： 4" ~ 10”

屏幕分辨率是指在横纵向上的像素点数，单位是px，1px=1个像素点。一般以纵向像素*横向像素，如1960*1080。

屏幕像素密度是指每英寸上的像素点数，单位是dpi，即“dot per inch”的缩写。目前每个屏幕像素可以认为就是一个“点”。

屏幕 dpi 的计算方式:

Android 设备中 dpi 分几个段：

•ldpi：~ 120 dpi (几乎绝迹)

•mdpi：~ 160 dpi (罕见)

•hdpi：~ 240 dpi (逐渐减少中)

•xhdpi：~ 320 dpi

•xxhdpi：~ 480 dpi

•xxxhdpi：~ 640dpi (目前较少)

dp(与 dip 同义) 是在 160dpi 下每个像素对应的物理尺寸，可近似理解为:

•160 dp = 1 inch

•1 dp = 1 / 160 inch = 0.15875 mm

•1 dp = 1 px (160 dpi 屏幕下)

•1 dp = 2 px (320 dpi 屏幕下)

Android的屏幕适配指标都基于物理尺寸（即屏幕的物理大小），而非像素（分辨率）。为什么呢？这里根据dp与px适配出两种效果来说明。

按 dp 适配不同屏幕的效果如下，内容的物理尺寸变化不大:

若直接按照像素适配，出现以下情况，高像素密度的设备内容显得特别小，影响布局与可用性：

屏幕长边和短边的比例。

目前手持设备的 长边 dpi 和 短边 dpi 普遍非常接近，可认为屏幕比例和屏幕水平、垂直像素比例一致

屏幕比例目前趋于 16:9 ~ 16:10 (8:5)

因不少设备使用了虚拟按键，所以通常非全屏的 app 可用面积略低，屏幕比例更接近 16:10

㈦ Android屏幕适配-应用篇

Android屏幕适配-基础篇
Android屏幕适配-应用篇

从两个大方面阐述一下Android的屏幕适配：

  Android推荐使用dp作为尺寸单位来适配UI ，通过dp加上自适应布局和weight比例布局可以基本解决不同手机上适配的问题，这基本是最原始的Android适配方案。
缺点 ：
（1）这种方案只能保证我们写出来的界面适配绝大部分手机，部分手机仍然需要单独适配，但dpi的不同，还是会存在差异。
（2）一般的设计稿都是以px为单位的，所以我们在写layout文件的时候需要将px转为dp，影响开发效率。

 为了高效的实现UI开发，出现了新的适配方案，我把它称作宽高限定符适配。简单说，就是穷举市面上所有的Android手机的宽高像素值，设定一个基准的分辨率，其他分辨率都根据这个基准分辨率来计算，在不同的尺寸文件夹内部，根据该尺寸编写对应的dimens文件:

鸿洋大神的作品 ，使用也超级简单，核心功能就是在绘制的时候在onMeasure里面做变换，重新计算px。
缺点 ：我们自定义的控件可能会被影响或限制，可能有些特定的控件（框架没有做适配的控件），需要单独适配。

  小结：上述几种适配方案都是实际开发中用过的方案，但随着技术不断的更新，出现了更好的适配方案。

   实现原理 ：Android会识别屏幕可用高度和宽度的最小尺寸的dp值（ 其实就是手机的宽度值 ），然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。
   sw限定符适配 和 宽高限定符适配 类似，区别在于，前者有很好的容错机制，如果没有value-sw360dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问题。
   优点: 1.非常稳定，极低概率出现意外
    2.不会有任何性能的损耗
    3.适配范围可自由控制，不会影响其他三方库
   缺点 ：就是多个dimens文件可能导致apk变大，几百k。

   附件： 生成sw文件的工具

   实现原理 ： 修改系统的density值 （核心）
  今日头条适配是以设计图的宽或高进行适配的，适配最终是改变系统density实现的。
   过程：

  AndroidAutoSize 是基于今日头条适配方案，该开源库已经很大程度上解决了今日头条适配方案的两个缺点，可以对activity，fragment进行取消适配。也是目前我的项目中所使用的适配方案。
使用也非常简单只需两步：
（1）引入：

（2）在 AndroidManifest 中填写全局设计图尺寸 (单位 dp)，如果使用副单位，则可以直接填写像素尺寸，不需要再将像素转化为 dp，详情请查看 demo-subunits