Android流行UI适配方案对比与评测

Android流行UI适配方案对比与评测

• 如果你是一个优点姿色（不不是有点资历）的android开发攻城狮，你一定会懂得android屏幕适配带来的烦恼，这个问题还将会一直的持续下去

下载完整演示代码,下载完整演示代码,下载完整演示代码

目录

1. 前言

2. 主流适配方案对比

3. 屏幕适配的知识必备

4. 张鸿洋 AutoLayout百分比适配框架介绍

5. smallestWidth适配框架介绍

6. 今日头条的AndroidAutoSize适配框架介绍

7. 下面我们谈一谈，使用鸿洋大神的 AutoLayout 框架的项目如何过渡到 smallestWidth 屏幕适配方案

1. 前言

最近一段时间各种适配方案的文章层出不穷，关于适配的的话题，在这个乱世之秋也从来没有间断过，其中曝光度最高的是今日头条的适配方案，到今日头条的适配方案，其实不得不说一下 smallestWidth 适配，今天我们就来大话一下android适配方案的选择和使用体验

我们在Android开发时，肯定会觉得屏幕适配是个尤其痛苦的事，各种屏幕尺寸适配起来蛋疼无比。如果我们换个角度我们看下这个问题，不知道大家有没有了解过web前端开发，或者说大家对于网页都不陌生吧，其实适配的问题在web页面的设计中理论上也存在，为什么这么说呢？电脑的显示器的分辨率、包括手机分辨率，我敢说分辨率的种类远超过Android设备的分辨率，那么有一个很奇怪的现象：

为什么Web页面设计人员从来没有说过，尼玛适配好麻烦？

或许这些会给我们的适配方案上面提供一些不错的解决思路。其实不论是谷歌官方的 百分比布局库(percent-support-lib) 、鸿洋大神的 Android AutoLayout适配框架、 smallestWidth、今日头条的 AndroidAutoSize框架，他们都是在延续着使用百分比的思想来解决android手机类型繁多形态下的适配问题。其中对比我们在变更和对比部分进行分析。

• 对于一个优秀的适配框架的盘被标准一般遵循以下的几个方面
• 适配效率，即把设计图转化为App界面的过程是否高效
• 是否可以保证尽可能的实现UI界面在不同尺寸和分辨率的手机中UI的一致性
• 代码切入性是否强（这个一般是将原有项目适配方案替换成其他适配方案或者由其他方案替换本方案是不是简单，如果需要更改一堆代码，那还是果断的放弃好了）
• 适配方案的明显的优缺点（缺陷明显的适配方案直接pass）

2. 主流适配方案对比

纵观来看相对于Linus和Windows来说，android还是比较年轻的系统，相比来看android自从进入中国市场后发展还是比较快的，其中华为在android系统的优化上面做出了很大的贡献，当然国内的厂商喜欢自己定制自己的系统，自此有了原生和android和 本土android 两种系统 ，随着发展和壮大避免不了的出现了屏幕的碎片化。对于这个问题也出现和很多的解决方案，大体有以下几种

适配方案或适配库	发布时间	原理	优点	缺点	相关文章	开源库或项目	作者或团队名称	备注
百分比布局库(percent-support-lib)	2015.06	通过自定义控件 PercentRelativeLayout、PercentFrameLayout 继承android原生控件FrameLayout和RelativeLayout并重写 onMeasure（） 方法实现的，根据屏幕的宽和高双向百分比适配	这个嘛，肯定在后续适配思路上是一个很不错的借鉴嘛（虽然这个库当时还十分的鸡肋），后面比较出名的库-鸿洋的AutoLayout适配框架就是基于这个开发的	1. 不能支持LinearLayout和自定义控件，局限性比较大 2.代码入侵强，一但发现问题切换其他适配库成本极高 3.根据宽高各自百分比适配，当屏幕宽高比和设计稿差距比较大的时候，出现过度变形不能满足预期 4.谷歌在2015.06以后放弃维护（弊端太大果断放弃了）	Android 百分比布局库(percent-support-lib) 解析与扩展	JulienGenoud/android-percent-support-lib-sample	google	虽然官方仅仅给了 PercentRelativeLayout、PercentFrameLayout两种控件，但是很明显模仿官方的思路可以很好的实现LinearLayout、ScrollVeiw等ViewGroup控件的扩展 已停止维护，慎用
Android AutoLayout 框架	2015.07	通过自定义控件 AutoRelativeLayout、AutoLinearLayout 继承android原生控件 RelativeLayout 和 LinearLayout 并重写 onMeasure（） 方法实现的，根据屏幕的宽和高双向百分比适配	思路借鉴了Google的百分比解决方案并进行优化，直接填写设计图上的像素尺寸即可完成适配，最大限度解决适配问题	1. 不能支持 自定义控件，局限性比较大 2.代码入侵强，一但发现问题切换其他适配库成本极高 3.根据宽高各自百分比适配既是优点更是缺点，当屏幕宽高比和设计稿差距比较大的时候，出现过度变形不能满足预期 4.无法适配刘海儿屏幕，自从有了刘海儿手机直接放弃这套方案	Android AutoLayout全新的适配方式 堪称适配终结者	https://github.com/hongyangAndroid/AndroidAutoLayout	张鸿洋	已停止维护，慎用
smallestWidth适配	2018.04	开发者先在项目中根据主流屏幕的 最小宽度 (smallestWidth) 生成一系列 values-swdp 文件夹 (含有 dimens.xml 文件)，当把项目运行到设备上时，系统会根据当前设备屏幕的 最小宽度 (smallestWidth) 去匹配对应的 values-swdp 文件夹，而对应的 values-swdp 文件夹中的 dimens.xml 文字中的值，又是根据当前设备屏幕的 最小宽度 (smallestWidth) 而定制的，所以一定能适配当前设备	只要我们的代码定义的尺寸和设计稿完全一致，可以实现标注多少代码就用多上px	1. 采用这套方案我们的APP体积会增加1-2M 2.代码侵入性强，后期不容易切换成其他适配方案	骚年你的屏幕适配方式该升级了!-SmallestWidth 限定符适配方案	暂无	暂无	如果项目对APP体积增加1-2M不是很敏感，这个是最完美的解决方案
今日头条的AndroidAutoSize	2018.08	以屏幕的最大宽度为基准，引入density概念，按照设计稿中控件的尺寸进行横向和竖直的百分比转化，本质上是单一个横向百分比适配思路，和smallestWidth适配的区别在于百分比是由控件onMessure时计算得到的	这个嘛，肯定在后续适配思路上是一个很不错的借鉴嘛（虽然这个库当时还十分的鸡肋），后面比较出名的库-鸿洋的AutoLayout适配框架就是基于这个开发的	1. 难以解决自定义控件适配问题 4.谷歌在2015.06以后放弃维护（弊端太大果断放弃了）	骚年你的屏幕适配方式该升级了!-今日头条适配方案	https://github.com/JessYanCoding/AndroidAutoSize	今日头条团队	如果对APP体积敏感这个框架是最佳选择

综合来说

• autoLayout百分比框架因为存在1.自定义控件无法自动适配2.无法完成刘海儿屏幕适配3.作者在15年停止了对项目的维护所以这个适配的方案直接被放弃，但是作者的思路还是值得我们去借鉴的，特别是当我们进行控件的自定义的时候
• 存在优点
  • 1. 当设计稿尺寸和我们的代码中定义尺寸相同是无需转化直接使用
  • 2. 代码侵入性很小
• 缺点
  • 1. 无法有效的解决三方自定义控件适配问题
  • 2. 当一个activity中含有多种设计稿尺寸的控件，本适配方案无法满足要求
  • 3. 无法完成刘海儿屏幕适配
  • 4. 作者在15年停止了对项目的维护
• 详细文章Android AutoLayout全新的适配方式 堪称适配终结者

• smallestWidth适配是截止目前为止市面上最接近于完美适配的解决方案
• 存在优点
  • 1. 适配简单，如果设计稿和生成dimens文件尺寸相同直接按照设计稿标注编写代码，无需转换
  • 2. 项目开发前只需引入一次适配文件，后面直接使用
• 缺点
  • 1. 增加APP体积，通过测试发现在1M左右
  • 2. 代码侵入性强，变更其他的适配方案选用布局文件逐一替换
  • 详细文章骚年你的屏幕适配方式该升级了!-SmallestWidth 限定符适配方案

• 今日头条的AndroidAutoSize适配方案是通过代码计算方式完成适配的最佳解决方案，如果项目对APP的体积有要求，这个是一个不错的选择
• 存在优点
  • 1. 当设计稿尺寸和我们的代码中定义尺寸相同是无需转化直接使用
  • 2. 代码侵入性很小
  • 3. 代码在积极维护中，出现问题方便解决
• 缺点
  • 1. 无法有效的解决三方自定义控件适配问题
  • 2. 当一个activity中含有多种设计稿尺寸的控件，本适配方案无法满足要求
  • 3. 尝试不同activity单独适配时，设计稿尺寸变得臃肿复杂
  • 详细文章骚年你的屏幕适配方式该升级了!-今日头条适配方案

3. 屏幕适配的知识必备

4. 张鸿洋 AutoLayout百分比适配框架介绍

• 详细文章Android AutoLayout全新的适配方式 堪称适配终结者

5. smallestWidth适配框架介绍

• 详细文章骚年你的屏幕适配方式该升级了!-SmallestWidth 限定符适配方案

6. 今日头条的AndroidAutoSize适配框架介绍

• 详细文章骚年你的屏幕适配方式该升级了!-今日头条适配方案

7. 下面我们谈一谈，使用鸿洋大神的 AutoLayout 框架的项目如何过渡到 smallestWidth 屏幕适配方案

• 重要的事 ：如果你的项目现在使用的是 AutoLayout框架 现在期望切换到 SmallestWidth适配框架,如果你想的是傻傻的手动切换，纳尼，你真的就out了，现在是21世纪了，什么最重要，脚本啊
• 好东西不敢独享，下面是最新研制的脚本，周边的朋友用完了反响还不错，谢谢你们的支持
• 点击我获取完成脚本，支持替换一键完成 android适配鸿洋_Autolayout自动化转换smallestWidth适配解决方案gradle脚本代码
• 点击我获取完成脚本，支持替换一键完成 android适配鸿洋_Autolayout自动化转换smallestWidth适配解决方案gradle脚本代码
• 点击我获取完成脚本，支持替换一键完成 android适配鸿洋_Autolayout自动化转换smallestWidth适配解决方案gradle脚本代码

AutoLayout框架下原有项目中的布局是这个样的，不得说使用起来是真心的方便，任何的控件尺寸距离和文字大小的标注统一使用 PX 完全解决问题了，而且只要是 十几稿尺寸和我们项目中引用的尺寸是相同的，那就只有一个体验 ，爽，倍儿爽，直接按照设计稿照搬就可以的啦

当然在项目迁移完成后我们的代码将会变成这样的

上面的代码在不同的android设备上的性能演示

• 先看红米 Note3

主屏尺寸：5.5英寸 主屏分辨率：1920x1080像素

• 刘海屏幕的手机一直是比较难适配的，不如这个oppo

屏幕尺寸：5.7英寸 运行内存：4GB 屏幕分辨率：1440×720像素

这个是里面有一个类型按钮没有适作为对比，可见如果不进行适配差距还是比较大的

下面将类型这个按钮的文字也按照 android:textSize="@dimen/qb_px_45"的方式进行适配，和红米手机进行对比，怎么样是不是很完美了

• 那你说，仅仅适配手机，那平板怎么解决啊，这个当然还是看公司的要求了，如果公司有条件的话我还是强烈的建议单独的位平板电脑开发一个HD版本的，这样在用户的体验上面是更加好的。但是如果我们的项目在研发阶段的还没有很大的用户量和市场渠道，那该怎么办呢，当然可以使用手机的一套代码适配平板优先打开市场。不多看一下在pad上的适配表现吧

同样的为了对比的方便，我们依旧单独在界面上留了一个 类型 小按钮不做适配，可以看到适配方面还是有一些差距的

下面将类型这个按钮的文字也按照 android:textSize="@dimen/qb_px_45"的方式进行适配，和红米手机进行对比，怎么样是不是很完美了

• 到这里方案的优劣和替换原理以及步骤我们都明白了，剩下的就是 just do it，不过先等等，你不是要真的是要 手动替换吧，这个不是一个优质的攻城狮（重度懒癌患者）该具备的哦，好啦这个我已经替大家真备好了，直接下载下面的脚本然后然在自己的项目里面运行一下就可以了，记得替换一下里面脚本的路径哦

• 附赠代码迁移的gradle脚本,点击获取脚本
  
  android适配鸿洋_Autolayout自动化转换smallestWidth适配解决方案gradle脚本代码

总结

• smallestWidth 屏幕适配的方案可以作为 AutoLayout 的过度选择，这个框架在各个手机上面的适配效果均达到了很不错的效果

• 优点： 适配简单，完美支持三方控件

• 缺点：

  • 需要创建大量的 xml文件，为APP的体积增加贡献 600-700K
  • 代码侵入性强，一旦决定采用这种方案，代码将会大改，如果我们想要替换其他适配方案成本将是巨大的（需要对每一个控件进行修改）