但是对于线上APP,我们要更改成这种方式适配的,要更改所有的代码,回归测试所有场景的case布局样式,这种全量的修改回归的适配方式,简直会让业务开发和测试崩溃。
那有什么好的办法处理这个呢?
那么我们先看下现有的UI设计师和DP适配的时
开发者是怎么处理设计稿还原到屏幕的?
有的设计师们的会针对Android出1080的稿子,因为Android的主流屏幕分辨率还是在1080X1920,Android开发人员对1080的稿子做px到dp的换算,通常是除3取整或1取小数点后一位。
但是这个我们在上一篇 https://blog.csdn.net/Zhouxiaomeng0209/article/details/79959975 已经做了具体的分析,这种其实是不准确的,因为1080的density其实大部分都不是3.
那么我们怎么得到一个缩放因子,可以按照屏幕百分比呢?
基于目前针对的app是纵向布局的前提(本篇文章只从纵向布局视角分析)我们取 scale = 屏幕宽度/设计稿的宽度 做缩放因子,后面都简称scale。
这样设计稿给出的size就是开发人员布局的时候要写到代码中的size,无需再做转换。
有了scale,我们的问题就回到开始的时候就是适配线上APP的成本,
怎么能减少这个成本?
这个成本从两方面来看:
1. 适配方案的开发成本。
2. 各个业务回归修改的成本。
显然,第二的成本是量级的,现在任何一个线上APP去挨个业务回归修改一遍的成本都是非常巨大的。
所以减少业务修改回归成本就是减少成本的。
那我们看下以下几种方案:
方案一:替换系统单位pt
github上发现一个适配适配方式:https://github.com/Firedamp/Rudeness 替换体统单位,方案表面上看起来有些“粗暴”,其实也是一种捷径。
简单梳理下这种方案:例如:12pt = 12 * xdpi * 1/72 = ?px
Hook掉xdpi (The exact physical pixels per inch of the screen in the X dimension) ,将其变成screenWidth(pixels)/designWidth(pixels)*72,从而达到通过屏幕横向分辨率/设计稿横向分辨率=缩放因子的效果。
12pt = 12 * screenWidth(pixels)/designWidth(pixels)*72 * 1/72 = 12 * screenWidth(pixels)/designWidth(pixels)
看是很完美的解决方案,那么这种方案存在的风险是什么呢?
1. 代码中无法正常使用xdpi,pt,mm,inch。2. 开发人员对于系统单位的新的换算的认知成本。
风险可控的情况下,这个方案的成本是最小的。
可能有朋友会问,为什么hook掉这个xdpi就可以做到全局适配呢?
1. xml文件中设置12pt。
2. 代码动态设置。
1. TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_PT, value, metrics)
不用说了,直接归约到了TypedValue.applyDimension。
2. context.getResources().getDimensionPixelSize(R.dimen.image_width_pt).
调用栈如下,规约到TypedValue.applyDimension。
3. setTextSize(TypedValue.COMPLEX_UNIT_PT,size).
方案二:直接替换系统单位dp
下一篇:Android屏幕适配 - 百分比(二)