提交需求
赛事与广告咨询合作,请填写需求表单,我们会在第一时间与您联系!
h5内嵌原生,移动端到pad,不同尺寸的适配
做适配就是为了一套设计稿,在不同的尺寸的屏幕下,保证一致性,保证屏效,保证内容不被裁减。
通常这种问题在常规的移动端竖屏显示下,在不涉及不同语言的开发下问题不是特别明显,但是一旦设计到h5嵌套原生,或者一稿适配到pad,或者横屏的情况下,就会出现严重的混乱,原因是开发会按照自己的理解去做布局,思路不够统一,原生习惯写固定的边距,h5端这边如果不做特殊处理,即使一样写边距也会自动转化为屏幕的百分比,这种情况在设备屏幕尺寸与设计图(我这里是常规的2倍图尺寸,750px 1334px)等比例的情况下当然是没有问提的,一旦涉及到不等比例,尤其是长屏手机,或者pad问题就会很明显了。
所以我自己的思路是,常规尺寸的一屏显示的内容,要保证在不同设备下起码能够展示完整,如果是一张图片就是保证在不同设备下不能被裁减(当然比如启动页,如果是带背景,我会把内容和背景拆分成两个图层,保证内容区域不受影响或者裁减)。
按照这个思路,首先是正常750px 1334px设计稿适配到pad(1536px 2048px),如果是竖屏的情况下,web开发如果不说明,会按照2倍图(750px 1334px )宽度的百分比去写,导致到了pad端实际上是等比缩放了2倍,但是pad的高度其实是不足6的两倍(2048px/1334px = 1.5左右),这种情况会导致h5嵌套原生界面是,在切换时,相同的元素、控件就会变得傻大傻大的,严重影响一致性(同于横屏幕下的6与x)。
所以解决办法是统一板式布局和适配方式,也不用转换单位,移动端,web前端一样,都可以拿到设备的机型(屏幕宽度高度的实际像素值),为了统一方便理解以竖屏幕为例:
页面适配元素以2倍图的实际像素值去写,包括布局方式仍不变(卡片累的容器,屏幕宽度-边距(不是写死的,如果是图片,原图有宽高比,乘以宽高比,如果不是图片,内容撑开)),然后在乘一个系数(这里取名为e吧),然后置于这个系数取多少,就看屏幕的宽高比(宽取名w,高取名h),当 w/h 大于等于 750px/1334px ,e=h/1334px,当w/h小于750px/1334px,e=w/750px,(边距,字号,间距等都✖️以这系数,拉伸区域不用管,自行填充)。
个人工作中遇到问题,解决办法,经验总结,希望对大家有所帮助。
Powered by Froala Editor
大牛,别默默的看了,快登录帮我点评一下吧!:)
登录 立即注册