视口基础
一个典型的针对移动端优化的站点包含类似下面的内容:
width属性控制视口的宽度。可以像width=600这样设为确切的像素数,或者设为device-width这一特殊值来指代比例为100%时屏幕宽度的CSS像素数值。(相应有height及device-height属性,可能对包含基于视口高度调整大小及位置的元素的页面有用。)
initial-scale属性控制页面最初加载时的缩放等级。maximum-scale、minimum-scale及user-scalable属性控制允许用户以怎样的方式放大或缩小页面。
像素并非像素
在240 dpi及以上的屏幕上,initial-scale=1的页面实际上会被Fennec及Android WebKit浏览器放大至150%。其中的文字会保持平滑锐利,但位图图像在全屏模式下就难免不尽人意了。为了使图片在这些屏幕上变得清晰,web开发者或许会把图片甚至整个布局设计成最终尺寸的150%(或者200%从而支持像配备retina屏的iPhone那样的像素密度高达320 dpi及以上的设备),然后通过CSS或视口属性缩小。
默认比例依赖于显示密度。在密度低于200 dpi的显示设备上,比例为1.0。在密度介于200及300 dpi之间的显示设备上,比例为1.5。对于具有300 dpi以上密度的显示设备,比例为密度/150 dpi向下取整的结果。注意再有在视口比例为1时才会应用默认比例。否则,CSS像素与设备像素之间的关系依赖于当前的缩放等级。
视口宽度及屏幕宽度
许多站点把视口设为”width=320, initial-scale=1“来准确地适应iPhone在竖屏状态下的显示。如上所述,这会导致Fennec 1.0在渲染这些站点时产生问题,尤其是横屏模式下。为了修正这个问题,Fennec 1.1将在必要时扩展视口宽度至相应的尺寸来填满屏幕。这与Android和Mobile Safari的行为一致,而这在一点像iPad这样的大屏设备上尤其有用。(Allen Pike的viewport for iPad sites对web开发者做了充分说明)。
对于设置了初始或最大缩放的页面,width属性实际上变成了最小视口宽度。比如,如果你的布局需要至少500像素的宽度,那么你可以使用以下标记。当屏幕宽度大于500像素时,浏览器会扩展视口(而不是放大页面)来适应屏幕:
Fennec 1.1还增加了对minimum-scale、 maximum-scale以及user-scalable的支持,采用与Safari类似的默认值与限制。这些属性会影响初始尺寸及宽度,并且会限制缩放等级。
移动浏览器在处理屏幕方向改变时稍有差异。例如,Mobile Safari通常在竖屏转横屏时只缩放页面,而不会把页面重新布局成横屏载入时的效果。如果web开发者想让iPhone在方向切换时保持固定比例,需要增加一个maximum-scale值来避免这样的的缩放,这会带来并非预期的禁止用户缩放页面的副作用:
不得不了解的html5 head 头标签
优先使用 IE 最新版本和 Chrome
|
|
SEO 优化部分
|
|
移动端的头部标签和meta
|
|
MobileWeb 适配总结
固定高度,宽度自适应
这是目前最通用的一种做法,属于自适应布局,viewport width 设置为 device-width,以较小宽度(如 320px)的视觉稿作为参照进行布局。垂直方向的高度和间距使用定值,水平方向混合使用定值和百分比或者利用弹性布局,最终达到“当手机屏幕变化时,横向拉伸或者填充空白的效果”。图像元素根据容器情况,使用定值或者 background-size 缩放。
粗略浏览了下一些大厂的首页,像百度、腾讯、Facebook、Twitter 都是采用的这种方案。
要点:
以小宽度作为参照是因为如果布局满足了小宽度的摆放,当屏幕变宽时,简单的填充空白就可以了;而如果反过来就可能造成“挤坏了”,考虑 header 区域,左测 logo 右测横向 nav 的情况。
需要小宽度的布局,又需要大宽度的图像,这是一个矛盾点。
320px 过于窄小,不利于页面的设计;只能设计横向拉伸的元素布局,存在很多局限性。
兼容性较好。
固定宽度,viewport 缩放
视觉稿、页面宽度、viewport width 使用统一宽度,利用浏览器自身缩放完成适配。页面样式(包括图像元素)完全按照视觉稿的尺寸,使用定值单位 (px、em)即可完成。
优点:
开发简单 缩放交给浏览器,完全按视觉稿切图。
还原精准 绝对等比例缩放,可以精准还原视觉稿(不考虑清晰度的情况下)。
测试方便 在PC端即可完成大部分测试,手机端只需酌情调整一些细节(比如图标、字体混合排列时,因为字体不同造成的对齐问题)。
存在的问题:
像素丢失 对于一些分辨率较低的手机,可能设备像素还未达到指定的 viewport 宽度,此时屏幕的渲染可能就不准确了。比较常见的是边框“消失”了,不过随着手机硬件的更新,这个问题会越来越少的。
缩放失效 某些安卓机不能正常的根据 meta 标签中 width 的值来缩放 viewport,需要配合 initial-scale 。
文本折行 存在于缩放失效的机型中,某些手机为了便于文本的阅读,在文本到达 viewport 边缘(非元素容器的边缘)时即进行折行,而当 viewport 宽度被修正后,浏览器并没有正确的重绘,所以就发现文本没有占满整行。一些常用的段落性文本标签会存在该问题。
缩放失效问题需通过 js 动态设定 initial-scale。
文本折行问题可以通过 css 样式解决。
利用 rem 布局
依照某特定宽度设定 rem 值(即 html 的 font-size),页面任何需要弹性适配的元素,尺寸均换算为 rem 进行布局;当页面渲染时,根据页面有效宽度进行计算,调整 rem 的大小,动态缩放以达到适配的效果。利用该方案,还可以根据 devicePixelRatio 设定 initial-scale 来放大 viewport,使页面按照物理像素渲染,提升清晰度。
优点:
清晰度高,能达到物理像素的清晰度。
能解决 DPR 引起的“1像素”问题。
向后兼容较好,即便屏幕宽度增加、PPI 增加该方案依旧适用。
缺点:
适配 js 需尽可能早进入,减少(避免)viewport 变化引起的重绘。
某些Android机会丢掉 rem 小数部分。
需要预编译库进行单位转换。
开发时,css 及 js 都以 16px 作为基数换算 rem,借助预编译库(以 scss 为例),我们设定一个动态尺寸单位 $ppr: 750px/16px/1rem ,即 pixel per rem,任何使用弹性尺寸的地方写作:width: 100px/$ppr。
动态调整 rem 的方法如下:
MDN:手机网页开发
MDN:在移动浏览器中使用viewport元标签控制布局
移动前端开发和 Web 前端开发的区别是什么
Alloyteam移动开发规范概述
手机/移动前端开发需要注意的20个要点
w3cplus响应式技术资源
浅谈移动Web开发
Alloyteam Mars
移动WEB开发入门
移动开发资源集合
The Mobile Web Handbook
MobileWeb 适配总结
移动前端不得不了解的html5 head 头标签