Android屏幕适配-应用篇

Android屏幕适配最主要的原因：
是由于Android手机的分辨率和尺寸千奇百怪，虽然Android官方提供了dp单位来适配，但其在各种奇怪分辨率下表现却不尽如人意。
主要是由于在界面在渲染绘制时，android会将dp转为px，在转换过程中是需要dpi的（上篇文章中有提到），而dpi是根据屏幕真实的分辨率和尺寸来计算的，每个设备都可能不一样的，从而导致显示问题。

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

一、Android屏幕适配的发展
1、dp直接适配
2、宽高限定符适配
3、UI适配框架Autolayout
二、目前最好的适配方案
1、SmallestWidth适配（sw限定符适配）
2、今日头条适配方案
3、AutoSize

一、Android屏幕适配的发展

1、dp直接适配

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

2、宽高限定符适配

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

20150503174449732.jpg

缺点：这个方案有一个致命的缺陷，那就是需要精准命中才能适配，比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。而使用默认的尺寸的话，UI就很可能变形，简单说，就是容错机制很差。

3、UI适配框架Autolayout

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

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

二、目前最好的适配方案

1.SmallestWidth适配（sw限定符适配）

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

附件：生成sw文件的工具

2.今日头条适配方案

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

20150503174449732.jpg

优点：使用成本低，侵入性低，修改一次项目所有地方都会适配，无性能损耗
缺点：
1.只需要修改一次 density，项目中的所有地方都会自动适配，这个看似解放了双手，减少了很多操作，但是实际上反应了一个缺点，那就是只能一刀切的将整个项目进行适配，但适配范围是不可控的。
2.这个方案依赖于设计图尺寸，但是项目中的系统控件、三方库控件、等非我们项目自身设计的控件，它们的设计图尺寸并不会和我们项目自身的设

3.AndroidAutoSize

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

 implementation 'me.jessyan:autosize:1.1.2'

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