做移动端页面以来,经常会听说移动端的适配这个问题,但是并没有认真分析过是如何适配各种机型的。目前公司用的是手淘的flexible.js进行页面适配的。适配的根本原理其实就是将设计稿按一定的比例在不同的手机上实现。
在分析移动段适配之前首先要了解一下rem, css3的一个相对长度单位。既然是相对长度,那就有一个参照体了,rem就是相对于html元素的font-size计算值的倍数。即1rem 等于一倍的html元素的font-size值。
最早看到这个适配是在同事的代码里,当时并不知到是什么原理,也并不明白这些数字是怎么来的。
@media screen and (min-width:350px){
html{font-size:342%;}
}
@media screen and (min-width:360px){
html{font-size:351.56%;}
}
@media screen and (min-width:375px){
html{font-size:366.2%;}
}
@media screen and (min-width:384px){
html{font-size:375%;}
}
@media screen and (min-width:390px){
html{font-size:380.85%;}
}
@media screen and (min-width:393px){ /* 小米NOTE */
html{font-size:383.79%;}
}
@media screen and (min-width:410px){
html{font-size:400%;}
}
@media screen and (min-width:432px){ /* 魅族3 */
html{font-size:421.875%;}
}
@media screen and (min-width:480px){
html{font-size:469%;}
}
@media screen and (min-width:540px){
html{font-size:527.34%;}
}
@media screen and (min-width:640px){
html{font-size: 625%;}
}
@media screen and (width:720px){
html{font-size: 703.125%;}
}
@media
媒体查询, 可以针对不同的屏幕尺寸设置不同的样式,特别是如果你需要设置设计响应式的页面,@media 是非常有用的。当你重置浏览器大小的过程中,页面也会根据浏览器的宽度和高度重新渲染页面。
上述代码中,第一个@media screen and (min-width:350px)表示当移动设备的宽度大于350px的时候页面将使用花括号内的样式,即将html根元素的字号设置为342%。(max-width:350px,则表示设备宽度小于350px时将采用此样式)。上述css代码的作用可见就是在不同分辨率的设备上设置不同的html字体大小。
为什么要这样设置呢?因为这种适配方法用的是css3的rem来进行适配的,而前面讲了,rem是相对于html的字号来计算的,现在不同的设备上html的字号改变了,也就意味这1rem代表的px像素值不同了,也就达到了按比例在不同设备上适配同一个页面的效果了。
html元素的font-size值又是怎么确定的呢?拿下面的举例:
@media screen and (min-width:375px){
html{font-size:366.2%;}
}
屏幕宽度大于375px的会按照宽度375px来适配。设计同时平时给我们的设计稿一般是640px宽度或者750px宽度的,而我们上面的都是假定设计稿是640px宽来计算的,750px也是同理计算。现在:
1.屏幕宽度是375,设计稿宽度是640,ratio = 375/640=0.5859375;
2.我们要将设计稿上元素用css单位rem写下来,那么该如何转换,1rem应该等于稿子上多少px。
这里我们设定1rem = 100px ;可以设定其它值吗,当然可以,这里设置为100只是方便我们在写css的时候好计算,小数点直接左移两位就可以了。比如,设计稿上一个宽46px按钮,这样转换成rem直接就是0.46rem。
3.现在1rem代表设计稿上100px,那么又该是等于设备上最后真实的多少像素呢。就要用到前面的屏幕宽度和设计稿的宽度比 ratio,设计稿上100px代表了真实的设备100*ratio = 58.59375px。
换句话说 css中写的1rem等于设备58.59375px。又因为1rem等于1倍的html元素的font-size,所以这里的html元素的font-size最终应该设置成58.59375px。可为什么上述代码中用的是百分比呢?因为一般浏览器中html元素的默认字号都是16px,但是当用户放大或者缩小浏览器字号设置时,就不会是16px了,所以我们将html的font-size还是设置成百分比更好,即 58.59375/16= 366.2109375%,也就是上面例子中的366.2%了。
其它的屏幕上也是同此道理计算出html的font-size值的。
@media + rem适配移动端还有一个不可少的条件就是要在head标签中写入一个meta标签。 <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1, minimum-scale=1">;关于viewport的了解可以看这里。此标签的作用是让layout viewport = visual viewport,用户也不可缩放页面。
flexible.js也是rem适配的,它是将设备分成10份,1rem等于1/10。分析其中部分代码:
var devicePixelRatio = win.devicePixelRatio;
dpr = devicePixelRatio || 1;
if (isIPhone) {
// iOS下,对于2和3的屏,用2倍的方案,其余的用1倍方案
if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {
dpr = 3;
} else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){
dpr = 2;
} else {
dpr = 1;
}
} else {
// 其他设备下,仍旧使用1倍的方案
dpr = 1;
}
scale = 1 / dpr;
......
.......
metaEl.setAttribute('content', 'initial-scale=' + scale + ', maximum-scale=' + scale + ', minimum-scale=' + scale + ', user-scalable=no');
win.devicePixelRatio(简称dpr),即设备像素比(戳我了解)
上述代码当dpr(设备物理像素和设备独立像素比)为3时候,页面缩入1/3,dpr为2时,页面绽放2/1。
function refreshRem(){
var width = docEl.getBoundingClientRect().width;
if (width / dpr > 750) {
width = 750 * dpr;
}
var rem = width / 10;
docEl.style.fontSize = rem + 'px';
flexible.rem = win.rem = rem;
}
上述代码将1rem设置成了设备真实宽度的1/10,因此html根元素的fontSize也就是设备真实宽度的1/10,假如设计老铁们给的漂亮稿子是750px宽的,写scss时1rem也就应该等于75px,那边我么的scss文件可以这样写:
@function px2rem($px, $base: 75) {
@return ($px / $base) * 1rem;
}
/*
稿子上量得某按钮宽60px,高20px
*/
.btn{
width:px2rem(60);
height:px2rem(20);
}
vw:viewport width(可视窗口宽度)
vh:viewport height(可视窗口高度)
vw和vh等详情可以点这里
1vw等于1%的设备宽度(设计稿宽度),1vh等于1%的设备高度(设计稿高度),这样看来vw,vh其它是最方便的,但是目前兼容性不是特别好。
所以只有在不需要考虑兼容的时候可以用这个相对最简便的适配方案了,比如一些混合开发里,app内的浏览器如果支持vw、vh,只在app内使用的页面就可以放心大胆的用了。像下面的
客户端内的右下角webview,一个小的PK对决页面,这里就是用的vw,vh进行适配的。
/*右下角窗口设计稿宽200px,高220px*/
@function px2vw($px, $base: 200) {
@return ($px/($base/100)) + vw;
}
@function px2vh($px, $base: 220) {
@return ($px/($base/100)) + vh;
}
/*头像宽42px,高42px*/
.avantar{
width:px2vw(42);
heightx:px2vh(42);
}
目前工作中用到的就是后面的两种适配方案了。手淘那个还有的地方看不懂,还是自己太Low了,但是看不懂车不影响老司机开车。
来自:https://segmentfault.com/a/1190000019677612
有些机型有些app不能横屏:比如Android的微信就没有横屏模式,而ios的微信能开启横屏模式。解决办法就是在竖屏模式下,写一个横屏的div,然后设置rotate正(负)90度,把他旋转过来;而且如果用户切到横屏时,需要把rotate复原,要求也能正常展现。
在做移动端时间转化为时间戳时,遇到了一个问题,安卓手机上访问时,能拿到时间戳,从而正确转换时间,而在iOS上缺不能正常显示,显示的时间为:NaN-NaN-NaN ,例如getTime()在ios上拿不到时间戳显示NaN
因为对于一枚前端而言,天天和页面打交道(H5页面),那么布局的活总是少不了,这也将面临不同终端的适配问题。不知道你是否和我一样,页面布局总是或多或少会有一些蛋疼的事情发生。
移动端点透现象的解决办法:解决方案一:来得很直接github上有个fastclick可以完美解决;解决方案二:用touchend代替tap事件并阻止掉时A元素touchend的默认行为preventDefault(),从而阻止click事件的产生;解决方案三:延迟一定的时间(300ms+)来处理事件...
这篇文章主要总结移动端页面开发时需要注意的一些问题。比如:防止手机中网页放大和缩小、format-detection设置、上下拉动滚动条时卡顿慢 、禁止复制选中文本...
由于微信webvie内置了调整字体大小的功能,如果用户调整了这一设置,就会导致了网页中的字体比原本的尺寸偏大或偏小,使得网页可能出现排版错乱,或者字体太小看不清的情况发生
在移动端部分浏览器中点击了图片,变成了查看图片的效果,怎么防止img的图片被手机浏览器的图片查看器打开呢?下面整理了一些方法来实现:在img元素上添加 onclick=return false、背景图的方式插入、使用js事件阻止默认行为的方式
移动端浏览器在派发点击事件的时候,通常会出现300ms左右的延迟。也就是说,当我们点击页面的时候移动端浏览器并不是立即作出反应,而是会等上一小会儿才会出现点击的效果。
在 PC 端,视口指的是浏览器的可视区域,其宽度和浏览器窗口的宽度保持一致。在 CSS 标准文档中,视口也被称为初始包含块,它是所有 CSS 百分比宽度推算的根源,给 CSS 布局限制了一个最大宽度。而移动端则较为复杂,它涉及到三个视口:布局视口(Layout Viewport)、视觉视口(Visual Viewport)和理想视口(Ideal Viewport)
随着技术的飞速发展,当前lib-flexible适配方案也在逐渐被更新的适配方案所替代,但是截止目前为止,还没有发现哪种方案能完全满足适配各种机型的需要,也会有一些小的问题。lib-flexible是目前用到的比较成熟的适配方案
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!