⑴ android屏幕适配有哪些方法
Android 资源文件夹有其中两种方式支持屏幕适配：
一、方法：
1.XXX XXX-ldpi XXX-mdpi XXX-hdpi XXX-xhdpi XXX-xxhdpi 这种方式 （推荐使用）
2.XXX XXX-123x456 后面是具体值（不推荐使用这种方式！）
当我们做适配处理时通常会在以上一堆文件夹中定义 xxx.xml 例如 定义一个 ： <dimen name="list_item_height">100dip</dimen>
二、适配举例：
Android的匹配机制和手机系统有关：
规则一：Android4.0 以上的手机，先寻找和设备吻合的文件夹里的相应文件里的资源，如果没有找到会继续匹配它下面（比它分辨率或密度小）的一些文件夹，最后去XXX 默认文件夹中匹配。
eg1: 小米2s (4.1 1280x720) 有文件夹 XXX XXX-320x240 XXX-800x480 XXX-1280x719 XXX-1280x720 XXX-1280x721 XXX-xhdpi
1.匹配XXX-xhdpi
2.匹配XXX-1280x720
3.匹配XXX-1280x719
4.匹配XXX-480x800
5.匹配XXX-320x240
6.匹配XXX
eg2：HTC ONE (4.2 1920×1080)
规则二：Android4.0 以下的手机，先寻找和设备吻合的文件夹里的相应文件里的资源，如果没有找到会继续匹配它下面（比它密度小）的一些文件夹。
eg:三星m250L(同三星9100 2.3.7 800x480) 有文件夹 XXX XXX-320x240 XXX-800x479 XXX-480x800 XXX-ldpi XXX-mdpi XXX-hdpi
1.匹配XXX-hdpi
2.匹配XXX-mdpi
3.匹配XXX-480x800
4.匹配XXX
5.匹配XXX-ldpi
6.程序退出
eg3:华为U8860(2.3.6 854x480)
所以在项目中<dimen name="list_item_height">50dip</dimen> 分别定义在
values : <dimen name="list_item_height">50dip</dimen> 和
values-320x240 : <dimen name="list_item_height">42dip</dimen> 中.
小米2s 会取 values-320x240 中42dip 的值。
⑵ 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
⑶ Android屏幕适配之全面屏适配
从2017年开始，全面屏之战逐渐如火如荼的展开了，那么我们Android程序员又多了一个小事情，就是解决全面屏适配的问题。
全面屏和以前的屏幕相比，有以下几点改变
声明方式
ratio_float这个值怎么取呢？
其实就是高宽比。
传统的手机高宽比是：16 : 9 即 16 / 9 ≈ 1.78
那么全面屏的手机宽高比：18 ：9 即 18 / 9 = 2
但是这个时候，我们需要注意一下，现在很多手机都在追求更大的高宽比，即让屏幕顶部和底部边框越小越好，比如现在的“小米 mix 3 ”
即他的高宽比是
19.5 / 9 ≈ 2.17
所以保险起见，设置成为 2.2, 当然这个值也不是固定的，如果有更新的手机上市，没准我们还得改。
即这样设定就好了
Android 7.0 google 默认支持了分屏模式，即 Manifest 文件中配置 Activity 的
那么这个时候就不需要再配置上面的 “最大屏幕高宽比”，就可以适配全面屏了。
但是如果通过自定义控件将“分屏模式”禁止的话，就会出现屏幕 上下黑边的效果，非常丑。
修改AndroidManifest.xml文件，设置targetSdkVersion>=26，就是应用升级到O版本。
不需要设置其他任何属性，默认在任何纵横比的屏幕都能全屏显示。
（备注：有一种例外情况需要注意，应用如果已经适配到O版本，并且通过meta-data属性android.max_aspect或者是android:MaxAspectRatio属性设置了页面支持的最大纵横比，同时又通过android:resizeableActivity=“false”设置了页面不支持分屏，这个时候系统会按照应用自己设置的最大纵横比决定该页面是否能全屏显示，如果应用设置的最大纵横比比手机屏幕比例小，那应用还是无法全屏显示。）
默认 UI 为我们切的启动页面的图是固定的，比如 1920*1080
这个能适配以前一般的分辨率的手机，但是全面屏的出现，我们会发现，这个启动页的图片会被拉伸，一般是纵向拉伸，因为 “高” 变大了。
那么这种情况的解决方法其实有这么几种思路：
本人还是觉得虚拟导航按键不是一个好东西，但是全面屏的出现，真的把我以前喜欢的"实体按键" 给舍弃掉了。
我倒是觉得替代以前的"实体按键"的最好的方法，还是手势操作。起码我觉得小米8 的手势操作很 6 有没有。再看看苹果，压根就不同虚拟按键考虑好不。。。
不过，这是我自己的拙见，请各位虚拟按键爱好者，不要喷我，先行谢过。
原则，虚拟按钮的显示样式，其实根据当前具体的页面情况进行调整，调整策略其实和status bar 的类似。
可以通过
来定义颜色。
或者通过设置当前activity 主题 或者设置application主题
在主题的样式中设置：
即可。
频繁的手机更新迭代，虽然让我们程序员多了一些事情可做，但是却也是我们喜闻乐见的事，手机在发展，说明我们的行业也在发展呀，况且，解决这些问题也不是难事。你说是不是呢？
如果没看懂我的文章，请观看小米官网提供的方案（其实是一致的）：
全面屏及虚拟键适配说明
⑷ Android 屏幕适配
摘自： https://www.jianshu.com/p/ec5a1a30694b
摘自： https://www.jianshu.com/p/337c47721690
摘自： https://www.jianshu.com/p/4669814362ee
因为ui设计师给你的设计图是以px为单位的，Android开发则是使用dp作为单位的，那么我们需要进行转换：
扩展：
Android屏幕适配-基础篇
Android推荐使用dp作为尺寸单位来适配UI ，通过dp加上自适应布局和weight比例布局可以基本解决不同手机上适配的问题，这基本是最原始的Android适配方案。
缺点：
（1）这种方案只能保证我们写出来的界面适配绝大部分手机，部分手机仍然需要单独适配，但dpi的不同，还是会存在差异。
（2）一般的设计稿都是以px为单位的，所以我们在写layout文件的时候需要将px转为dp，影响开发效率。
为了高效的实现UI开发，出现了新的适配方案，我把它称作宽高限定符适配。简单说，就是模仿市面上所有的Android手机的宽高像素值，设定一个基准的分辨率，其他分辨率都根据这个基准分辨率来计算，在不同的尺寸文件夹内部，根据该尺寸编写对应的dimens文件:
鸿洋大神的作品 ，使用也超级简单，核心功能就是在绘制的时候在onMeasure里面做变换，重新计算px。
缺点：
我们自定义的控件可能会被影响或限制，可能有些特定的控件（框架没有做适配的控件），需要单独适配。
小结：上述几种适配方案都是实际开发中用过的方案，但随着技术不断的更新，出现了更好的适配方案。
1.SmallestWidth适配（sw限定符适配）
实现原理：
Android会识别屏幕可用高度和宽度的最小尺寸的dp值（其实就是手机的宽度值），然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。
sw限定符适配 和 宽高限定符适配 类似，区别在于，前者有很好的容错机制，如果没有value-sw360dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问
优点：
1.非常稳定，极低概率出现意外
2.不会有任何性能的损耗
3.适配范围可自由控制，不会影响其他三方库
缺点：
就是多个dimens文件可能导致apk变大，几百k。
这里有个问题：
在项目的其他 mole 中怎么实现适配？难道也要多套 dimens 文件？
解答：
并不需要多套 dimens 文件，只需要在 values 文件夹下有一套与 app mole 一样的 dimens 文件即可达到适配。因为经过编译，所有 mole 中的 dimen 数据都会统一归类到主 mole（即 app mole）中的 values/dimens.xml 文件中了，然后系统又会根据你设置的值去找对应 values-swxxxdp 文件夹下的dimens.xml 文件中的值。
附件： [生成sw文件的工具]( https://links.jianshu.com/go ?
to=https%3A%2F%2Fgithub.com%2Fladingwu%2Fdimens_sw)
实现原理：修改系统的density值（核心）
今日头条适配是以设计图的宽或高进行适配的，适配最终是改变系统density实现的。
过程：
缺点：
1.只需要修改一次 density，项目中的所有地方都会自动适配，这个看似解放了双手，减少了很多操作，但是实际上反应了一个缺点，那就是只能一刀切的将整个项目进行适配，但适配范围是不可控的。
2.这个方案依赖于设计图尺寸，但是项目中的系统控件、三方库控件、等非我们项目自身设计的控件，它们的设计图尺寸并不会和我们项目自身的设
AndroidAutoSize 是基于今日头条适配方案，该开源库已经很大程度上解决了今日头条适配方案的两个缺点，可以对activity，fragment进行取消适配。也是目前我的项目中所使用的适配方案。
使用也非常简单只需两步：
第一步： 导入依赖
第二步： 配置AndroidManifest
在 AndroidManifest 中填写全局设计图尺寸 (单位 dp)，如果使用副单位，则可以直接填写像素尺寸，不需要再将像素转化为 dp，详情请查看 demo-subunits
老师给的UI设计是在蓝湖上的，因为还没工作，接触就蓝湖，SW个人感觉好处就是蓝湖上尺寸多少你就写多少就行
⑸ 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遍......