Rumah > Artikel > hujung hadapan web > 构建自适应的手机页面_html/css_WEB-ITnose
从事PC Web开发好多年,但是手机页面开发较晚,所以最开始的时候,为了做微信应用的开发,各种饿补,但是为了将设计稿精准的适配在各种尺寸的手机上还是太坑,所以找了些资料后,借鉴了一些成熟的网站,自己整合了一个简便的方法,分享出来,欢迎拍砖。
首先需要你对viewport有一个了解,建议看Apple官方文档,虽然?嗦,但是啃一遍,基本该明白的就全明白了。
第一种方案html<meta name="viewport" content="target-densitydpi=device-dpi,width=640,user-scalable=no" />
简便易行,适用情况:1. 网页设计仅针对手机屏幕,并且没有需要根据手机屏幕尺寸进行UI调整的内容,既没有媒体查询的CSS2. 产品层面可以不考虑非主流设备或浏览器的兼容性,例如黑莓的某些设备或搜狗浏览器这类的不支持640定宽渲染的浏览器3. 当手机横竖切换时,能够容忍部分手机在横屏浏览网页时,可能出现的问题(潜在问题)。
这个方案是强制让手机浏览器按640的比例来呈现网页,让浏览器去做尺寸适配;这个方案我觉得其实非常好,绝大多数的场景都可以支持,而且开发起来简单高效,不需要考虑各种尺寸和样式表的单位换算问题。
测试地址:点击这里,这个网页就是按640定宽做的,可以在多数尺寸的网页上做适配
第二种方案html<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no" />
上面这个不用解释了,绝大多数知名网站都这么做的,但是为了能够让图片和字体去做自适应,通常的做法是使用rem来作为单位,然后再启用javascript判定屏幕宽度,动态改变html元素的fontsize。
为了方便计算,通常会默认将html的font-size设置为100px,这样方便计算,例如你的网页字体是16px,只需要写成0.16rem就行了,然后假如设计稿是按640宽度设计,切图的时候完全按设计稿来进行单位换算,然后在js中获取屏幕宽度,根据比例:100/x = 640/documentWidth 计算html的字体大小即可,当然要加入一个window.resize事件重新计算,以防横竖屏切换。
第二种方案有几个弊端: 1. 由于背景图片无法做缩放,(background-size:cover|contain)只能针对单张图片,而对于sprite css image无力解决,所以这里要求如果有背景图,全部制作成单张的,然后再加上background-size:cover|contain,这里凸显出使用css font的好处了... 2. 页面中的所有单位都需要用rem来计算,虽然 X/100是很简单的计算,但是书写的时候还是让人厌烦。 3.如果有图片必须指定宽度,不然图片会按原始宽度进行渲染,当屏幕尺寸与设计预期尺寸不一致时,就会出错了。
根据上面的描述,我做了两个工具:
1.制作时依然采用px作为单位,通过watch插件监听css文件的改变,然后动态转换px2rem。
2.根据图片生成auto convert css icon文件,类似grunt-sprite,但只生成对应的css,而不合成图片,这样对于将以往的css sprite工具生成的图片可以低成本切换成单一图片ICON
开发思路是这样:
1.开发时区分目录,例如src表示源码,dest目录标示转换后的静态文件,目前上规模的工程都这么做,应该没什么成本了,然后css依然使用像素作为单位。
2.通过grunt或gulp插件来监听文件改变,然后做copy,sync之类的处理,同时这里将css中的px按设定的比率转换成rem。
3.不能在网页中直接嵌入内联style,或者需要自行转换单位之后嵌入。
监听脚本:
(注:这里假定开发的时候依据的宽度的640,默认字体是32像素)
javascript// 根据屏幕宽度适配字体大小$(window).on('resize', function () { var width = document.documentElement.clientWidth; $('html').css('font-size', (width / 640 * 32) + 'px');}).triggerHandler('resize');
测试地址:点击这里
(因为我的工程使用的是grunt,所以写的插件也是针对grunt的,如果你打算使用gulp,需要自行实现上面的工具了)
总结第一个定宽开发的方案其实非常适合小团队做推广页面,因为这样避免了各种工具的整合,降低了开发复杂度。
第二个方案适合需要适应绝大多数尺寸浏览器的项目,同时如果配置好打包工具,可以很大程度降低难度,将开发和部署解耦,开发代码比较清晰。