移动端适配方案研究

初次接触移动端的时候,以为终于可以不用像pc那样考虑令人头疼的ie浏览器兼容问题,有强大的css3的帮助,可以随心所欲。。可是后来才发现原来移动端各种层次不齐的终端更会让人抓耳挠腮,同样的页面在不同的手机上显示的完全不一样的效果,于是抛开功能,页面适配性也成了一个大的课题。

说到移动端,下面这一行代码大家一定不陌生:

    <meta name="viewport"   content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">

如果对viewport还有不理解的可以直接去百度有很多资料,其中,device-width指设备的物理宽度,比如iphone4为320,剩下的initial-scale与maximum-scale指页面缩放值及最大缩放值,user-scalable表示是否允许缩放。

注意device-width并不等于手机的物理像素,同样宽度的屏幕物理像素可能为320,640,这就是我们常说的retina屏。当然也就意味着我们css中的1px可能是1个物理像素,也可能是2个物理像素,当然就显示来说我们设置1px的border不管是在哪个屏幕下看起来都是显示1px的。

移动端适配的解决方案大概有几种,现就我所了解的主要方法做个简单总结:

一.媒体查询

    相信对响应式网站了解的同学都看过下面的写法:

@media screen and (max-width: 300px){

….

}

通过css3的媒体查询,我们可以对不同的分辨率设定不同的样式,如320px(device-width)下字号14px,而375px字号设为16px,等等。

这样我们就可以做到简单的适配,不过现在市场机型320,360,375等等各种分辨率,如果我们每一个都去U针对的话,代码量抛开不说,各种计算也会使得效率极其低下。

二.动态改变缩放值

    我们之前的大神是通过下面这种方法来实现不同设备的自适应的,例如我们的设计稿为640px为标准的,那么我们写页面的时候可以按实际ps中的px来写,然后再页面开头加入如下js(这种方法与淘宝和网易的做法有异曲同工之妙,下面我们会介绍到):

 1 var sW=$(window).width();
 2
 3 if(sW>=640&&sW<720){
 4
 5        $("#screeMeta").attr("content","width=640, initial-scale=1,minimum-scale=0.5, maximum-scale=0.5");
 6
 7 }else if(sW>=720&&sW<750){
 8
 9        $("#screeMeta").attr("content","width=640, initial-scale=1,minimum-scale=0.5, maximum-scale=0.56");
10
11 }else if((sW>=750&&sW<800)){
12
13       $("#screeMeta").attr("content","width=640, initial-scale=1,minimum-scale=0.5, maximum-scale=0.58");
14
15 }else if(sW>=800&&sW<1000){
16
17      $("#screeMeta").attr("content","width=640, initial-scale=1,minimum-scale=0.5, maximum-scale=0.65");
18
19 }

基本思想为以640为基准,当在标准iphone4的时候页面整体缩放0.5,然后再遇到不同分辨率的时候赋予不同的缩放值,例如对于device-width为375的情况下,最大缩放值设为375/320*0.5。

这种方法的优点是我们可以完全按照设计稿来设定css尺寸,通过js的计算来实现不同机型的适配。当然缺点就是你当我们嵌入第三方页面或者将我们的页面嵌入第三方时,由于缩放值的不同会出现兼容性问题。

     三.rem自适应

    我们都知道rem不同于em相对于父元素的字体,rem是相对于html根字体来设置的,也就是假设html字体设为16px,那么设置为1rem的元素不论父级元素是哪一层都相当于设置了字体font-size:16px,我们来看一看淘宝和网易的页面:

iphone4:font-size设为64px,缩放值为0.5

iphone6:font-size设为75px,缩放值为0.5

我们再来看下元素设置:

除字体外,其他单位都用rem,这样通过动态的计算html的px,页面内容也会做相应比例的变化,字体用px显示。当然,他们的理念是大屏就要显示更多的字体。

关于字体有一个疑问始终没有搞明白,看下面几个图:

data-dpr=1,安卓机,字体设为12px,缩放值为1

data-dpr=2,iphone6,字体设为24px,缩放值为0.5

data-dpr=3,iphone6 plus,字体设为36px,缩放值为0.333

看上面3个截图,可以看到,通过不同的dpr,为html赋予了不同的data-dpr属性,然后根据不同的屏幕设置字体属性和缩放倍数,如1倍屏12px,缩放为1,2倍屏缩放为0.5,3倍屏缩放为0.3333,不清楚这样做的目的是什么,貌似缩放乘以倍数是一样的效果,也就是可以用一种设置来实现,不知道理解的是不是有问题?忘大神告知。

关于淘宝h5兼容,这里有详细的介绍。使用Flexible实现手淘H5页面的终端适配

下面来看下网易的适配:

安卓1倍屏,device-width为384,html字体设置为51.2

iphone2倍屏,device-width为320,html字体设置为42

iphone3倍屏,device-width为414,html字体设置为55px

网易的缩放值始终为1,而且所有属性包括字号都是用rem来设置,不同于淘宝,网易客户端在各种终端显示内容始终是一致的,这和我们上面讲过的动态改变缩放值是一样的。选定一种宽度为标准,然后其他机型的设置即为标准机型*比例值。

至少就个人来说,我更喜欢网易的这种适配方案,这样可以保证我的页面在每个机型上都是一样的效果。

通过分析上面的几种方法,我们可以简单写一个方法,当然下面方法还没有经过大量测试,只讲方法,慎用

 1 function autoSize(width){
 2
 3   //如果我们设计稿为750,则传入750,否则都认为是640
 4     var width=width?width:640;
 5
 6      //为了便于计算,在参照宽度下设html字号为100px,
 7
 8     var units=width/100;
 9     var width=document.documentElement.clientWidth;
10     width=width>1080?1080:width;   //设定最大值
11     width=width<=240?240:width;   //设定最小值
12     var calFontSize=width/units;   //计算html字体的字号
13     console.log(units+‘--‘+width+‘---‘+calFontSize)
14     document.documentElement.style.fontSize=calFontSize+‘px‘;
15 }
16 autoSize();
17 window.onresize=function(){
18     autoSize()
19 }
时间: 04-16

移动端适配方案研究的相关文章

移动端适配方案以及rem和px之间的转换

背景 开发移动端H5页面 面对不同分辨率的手机 面对不同屏幕尺寸的手机 视觉稿 在前端开发之前,视觉MM会给我们一个psd文件,称之为视觉稿. 对于移动端开发而言,为了做到页面高清的效果,视觉稿的规范往往会遵循以下两点: 1)首先,选取一款手机的屏幕宽高作为基准(以前是iPhone4的320×480,现在更多的是iphone6的375×667). 2)对于retina屏幕(如: dpr=2),为了达到高清效果,视觉稿的画布大小会是基准的2倍,也就是说像素点个数是原来的4倍(对iphone6而言:

前端编程提高之旅(十八)----移动端web流行交互技术方案研究

   在停止实习后,生活最大变化在于没有项目的压力,可以根据兴趣场景,探索技术实现.这个过程对于个人来说,动力自内而外,需求自上而下,都由个人把握.    生活在移动互联网井喷的今天,同时又关注前端技术,平常对微信端流行的交互(或者说玩法)有着特殊的敏感性.如果说之前接触MVC框架还是对单页面网站.CSS3前沿特效有一个概念的话,微信朋友圈及好友分享网页,则把国内网页构建的流行趋势,从幕后推向前台.    乐帝通过研究移动端web流行交互,构建起了一个初步可行的技术方案,用来实现单页面与DOM动

移动端高清、多屏适配方案

移动端高清.多屏适配方案 背景 开发移动端H5页面 面对不同分辨率的手机 面对不同屏幕尺寸的手机 视觉稿 在前端开发之前,视觉MM会给我们一个psd文件,称之为视觉稿. 对于移动端开发而言,为了做到页面高清的效果,视觉稿的规范往往会遵循以下两点: 首先,选取一款手机的屏幕宽高作为基准(以前是iphone4的320×480,现在更多的是iphone6的375×667). 对于retina屏幕(如: dpr=2),为了达到高清效果,视觉稿的画布大小会是基准的2倍,也就是说像素点个数是原来的4倍(对i

移动端适配知识梳理

了解移动端的知识 viewportviewport是用户网页的可视区域.手机浏览器是把页面放在一个虚拟的"窗口"(viewport)中,通常这个虚拟的"窗口"(viewport)比屏幕宽,这样就不用把每个网页挤到很小的窗口中(这样会破坏没有针对手机浏览器优化的网页的布局),用户可以通过平移和缩放来看网页的不同部分. 像素css中的像素只是一个抽象的单位,早期的手机屏幕像素密度较低,一个css像素等于一个物理像素.但是随着手机的屏幕像素密度越来越高,比如Retina,

移动端适配之雪碧图(sprite)背景图片定位

为了减少网络请求个数量,提高网站的访问速度,我们一般都会把一些小的图片合并成一张sprite图,然后根据background-position来进行定位.在web端由于是固定的大小与left .top,所以定位起来会比较准确.简单.但是在移动端就不一样了,各种手机的屏幕大小不一样,很难做到使用sprite图然后根据background-position来定位.所以普遍的做法都是使用单张图片,然后使用background-size: cover|100%|contain来控制背景图的大小.其实这样

H5常用代码:适配方案3

在H5项目中有一种常见的宣传页,就是那种整屏整屏的,带着炫丽进场动画的移动宣传页,不仅是一种欣赏也起到了很大宣传作用. 对于这种整屏的适配,前面通过视口的兼容处理也是可以做到的,但是在窄屏下会在上下有明显的切割,于是想到既然是保证内容在整屏,那是不是只要保证高度在整屏内就完美了,不管屏幕怎么小整个高度被填在屏幕内,于是就有了这一种适配方案: 代码如下: <!DOCTYPE html> <html> <head> <title>主结构&适配方案3<

Unity+NGUI多分辨率适配方案

说起unity的适配方案,网上可谓是一查一大堆,但是真正要应用到项目中的时候,总会出现各式各样的问题.由于最近自己要做一个小游戏,在开始做游戏之前,就想着先好好搞一搞适配这块,以后新起项目的时候也会用得着. NGUI应该是现在大部分开发者都会去选择的UI插件,虽然NGUI还存在着不少问题,像是相对来说,NGUI还是比较靠谱的,所以这里只是针对NGUI做适配方案. NGUI中对于每一个场景,都是以UIRoot为GameObject树的根的,UIRoot下面主要有这几种属性 1) Scaling S

web屏幕适配方案

一个多月前水了一篇移动web屏幕适配方案,当时噼里啪啦的写了一通,自我感觉甚是良好.不过最近又有一些新的想法,和之前的有一些不同. 先说一下淘宝的方案,感觉现在好多的适配方案都是受了它的影响,上周六看了winter在一个会议的分享,讲到了这个方案.现在你谷歌一下移动 web适配,绝对可以看到很多类似的,切活动页的童鞋都忍不住试一把.这些方案和我的博客写的其实还是相似的,就是抛弃了那种viewport直接缩放, 然后给定html的初始font-size值,使用rem这个单位. 在屏幕的设备像素比上

JavaScript强化教程 —— Cocos2d-JS的屏幕适配方案

1. 设置屏幕适配策略(Resolution Policy) 如果你还没有用过Resolution Policy,只需要在游戏载入过程完成之后(cc.game.onStart函数回调中),调用下面的代码: cc.view.setDesignResolutionSize(320, 480, cc.ResolutionPolicy.SHOW_ALL); setDesignResolutionSize函数的前两个参数是你想要在你的代码中使用的游戏分辨率,第三个参数就是你选择的适配方案.引擎中内置了5种