论文部分内容阅读
摘 要：随着Android设备种类繁多，屏幕尺寸差别较大，加之Android、应用软件的碎片化严重，屏幕适配一直是开发中较为头疼的问题;本文采用使用门的pt作为长度单位，完全按照设计图上标注的尺寸来编写页面，即控件在所有屏幕上相对于整个屏幕的相对大小都一致（看起来只是将设计图等比缩放至屏幕宽度大小），实现了Android的屏幕自适应效果。中国
关键词：Android;屏幕;自适配策略
中图分类号：TP3 文献标识码：A
现状
由于Android设备种类繁多，屏幕尺寸差别较大，加之Android碎片化严重，屏幕适配一直是开发中较为头疼的问题。面对市面上五花八门的屏幕大小与分辨率，Android基于dp与res目录名称来适配的方案已无法满足一次编写全屏幕适配的需求，为了达到最优的视觉效果，开发过程中需要花费较多资源进行适配。
1、常见的解决方案----官方适配方案
1.1 dp方法
Dp（设备独立像素）是Android开发中特有的一个单位。与px（绝对像数）不同，dp是基于屏幕像素密度的一种单位。在密度低的屏幕上或许1dp=1px，但在密度高的屏幕上可能1dp=4px。编写布局xml时，如果一个控件的长宽都使用dp来指定，那么能确保该控件在各种大小与分辨率的屏幕下的绝对大小都大致相当。也就是说无论在pad下还是大小屏手机下，实际看到的该控件的大小是差不多的：
1.2 Ver方法
Ver（资源目录名）是最常见的屏幕布局方法，Ver目录用于存放Android应用程序使用到的所有资源，按照约定将不同的资源存放到不同的文件夹内。上图可见虽然使用dp确保了控件在不同屏幕中的绝对大小一致。这样的好处在于，在大小相近的屏幕中，无论分辨率多大都不会对布局造成影响;但是当屏幕大小相差较大时，仅保证控件的绝对大小看起来就有些问题了。在res目录下可以给各资源目录都加上例如“1920x1080”等后缀来适配不同的屏幕，具体规则可见官网文档。这样可以针对不同的屏幕提供不同的布局，甚至针对pad与手机提供两套完全不同的布局样式。但是通常情况下，设计师并不会对不同屏幕提供不同的设计图，他们的需求仅仅是不同屏幕下控件对屏幕的相对大小一致，所以dp并不能满足这一点，而对各种屏幕适配一遍又显得略为繁琐，并且修改也较为麻烦。通常需要的适配如下：
1.3 Px方法
Px（百分比布局支持庫）为deprecated推荐使用的布局，看起来似乎略复杂，但适配目的很明确，目的就是要确保控件在不同屏幕的相对大小一致，看起来一模一样的，归纳常用的适配方案：
方案一：编写脚本将长度转换成各分辨率下的长度，缺点是难以覆盖市面上的所有分辨率。
方案二：AutoLayout支持库。该库的想法非常好：对照设计图，使用px编写布局，不影响预览;绘制阶段将对应设计图的px数值计算转换为当前屏幕下适配的大小;为简化接入，inflate时自动将各Layout转换为对应的AutoLayout，从而不需要在所有的xml中更改。但是同时该库也存在以下问题：
扩展性较差。对于每一种ViewGroup都要对应编写对应的AutoLayout进行扩展，对于各View的每个需要适配的属性都要编写代码进行适配扩展;在onMeasure阶段进行数值计算。
消耗性能，并且这对于非LayoutParams中的属性存在较多不合理之处。比如在onMeasure时对TextView的textSize进行换算并setTextSize，那么在代码中动态设置的textSize都会失效，因为在每次onMesasure时都会重新被AutoLayout重新设置覆盖。
issue较多并且已不再维护。
2、Android的屏幕自适应实现原理
对于大小差异较大的屏幕，本不该使用同一套设计方案，否则大屏的优势没有完全体现出来，从官方的适配方案也似乎是表达了这个意思。但是在实际设计与开发中，对于一个普通的App，很少有项目有意愿有精力来对各屏幕来分别设计与开发一套设计方案来适配。
通常的一个简单的适配需求是：假如设计图宽度为200，一个控件在设计图上标注的长度为3，要么该控件长度相当于总宽度的3/200，要么希望在任何大小的屏幕上该控件所表现的长度都为屏幕宽度的3/200。
Android的AutoLayout设计思想非常优秀，但是将LayoutParams与属性作为切入口，在mesure过程中进行转换计算的方案存在效率与扩展性等方面的问题。那么Android计算长度的收口在哪里？能不能在Android计算长度时进行换算呢？如果能在Android计算长度时进行换算，那么就不需要一系列多余的计算以及适配，一切问题就都迎刃而解了。
经过研究，本文将长度计算的收口设为TypedValue中的applyDimension函数，传入单位与value值，将其计算为对应的px数值。代码如下：
1.public static float applyDimension（int unit，float value，
2.DisplayMetrics metrics）
3.{
4.switch（unit）{
5.case COMPLEX_UNIT_PX：
6.return value;
7.case COMPLEX_UNIT_DIP：
8.return value * metrics.density;
9.case COMPLEX_UNIT_SP： 10.return value * metrics.scaledDensity;
11.case COMPLEX_UNIT_PT：
12.return value * metrics.xdpi *（1.0f/72）;
13.case COMPLEX_UNIT_IN：
14.return value * metrics.xdpi;
15.case COMPLEX_UNIT_MM：
16.return value * metrics.xdpi *（1.0f/25.4f）;
17.}
18.return 0;
19.}
可以看见换算方法非常简单，而DisplayMetrics的所有属性都是public的，不用反射就能修改;pt的原意是长度单位磅，根据当前屏幕与设计图尺寸将metrics.xdpi进行修改就可以实现将pt这个单位重定义成我们所需要的相对长度单位，使修改之后计算出的1pt实际对应的px/屏幕宽度px=1px/设计图宽度px。mContext即为所在Activity;横竖屏切换等Configuration的变化会导致DisplayMetrics的重新计算还原;px，dp与sp都是平时常用的单位，而pt，in与mm几乎没有看见过，从这些不常见的单位下手正好可以不影响其他常用的单位。
基于以上几点，便有了以下方案。
3、Android的屏幕自适应实验结果及分析
本适配方案的目标是：完全按照设计图上标注的尺寸来编写页面，所编写的页面在所有大小与分辨率不同的屏幕上都表现一致，即控件在所有屏幕上相对于整个屏幕的相对大小都一致（看起来只是将设计图等比缩放至屏幕宽度大小）。
核心。使用冷门的pt作为长度单位，按照上述想法将其重定义为与屏幕大小相关的相对单位，不会对dp等常用单位的使用造成影响。
绘制。编写xml时完全对照设计稿上的尺寸来编写，只不过单位换为pt。假如设计图宽度为200，一个控件在设计图上标注的长度为3，只需要在初始化时定义宽度为200，绘制该控件时长度写为3pt，那么在任何大小的屏幕上该控件所表现的长度都为屏幕宽度的3/200。如果需要在代码中动态转换成px的话，使用TypedValue.applyDimension（TypedValue.COMPLEX_UNIT_PT，value，metrics）。
预览。实时预览时绘制页面是很重要的一个环节。以1334x750的设计图为例，为了实现于正常绘制时一样的预览功能，创建一个长为1334磅，宽为750磅的设备作为预览，经换算约为21.5英寸（（sqrt（1334^2+750^2））/72）。预览时选择这个设备即可。
代码处理。在activityonCreate时修改DisplayMetrics即可，推荐写在基类或ActivityLifecycleCallbacks中，参考github demo。
1.Point size = new Point（）;
2activity.getWindowManager（）.getDefaultDisplay（）.getSize（size）;
3.context.getResources（）.getDisplayMetrics（）.xdpi = size.x / designWidth * 72f;
这样绘制出来的页面就跟设计图几乎完全一样，无论大小屏上看起来就只是将设计图缩放之后的结果。
虽然本文的方案比较简单，但是为了方便使用也整理成了一个library，代碼及demo。
4、结论
本文使用冷门的pt作为长度单位，完全按照设计图上标注的尺寸来编写页面，所编写的页面在所有大小与分辨率的屏幕上都表现一致，即控件在所有屏幕上相对于整个屏幕的相对大小都一致（看起来只是将设计图等比缩放至屏幕宽度大小），实现了Android的屏幕自适应效果，在Android设备上的应用具有实用价值。
赛尔网络下一代互联网技术创新项目：NGII20160516
关键词：Android;屏幕;自适配策略
中图分类号：TP3 文献标识码：A
现状
由于Android设备种类繁多，屏幕尺寸差别较大，加之Android碎片化严重，屏幕适配一直是开发中较为头疼的问题。面对市面上五花八门的屏幕大小与分辨率，Android基于dp与res目录名称来适配的方案已无法满足一次编写全屏幕适配的需求，为了达到最优的视觉效果，开发过程中需要花费较多资源进行适配。
1、常见的解决方案----官方适配方案
1.1 dp方法
Dp（设备独立像素）是Android开发中特有的一个单位。与px（绝对像数）不同，dp是基于屏幕像素密度的一种单位。在密度低的屏幕上或许1dp=1px，但在密度高的屏幕上可能1dp=4px。编写布局xml时，如果一个控件的长宽都使用dp来指定，那么能确保该控件在各种大小与分辨率的屏幕下的绝对大小都大致相当。也就是说无论在pad下还是大小屏手机下，实际看到的该控件的大小是差不多的：
1.2 Ver方法
Ver（资源目录名）是最常见的屏幕布局方法，Ver目录用于存放Android应用程序使用到的所有资源，按照约定将不同的资源存放到不同的文件夹内。上图可见虽然使用dp确保了控件在不同屏幕中的绝对大小一致。这样的好处在于，在大小相近的屏幕中，无论分辨率多大都不会对布局造成影响;但是当屏幕大小相差较大时，仅保证控件的绝对大小看起来就有些问题了。在res目录下可以给各资源目录都加上例如“1920x1080”等后缀来适配不同的屏幕，具体规则可见官网文档。这样可以针对不同的屏幕提供不同的布局，甚至针对pad与手机提供两套完全不同的布局样式。但是通常情况下，设计师并不会对不同屏幕提供不同的设计图，他们的需求仅仅是不同屏幕下控件对屏幕的相对大小一致，所以dp并不能满足这一点，而对各种屏幕适配一遍又显得略为繁琐，并且修改也较为麻烦。通常需要的适配如下：
1.3 Px方法
Px（百分比布局支持庫）为deprecated推荐使用的布局，看起来似乎略复杂，但适配目的很明确，目的就是要确保控件在不同屏幕的相对大小一致，看起来一模一样的，归纳常用的适配方案：
方案一：编写脚本将长度转换成各分辨率下的长度，缺点是难以覆盖市面上的所有分辨率。
方案二：AutoLayout支持库。该库的想法非常好：对照设计图，使用px编写布局，不影响预览;绘制阶段将对应设计图的px数值计算转换为当前屏幕下适配的大小;为简化接入，inflate时自动将各Layout转换为对应的AutoLayout，从而不需要在所有的xml中更改。但是同时该库也存在以下问题：
扩展性较差。对于每一种ViewGroup都要对应编写对应的AutoLayout进行扩展，对于各View的每个需要适配的属性都要编写代码进行适配扩展;在onMeasure阶段进行数值计算。
消耗性能，并且这对于非LayoutParams中的属性存在较多不合理之处。比如在onMeasure时对TextView的textSize进行换算并setTextSize，那么在代码中动态设置的textSize都会失效，因为在每次onMesasure时都会重新被AutoLayout重新设置覆盖。
issue较多并且已不再维护。
2、Android的屏幕自适应实现原理
对于大小差异较大的屏幕，本不该使用同一套设计方案，否则大屏的优势没有完全体现出来，从官方的适配方案也似乎是表达了这个意思。但是在实际设计与开发中，对于一个普通的App，很少有项目有意愿有精力来对各屏幕来分别设计与开发一套设计方案来适配。
通常的一个简单的适配需求是：假如设计图宽度为200，一个控件在设计图上标注的长度为3，要么该控件长度相当于总宽度的3/200，要么希望在任何大小的屏幕上该控件所表现的长度都为屏幕宽度的3/200。
Android的AutoLayout设计思想非常优秀，但是将LayoutParams与属性作为切入口，在mesure过程中进行转换计算的方案存在效率与扩展性等方面的问题。那么Android计算长度的收口在哪里？能不能在Android计算长度时进行换算呢？如果能在Android计算长度时进行换算，那么就不需要一系列多余的计算以及适配，一切问题就都迎刃而解了。
经过研究，本文将长度计算的收口设为TypedValue中的applyDimension函数，传入单位与value值，将其计算为对应的px数值。代码如下：
1.public static float applyDimension（int unit，float value，
2.DisplayMetrics metrics）
3.{
4.switch（unit）{
5.case COMPLEX_UNIT_PX：
6.return value;
7.case COMPLEX_UNIT_DIP：
8.return value * metrics.density;
9.case COMPLEX_UNIT_SP： 10.return value * metrics.scaledDensity;
11.case COMPLEX_UNIT_PT：
12.return value * metrics.xdpi *（1.0f/72）;
13.case COMPLEX_UNIT_IN：
14.return value * metrics.xdpi;
15.case COMPLEX_UNIT_MM：
16.return value * metrics.xdpi *（1.0f/25.4f）;
17.}
18.return 0;
19.}
可以看见换算方法非常简单，而DisplayMetrics的所有属性都是public的，不用反射就能修改;pt的原意是长度单位磅，根据当前屏幕与设计图尺寸将metrics.xdpi进行修改就可以实现将pt这个单位重定义成我们所需要的相对长度单位，使修改之后计算出的1pt实际对应的px/屏幕宽度px=1px/设计图宽度px。mContext即为所在Activity;横竖屏切换等Configuration的变化会导致DisplayMetrics的重新计算还原;px，dp与sp都是平时常用的单位，而pt，in与mm几乎没有看见过，从这些不常见的单位下手正好可以不影响其他常用的单位。
基于以上几点，便有了以下方案。
3、Android的屏幕自适应实验结果及分析
本适配方案的目标是：完全按照设计图上标注的尺寸来编写页面，所编写的页面在所有大小与分辨率不同的屏幕上都表现一致，即控件在所有屏幕上相对于整个屏幕的相对大小都一致（看起来只是将设计图等比缩放至屏幕宽度大小）。
核心。使用冷门的pt作为长度单位，按照上述想法将其重定义为与屏幕大小相关的相对单位，不会对dp等常用单位的使用造成影响。
绘制。编写xml时完全对照设计稿上的尺寸来编写，只不过单位换为pt。假如设计图宽度为200，一个控件在设计图上标注的长度为3，只需要在初始化时定义宽度为200，绘制该控件时长度写为3pt，那么在任何大小的屏幕上该控件所表现的长度都为屏幕宽度的3/200。如果需要在代码中动态转换成px的话，使用TypedValue.applyDimension（TypedValue.COMPLEX_UNIT_PT，value，metrics）。
预览。实时预览时绘制页面是很重要的一个环节。以1334x750的设计图为例，为了实现于正常绘制时一样的预览功能，创建一个长为1334磅，宽为750磅的设备作为预览，经换算约为21.5英寸（（sqrt（1334^2+750^2））/72）。预览时选择这个设备即可。
代码处理。在activityonCreate时修改DisplayMetrics即可，推荐写在基类或ActivityLifecycleCallbacks中，参考github demo。
1.Point size = new Point（）;
2activity.getWindowManager（）.getDefaultDisplay（）.getSize（size）;
3.context.getResources（）.getDisplayMetrics（）.xdpi = size.x / designWidth * 72f;
这样绘制出来的页面就跟设计图几乎完全一样，无论大小屏上看起来就只是将设计图缩放之后的结果。
虽然本文的方案比较简单，但是为了方便使用也整理成了一个library，代碼及demo。
4、结论
本文使用冷门的pt作为长度单位，完全按照设计图上标注的尺寸来编写页面，所编写的页面在所有大小与分辨率的屏幕上都表现一致，即控件在所有屏幕上相对于整个屏幕的相对大小都一致（看起来只是将设计图等比缩放至屏幕宽度大小），实现了Android的屏幕自适应效果，在Android设备上的应用具有实用价值。
赛尔网络下一代互联网技术创新项目：NGII20160516