本文深入探讨了Android系统如何根据设备配置选择最佳匹配资源，包括图片、布局和values资源的匹配规则。通过‘先高再低’的原则和单向检索机制，确保在不同屏幕密度和分辨率下的适配。同时讨论了dp和sp单位在屏幕适配中的作用，指出dp能保持元素尺寸相对一致，但无法解决设备尺寸差异问题。sp单位保证了文本大小的独立性。最后提出了百分比支持库配合sp的屏幕适配方案。
屏幕适配（一） 点击打开链接
=================================
----android如何查找最佳匹配资源？
Android会根据当前的设备配置选择要在运行时使用的备用资源。
-------Android是怎么匹配图片资源的？
----------以 mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi作为扩展名
当应用在设备对应dpi目录下没有找到某个资源时，遵循“先高再低”原则，然后按比例缩放图片：
比如，当前为xhdpi设备，并且只有以下几个目录，则drawable的寻找顺序为：
xhdpi->xxhdpi->xxxhdpi(如果没有更高的了)->nodpi(如果有的话)->hdpi->mdpi，
如果在xxhdpi中找到目标图片，则压缩2/3来使用，如果在mdpi中找到图片，则放大2倍来使用。
-----详细解读
--------Android是怎么匹配布局资源的？
----------以1920*1080形式作为扩展名
单向检索，只匹配比自己小的，绝不往上去匹配；屏幕分辨率以720*1280为例
系统先检索720*1280及其附近的（720*1300等），如果匹配失败，则向下检索（480*800等），直至检索的到默认（320*480），如果向下检索得不到匹配，
则应用挂掉，运行时异常。
*******以上规律对屏幕适配没有任何帮助；----------以 mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi作为扩展名
比如，当前为xhdpi设备，并且只有以下几个目录，则layout的寻找顺序为：
xhdpi->xxhdpi->xxxhdpi(如果没有更高的了)->nodpi(如果有的话)->hdpi->mdpi，
--------Android是怎么匹配values资源的？
----------以 mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi作为扩展名
values目录用来放置colors.xml，dimens.xml，strings.xml等，也可以根据屏幕密度设置特定的values目录让满足设定的设备进行加载，比如values-mdpi、values-hdpi、values-xhdpi、values-xxhdpi等等，然后每个目录放置一个demins.xml，使不同分辨率的设备应用不同的尺寸设置。当应用设备在当前dpi对应目录的demins.xml中没有找到目标条目时，采用“就近匹配”原则：
- 比如，当前为hdpi设备，并且只有以下几个目录，则values的寻找顺序为：
hdpi->xhdpi->mdpi->values，即先向上级dpi目录查找，再向下级dpi目录查找，最后一路向下查找到values目录，如果values下都找不到，就只有找values-ldpi，当然，现在有这个目录的应用不多了。
----------以1920*1080形式作为扩展名
单向检索，只匹配比自己小的，绝不往上去匹配；屏幕分辨率以720*1280为例
系统先检索720*1280及其附近的（720*1300等），如果匹配失败，则向下检索（480*800等），
直至检索的到默认（320*480），如果向下检索得不到匹配，
则应用挂掉，运行时异常。
--------亲自试验--------
默认资源 values
添加备用资源 values-720x1280
----------分别运行在
-----1920*1080 dpi 600 匹配 values-720x1280
-----1920*1080 dpi 480 匹配 values-720x1280
-----1920*1080 dpi 240 匹配 values-720x1280
-----1920*1080 dpi 320 匹配 values-720x1280
-----1920*1080 dpi 160 匹配 values-720x1280
-----720*1280 dpi320 匹配 values-720x1280 1.77
----- 672*1280 dpi320 匹配 values-720x1280 1.90
---- 672*1279 dpi320 匹配 values-720x1280 1.90
---- 672*1200 dpi320 匹配 values-720x1280 1.78
---- 672*1100 dpi320 匹配 values 1.637
-----640*1136 dpi 300 匹配 values 1.775
-----640*1136 dpi 330 匹配 values 1.775
-----800*480 dpi 480 匹配 values
-----800*480 dpi 320 匹配 values
-----800*480 dpi 240 匹配 values
-----800*480 dpi 160 匹配 values
++++++++结论
单向检索，只匹配比自己小的，绝不往上去匹配；屏幕分辨率以720*1280为例
系统先检索720*1280及其附近的（720*1300等），如果匹配失败，则向下检索（480*800等），直至检索的到默认（320*480），如果向下检索得不到匹配，
则应用挂掉，运行时异常。
*******以上规律对屏幕适配没有任何帮助；
=============================================================
dp适配的可行性？
我们首先看下dp的定义：
Density-independent pixel (dp)独立像素密度。标准是160dip.即1dp对应1个pixel，计算公式如：px = dp * (dpi / 160)，屏幕密度越大，1dp对应 的像素点越多。
上面的公式中有个dpi，dpi为DPI是Dots Per Inch（每英寸所打印的点数），也就是当设备的dpi为160的时候1px=1dp；好了，上述这些概念记不记得住没关系，只要记住一点dp是与像素无关的，在实际使用中1dp大约等于1/160inch。
那么dp究竟解决了适配上的什么问题？可以看出1dp = 1/160inch；那么它至少能解决一个问题，就是你在布局文件写某个View的宽和高为160dp*160dp，
这个View在任何分辨率的屏幕中，显示的尺寸大小是大约是一致的（可能不精确），大概是 1 inch * 1 inch。
但是，这样并不能够解决所有的适配问题：
- 呈现效果仍旧会有差异，仅仅是相近而已
- 当设备的物理尺寸存在差异的时候，dp就显得无能为力了。为4.3寸屏幕准备的UI，运行在5.0寸的屏幕上，很可能在右侧和下侧存在大量的空白。而5.0寸的UI运行到4.3寸的设备上，很可能显示不下。
一句话，总结下，dp能够让同一数值在不同的分辨率展示出大致相同的尺寸大小。但是当设备的尺寸差异较大的时候，就无能为力了。
来自鸿洋 点击打开链接
Android 系统可帮助您的应用以两种方式实现密度独立性：
- 系统根据当前屏幕密度扩展 dp 单位数
- 系统在必要时可根据当前屏幕密度将可绘制对象资源扩展到适当的大小
在图 2 中，文本视图和位图可绘制对象具有以像素（px单位）指定的尺寸，因此视图的物理尺寸在低密度屏幕上更大，在高密度屏幕上更小。
这是因为，虽然实际屏幕尺寸可能相同，但高密度屏幕的每英寸像素更多（同样多的像素在一个更小的区域内）。
在图 3 中，布局尺寸以密度独立的像素（dp 单位）指定。由于密度独立像素的基线是中密度屏幕，因此具有中密度屏幕的设备看起来与图 2 一样。
但对于低密度和高密度屏幕，系统将分别增加和减少密度独立像素值，以适应屏幕。
多数情况下，确保应用中的屏幕独立性很简单，只需以适当的密度独立像素（dp 单位）或 "wrap_content" 指定所有布局尺寸值。
系统然后根据适用于当前屏幕密度的缩放比例适当地缩放位图可绘制对象，以适当的大小显示。
应用显示在密度不同的屏幕上时，如果它保持用户界面元素的物理尺寸（从用户的视角），便可实现“密度独立性”。
与屏幕分辨率无关，dp维护界面元素的物理尺寸；
==========================================================
UI要遵循什么样的设计原则呢？
① 字体
类似地，您应选择 sp（缩放独立的像素）来定义文本大小。sp 缩放系数取决于用户设置，系统会像处理 dp 一样缩放大小。
dp和sp都是为了在不同屏幕分辨率上看起来一样大。
② 非字体
==========================
sp 和 dp 点击打开链接
sp会和dp一样独立于设备，但是sp可被用户偏好放大或缩小。
========================
挺不错的一篇文章可以理清思路 点击打开链接
==============
虽然说dp可以去除不同像素密度的问题，使得1dp在不同像素密度上面的显示效果相同，但是还是由于Android屏幕设备的多样性，如果使用dp来作为度量单位，并不是所有的屏幕的宽度都是相同的dp长度，比如说，Nexus S和Nexus One属于hdpi，屏幕宽度是320dp，而Nexus 5属于xxhdpi，屏幕宽度是360dp，Galaxy Nexus属于xhdpi，屏幕宽度是384dp，Nexus 6 属于xxxhdpi，屏幕宽度是410dp。所以说，光Google自己一家的产品就已经有这么多的标准，而且屏幕宽度和像素密度没有任何关联关系，即使我们使用dp，在320dp宽度的设备和410dp的设备上，还是会有90dp的差别。当然，我们尽量使用match_parent和wrap_content，尽可能少的用dp来指定控件的具体长宽，再结合上权重，大部分的情况我们都是可以做到适配的。
dp会遇到这个问题，但是对sp不影响啊，sp不用替换；
======================================
一句话，总结下，dp能够让同一数值在不同的分辨率展示出大致相同的尺寸大小。但是当设备的尺寸差异较大的时候，就无能为力了。
采用百分比，维护了比例一致；
一定有需要以上2种方式协调的场景；
主体采用百分比，按需求局部采用dp和sp。
屏幕尺寸集中在 4.5-5.5英寸 点击打开链接
因此必要担心按照比例缩放字体物理尺寸会变小；
解决了字体，其他的都解决了，所以百分比适配堪称完美；
=========================
百分比适配的局限性
没有考虑到的分辨率，可能会出现特殊情况；
apk包变大；
===================
采用google提供的百分比支持库
添加依赖
compile 'com.android.support:percent:25+'add PercentLinearLayout 点击打开链接
鸿洋 点击打开链接
==================
需要考虑 文字适配吗？
文字使用sp作为单位，则在各种屏幕上显示的大小一致；会出现和其他在百分比下的冲突吗？
冲不冲突这要看文字的缩放比例了，和百分比下的是否一致；
320*480 1
480*800 1.5
720*1280 2
1080*1920 3
宽高等非文字尺寸都是用百分比的，
而 文字用sp就会导致 可能与原设计UI比例不一致；
但是你要清楚 实际设备配置都是遵循Android设计规律的：
分辨率的宽高要遵循 Android标准；
一般来说15:9 ； 16:9 ;
一般来说依据标准 宽和高等比例缩放；缩放值 恰好等于 屏幕像素密度dpi/160dpi；
用sp标注文字尺寸失真之处在于 UI设计稿是在16:9下做的，而 还必须适配15:9的屏幕，在15:9下就会产生失真，
但是由于 字体的大小 一般集中在 32px左右（xhdpi下），一般来说最高 偏差在 6px ，一般来说 偏差在 3px ，可以忽略不计 ；
由此可以得出结论 sp是可以达到文字适配效果的，并且一般偏差度在 3 px，可以忽略；
===============================
经过以上论述，可以提出一种屏幕适配方案：
google提供的百分比支持库+文字sp
========================
基于上述关于sp适配的结论，反过来想，如果忽略用户偏好设置，对文字采取百分比适配方案也是可以的呀！
甚至在不影响文字效果的情况下，更精确了，更接近于UI设计稿；
==========================
尽量用LinearLayout写，似乎也可以解决问题！
===================
拿到设计图，meta信息中填入设计图的尺寸，然后不需要额外计算，布局直接抄设计图上的尺寸，不产生任何多余的资源文件，完成各种分辨率的适配！
鸿洋 autoLayout 点击打开链接
虽然解决了常见的适配，但是毕竟不是官方的，可能会遇到一些麻烦，
这么看来，屏幕适配注定是麻烦的。
=============
既然一种方案解决不了问题，那么如果我选择组合式呢？
support-percent-lib结合autoLayout使用！
===============
其实你get到要点没有？要先现在集中到屏幕 15:9 ； 16:9 ； 等区别，宽度的区别；
===================
按照百分比适配这篇文章写的不多
对目前适配的一个总结 点击打开链接
扫一扫
2957
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
