浅谈Android适配
Android系统能发展到今天，离不开其开放性，而随着国内手机厂商的崛起，任何用户、开发者、OEM厂商、运营商都可以对Android进行定制，于是导致长期以来一直诟病的碎片化严重的问题。而当Android系统、屏幕尺寸、屏幕密度出现碎片化的时候，就很容易出现同一元素在不同手机上显示不同的问题，为了保证某一元素在Android不同尺寸、不同分辨率的手机上具备相同的显示效果，这个时候就需要对屏幕进行适配。
一、为了更好的理解Android适配，我们先熟悉一下几个关键概念：
1、关键概念
屏幕尺寸：手机对角线的物理尺寸 单位：英寸（inch），1英寸=2.54cm
屏幕分辨率：手机在横向、纵向上的像素点数总和，单位是px，1px=1个像素点，一般以纵向像素*横向像素
屏幕像素密度：每英寸的像素点数 dpi（dots per ich）
dp(Density Independent Pixel) ：虚拟像素单位，1 dp 约等于中密度屏幕（160dpi；“基准”密度）上的 1 像素。对于其他每个密度，Android 会将此值转换为相应的实际像素数。（注：早期android定义为dip，后改城dp，即是dip=dp）
sp(Scale Independent Pixel) ：在定义文本大小时，您应改用可缩放像素 (sp) 作为单位（但切勿将 sp 用于布局尺寸）。默认情况下，sp 单位与 dp 大小相同，但它会根据用户的首选文本大小来调整大小。
px：像素单位，我们通常映射到屏幕像素的标准像素单位。
in：英寸，物理屏幕尺寸单位。
pt：磅 , 1pt=1/72英寸=0.035厘米
2、dp,px,dpi之间的关系
dp,px,dpi之间的关系
3、dp与px的转换
因为ui设计师给你的设计图是以px为单位的，Android开发则是使用dp作为单位的，那么我们需要进行转换：
dp与px的转换
在Android中，规定以160dpi（即屏幕分辨率为320x480）为基准：1dp=1px
二、为什么要进行Android屏幕适配
由于Android系统的开放性，任何用户、开发者、OEM厂商、运营商都可以对Android进行定制，于是导致：
1）Android系统碎片化：小米定制的MIUI、魅族定制的flyme、华为定制的EMUI等等
2）Android机型屏幕尺寸碎片化：5寸、5.5寸、6寸等等
3）Android屏幕分辨率碎片化：320x480、480x800、720x1280、1080x1920、2560*1600
当Android系统、屏幕尺寸、屏幕密度出现碎片化的时候，就很容易出现同一元素在不同手机上显示不同的问题。
为了保证用户获得一致的用户体验效果（使得某一元素在Android不同尺寸、不同分辨率的手机上具备相同的显示效果），于是，我们便需要对Android屏幕进行适配。
三、 如何进行屏幕尺寸匹配？
常用适配技巧
1、宽高限定符适配方案
所谓的宽高限定符适配就是穷举市面上所有的Android手机的宽高像素值，不过需要先设定一个基准，然后其它分辨率根据这个基准做适配，如图所示：
宽高限定符适配
该方式需要设置一个基准，其它分辨率根据这个基准做适配，分析需要的支持的分辨率，可以通过工具自动生成如图所示的资源文件，这得感谢鸿洋大佬提供的生成工具。
备注：而关于屏幕分辨率信息，可以通过该网站查询：点击这里跳转查询屏幕分辨率信息
资源文件生成工具
这里提供了个jar包，默认情况下，双击即可生成，如图所示：
jar包
这里默认内置了常用的分辨率，默认基准为480*320，主流的分辨率已经集成到程序里了。对于特殊需求，可以通过命令行指定即可，比如我想以分辨率1280 * 800为基准 ，并且额外支持尺寸：1152 * 735；4500 * 3200，如图所示：
命令行指定基准分辨率
格式如下：
java -jar xx.jar width height width,height_width,height
最后自动生成文件如图所示：
生成的资源文件
这样就更改了默认的基准，还添加了额外支持的分辨率。
使用这种适配方案，可以按照UI设计稿的尺寸为基准分辨率，这时运行在不同分辨率的手机中，这些系统会根据这些dimens引用去该分辨率的文件夹下面寻找对应的值，这样基本解决了我们的适配问题，而且极大的提升了我们UI开发的效率。
缺点：
1）最明显的肯定就是占用资源大，会增加APK的体积
2）容错机制大，需要精准命中资源文件才能适配，比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。而使用默认的尺寸的话，UI就很可能变形。
2、今日头条适配方案
文章链接，这也是相对比较完美的方案，我先简单说一下这个方案的思路，它是通过修改density值，强行把所有不同尺寸分辨率的手机的宽度dp值改成一个统一的值，这样就解决了所有的适配问题。
比如，设计稿宽度是360px，那么开发这边就会把目标dp值设为360dp，在不同的设备中，动态修改density值，从而保证(手机像素宽度)px/density这个值始终是360dp,这样的话，就能保证UI在不同的设备上表现一致了。
这个方案侵入性很低，而且也没有涉及私有API，应该也是极不错的方案，我暂时也想不到强行修改density是否会有其他影响，既然有今日头条的大厂在用，稳定性应当是有保证的。
但是根据我的观察，这套方案对老项目是不太友好的，因为修改了系统的density值之后，整个布局的实际尺寸都会发生改变，如果想要在老项目文件中使用，恐怕整个布局文件中的尺寸都可能要重新按照设计稿修改一遍才行。因此，如果你是在维护或者改造老项目，使用这套方案就要三思了。
3、smallestWidth适配
smallestWidth适配，或者叫sw限定符适配。指的是Android会识别屏幕可用高度和宽度的最小尺寸的dp值（其实就是手机的宽度值），然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。
这种机制和上文提到的宽高限定符适配原理上是一样的，都是系统通过特定的规则来选择对应的文件。
举个例子，小米5的dpi是480,横向像素是1080px，根据px=dp(dpi/160)，横向的dp值是1080/(480/160),也就是360dp,系统就会去寻找是否存在value-sw360dp的文件夹以及对应的资源文件。
smallestWidth适配
smallestWidth限定符适配和宽高限定符适配最大的区别在于，前者有很好的容错机制，如果没有value-sw360dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问题。
这套方案是上述几种方案中最接近完美的方案。
首先，从开发效率上，它不逊色于上述任意一种方案。根据固定的放缩比例，我们基本可以按照UI设计的尺寸不假思索的填写对应的dimens引用。
我们还有以375个像素宽度的设计稿为例，在values-sw360dp文件夹下的dimens文件应该怎么编写呢？
这个文件夹下，意味着手机的最小宽度的dp值是360，我们把360dp等分成375等份，每一个设计稿中的像素，大概代表smallestWidth值为360dp的手机中的0.96dp，那么接下来的事情就很简单了，假如设计稿上出现了一个10px*10px的ImageView,那么，我们就可以不假思索的在layout文件中写下对应的尺寸。
当系统识别到手机的smallestWidth值时，就会自动去寻找和目标数据最近的资源文件的尺寸。
其次，从稳定性上，它也优于上述方案。原生的dp适配可能会碰到Pixel 2这种有些特别的手机需要单独适配，但是在smallestWidth适配中，通过计算Pixel 2手机的的smallestWidth的值是411，我们只需要生成一个values-sw411dp(或者取整生成values-sw410dp也没问题)就能解决问题。
smallestWidth的适配机制由系统保证，我们只需要针对这套规则生成对应的资源文件即可，不会出现什么难以解决的问题，也根本不会影响我们的业务逻辑代码，而且只要我们生成的资源文件分布合理，即使对应的smallestWidth值没有找到完全对应的资源文件，它也能向下兼容，寻找最接近的资源文件。
当然，smallestWidth适配方案有一个小问题，那就是它是在Android 3.2 以后引入的，Google的本意是用它来适配平板的布局文件（但是实际上显然用于diemns适配的效果更好），不过目前所有的项目应该最低支持版本应该都是4.0了（糗事百科这么老的项目最低都是4.0哦），所以，这问题其实也不重要了。
项目地址：smallestWidth适配
点击进入上文的github项目，下载到本地，然后运行该Java工程，会在本地根目录下生成相应的文件，如果需要生成更多尺寸，在DimenTypes 文件中填写你需要的尺寸即可。建议以300,320,360,411，450这几个尺寸为基础，然后在其中插入一些其他的尺寸即可，如果不放心，可以在300-450之间，以10为步长生成十几个文件。
以上为关于适配的基本介绍和方案分析，此外无论选择哪一种方案，都一定要提前弄清楚它的原理，因为这些方案的原理都不复杂，弄清楚有助于更合理的使用甚至扩展为更适合自己的方案。
