移动端web开发基础

1.移动端常用单位

  • 像素(Pixel)
    在前端开发中视口的水平方向和垂直方向是由很多小方格组成的, 一个小方格就是一个像素.例如div尺寸是100 x 100, 那么水平方向就占用100个小方格, 垂直方向就占用100个小方格
    像素特点:不会随着视口大小的变化而变化, 像素是一个固定的单位(绝对单位)
  • 百分比
    百分比是前端开发中的一个动态单位, 永远都是以当前元素的父元素作为参考进行计算.例如父元素宽高都是200px, 设置子元素宽高是50%, 那么子元素宽高就是100px
    特点
    子元素宽度是参考父元素宽度计算的
    子元素高度是参考父元素高度计算的
    子元素padding无论是水平还是垂直方向都是参考父元素宽度计算的
    子元素margin无论是水平还是垂直方向都是参考父元素宽度计算的
    不能用百分比设置元素的border属性
  • em
    em是前端开发中的一个动态单位, 是一个相对于元素字体大小的单位
    例如font-size: 12px; ,那么1em就等于12px
    特点
    当前元素设置了字体大小, 那么就相对于当前元素的字体大小
    当前元素没有设置字体大小, 那么就相当于第一个设置字体大小的祖先元素的字体大小
    如果当前元素和所有祖先元素都没有设置大小, 那么就相当于浏览器默认的字体大小
    结论
    em是一个动态的单位, 会随着参考元素字体大小的变化而变化(相对单位)
  • rem
    rem就是root em, 和em是前端开发中的一个动态单位,
    rem和em的区别在于, rem是一个相对于根元素字体大小的单位
    例如 根元素(html) font-size: 12px; ,那么1em就等于12px
    特点
    除了根元素以外, 其它祖先元素的字体大小不会影响rem尺寸
    如果根元素设置了字体大小, 那么就相对于根元素的字体大小
    如果根元素没有设置字体大小, 那么就相对于浏览器默认的字体大小
    结论
    rem是一个动态的单位, 也会随着根元素字体大小的变化而变化(相对单位)
  • vw(Viewport Width)和vh(Viewport Height)
    vw和vh是前端开发中的一个动态单位, 是一个相对于网页视口的单位
    系统会将视口的宽度和高度分为100份,1vw就占用视口宽度的百分之一, 1vh就占用视口高度的百分之一,vw和vh和百分比不同的是, 百分比永远都是以父元素作为参考, 而vw和vh永远都是以视口作为参考
    结论:
    vw/vh是一个动态的单位, 会随着视口大小的变化而变化(相对单位)
    vmin和vmax
    vmin: vw和vh中较小的那个
    vmax: vw和vh中较大的那个
    使用场景: 保证移动开发中屏幕旋转之后尺寸不变
  • 视口
    视口简单理解就是可视区域大小我们称之为视口
    在PC端,视口大小就是浏览器窗口可视区域的大小
    在移动端, 视口大小并不等于窗口大小, 移动端视口宽度被人为定义为了980

1.为什么是980而不是其他的值?
因为过去网页的版心都是980,乔老爷子为了能够让网页在移动端完美的展示, 所以将iOS手机视口的大小定义为了980,后来谷歌也觉得这是一个非常牛X的方案, 所以Android手机的视口也定义为了980
2.移动端自动将视口宽度设置为980带来的问题
虽然移动端自动将视口宽度设置为980之后让我们可以很完美的看到整个网页
但是由于移动端的物理尺寸(设备宽度)是远远小于视口宽度的
所以为了能够在较小的范围内看到视口中所有的内容, 那么就必须将内容缩小
(和前面讲解Canvas时讲解的viewbox一样, 近大远小原理)
3.如何保证在移动端不自动缩放网页的尺寸?

通过meta设置视口大小
<meta name="viewport" content="width=device-width, initial-scale=1.0">
width=device-width 设置视口宽度等于设备的宽度
initial-scale=1.0 初始缩放比例, 1不缩放
maximum-scale:允许用户缩放到的最大比例
minimum-scale:允许用户缩放到的最小比例
user-scalable:用户是否可以手动缩放

2.移动端适配方案

2.1通过媒体查询
媒体查询的方式可以说是我早期采用的布局方式,
它主要是通过查询设备的宽度来执行不同的css代码,最终达到界面的配置
媒体查询优势
简单, 哪里不对改哪里
调整屏幕宽度的时候不用刷新页面即可响应式展示
特别适合对移动短和PC维护同一套代码的时候
媒体查询劣势
由于移动端和PC端维护同一套代码, 所以代码量比较大,维护不方便
为了兼顾大屏幕或高清设备,会造成其他设备资源浪费,特别是加载图片资源
为了兼顾移动端和PC端各自响应式的展示效果,难免会损失各自特有的交互方式
媒体查询应用场景
对于比较简单(界面不复杂)的网页, 诸如: 企业官网、宣传单页等
我们可以通过媒体查询、伸缩布局、Bootstrap来实现响应式站点
对于比较复杂(界面复杂)的网页, 诸如: 电商、团购等
更多的则是才是PC端一套代码, 移动端一套代码

@media screen and (min-width: xxxpx){
      上面的xxx代表媒体设备的宽度
    }

如何实现PC端一套代码,移动端一套代码,
在PC端打开自动打开PC端界面
在移动端打开自动打开移动端界面
步骤:
默认打开PC端界面
在PC端界面中通过BOM拿到当前浏览器信息
通过正则判断当前浏览器是否是移动端浏览器
通过BOM的location对象实现跳转到移动端界面

let userAgentInfo = navigator.userAgent;
           console.log(userAgentInfo);
          //PC: Mozilla/5.0 (Windows NT 10.0; WOW64)...
    //移动端: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X)...
    //移动端: Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T)...
function isPc() {
    let userAgentInfo = navigator.userAgent;
    if(/iphone/i.test(userAgentInfo)){
        return false;
    }else if(/android/i.test(userAgentInfo)){
        return false;
    }
    return true;
}
if(!isPc()){
    location.href = "http://m.jd.com";
}

2.2通过媒体查询 + rem
虽然我们将移动端独立到一套代码中了, 但是由于移动端也有很多的屏幕尺寸, 所以也需要进行适配
例如:
iPhone3/4/5: 320px
iPhone678: 375px
iPhoneX/plus: 414px
当下在企业开发中设计师提供给我们的移动端设计图片是750xxx的或者1125xxx的
所以我们需要对设计师提供的图片进行等比缩放, 这样才能1:1还原设计图片
如何等比缩放?
将设计图片等分为指定份数,求出每一份的大小
例如: 750设计图片分为7.5份, 那么每一份的大小就是100px
将目标屏幕也等分为指定份数,求出每一份的大小
例如: 375屏幕也分为7.5份, 那么每一份的大小就是50px
用 原始元素尺寸 / 原始图片每一份大小 * 目标屏幕每一份大小 = 等比缩放后的尺寸
例如: 设计图片上有一个150150的图片, 我想等比缩放显示到375屏幕上
那么: 150 / 100 * 50 = 1.5
50 = 75px
如何在前端开发中应用这个计算公式?
目标屏幕每一份的大小就是html的font-size: 50px
使用时只需要用 "原始元素尺寸 / 原始图片每一份大小rem" 即可
150 / 100 = 1.5 / 1.5rem
1rem = 50px / 1.5rem === 1.5*50 = 75px

2.3 通过JS动态计算当前屏幕每一份大小的好处: 不用写很多的媒体查询
坏处: 切换了屏幕尺寸之后需要刷新界面才有效
而媒体查询如果切换了屏幕的尺寸不需要重新刷新界面

    document.documentElement.style.fontSize = window.innerWidth / 7.5 + "px";

2.4最终的适配方案

 <script>
    let scale = 1.0 / window.devicePixelRatio;
    console.log(scale);
    let text = `<meta name="viewport" content="width=device-width, initial-scale=${scale}, maximum-scale=${scale}, minimum-scale=${scale}, user-scalable=no">`;
    document.write(text);
    console.log(window.innerWidth);
</script>
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,294评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,493评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,790评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,595评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,718评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,906评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,053评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,797评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,250评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,570评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,711评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,388评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,018评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,796评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,023评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,461评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,595评论 2 350