一、近况
因为Android碎片化严重，屏幕适配一向是开辟中较为头疼的问题。面对市情上八门五花的屏幕大年夜小与分辨率，Android基于dp与res目次名称来适配的筹划已无法知足一次编写全屏幕适配的需求，为了达到最优的视觉效不雅，开辟过程中老是须要花费较多资本进行适配。也有开辟者给出了一些本身的解决筹划。起首来分析一下一些常见的解决筹划的近况： 1. 官方适配筹划 – dp。dp是Android开辟中特有的一个单位。与px不合，dp是基于屏幕像素密度的一种单位。在密度低的屏幕上或许1dp=1px，但在密度高的屏幕上可能1dp=4px。编写构造xml时，如不雅一个控件的长宽都应用dp来指定，那么能确保该控件在各类大年夜小与分辨率的屏幕下的绝对大年夜小都大年夜致相当。也就是说无论在pad下照样大年夜小屏手机下，我们实际看到的该控件的大年夜小是差不多的：
- 代码处理。代码处理有两种筹划：如不雅所有页面的设计图尺寸都一样，则在Applicalition中的onCreate中与onConfigurationChanged中处理即可;如不雅每个页面的设计图尺寸不一样，则须要在每个activity的onCreate中处理(Activity中不须要处理onConfigurationChanged，因为设备变更页面会从新生成)。
- 全局处理筹划。在Application的onCreate中与onConfigurationChanged中更改DisplayMetrics(个中DESIGN_WIDTH是绘制页面时参照的设计图宽度)：
- 资本目次名。上图可见固然应用dp确保了控件在不合屏幕中的绝对大年夜小一致。如许的好处在于，在大年夜小邻近的屏幕中，无论分辨率多大年夜都不会对结构造成影响;然则当屏幕大年夜小相差较大年夜时，仅包管控件的绝对大年夜小看起来就有些问题了。在res目次下可以给各资本目次都加上例如’-1920×1080′等后缀来适配不合的屏幕，具体规矩可见官网文档。如许可以针对不合的屏幕供给不合的构造，甚至针对pad与手机供给两套完全不合的构造样式。然则平日情况下，设计师并不会对不合屏幕供给不合的设计图，他们的需求仅仅是不合屏幕下控件对屏幕的相对大年夜小一致，所以dp并不克不及知足这一点，而对各类屏幕适配一遍又显得略为繁琐，并且修改也较为麻烦。平日我们须要的适配是如许的：
- 计整洁。编写脚本将长度转换成各分辨率下的长度，缺点是难以覆盖市情上的所有分辨率。
- 百分比构造支撑库。没有应用过，然则deprecated in API level 26.0.0-beta1。
- ConstraintLayout。百分比支撑库deprecated之后推荐应用的构造，看起来似乎略复杂。 2. 玩家适配筹划。广大年夜玩家的适配目标很明白，目标就是要确保控件在不合屏幕的相对大年夜小一致，看起来一毛一样的。以一位大年夜神玩家的两种适配筹划为例：
- 筹划二。AutoLayout支撑库。该库的设法主意异常好：对比设计图，应用px编写构造，不影响预览;绘制阶段将对应设计图的px数值计算转换为当前屏幕下适配的大年夜小;为简化接入，inflate时主动将各Layout转换为对应的AutoLayout，大年夜而不须要在所有的xml中更改。然则同时该库也存在以劣等问题：
- 扩大性较差。对于每一种ViewGroup都要对应编写对应的AutoLayout进行扩大，对于各View的每个须要适配的属性都要编写代码进行适配扩大; – 在onMeasure阶段进行数值计算。这对于非LayoutParams中的属性存在较多不合理之处。比如在onMeasure时对TextView的textSize进行换算并setTextSize，那么玩家在代码中动态设置的textSize都邑掉效，因为在每次onMesasure时都邑从新被AutoLayout从新设置覆盖。 – issue较多并且作者已不再保护。
二、设法主意
小我认为AutoLayout的设计思惟异常优良，然则将LayoutParams与属性作为切人口在mesure过程中进行转换计算的筹划存在效力邮攀扩大性等方面的问题。那么Android计算长度的收口在哪里，能不克不及在Android计算长度时进行换算呢?如不雅能在Android计算长度时进行换算，那么就不须要一系列多余的计算以及适配，一切问题就都水到渠成了。 经由一番寻觅，发明体系进行长度计算的收口为TypedValue中的applyDimension函数，传入单位与value将其计算为对应的px数值。
网友点评
精彩导读
科技快报
品牌展示