PC端UI设计尺寸规范?_百度知道6个html5页面适配iphone6的技巧--百度百家
6个html5页面适配iphone6的技巧
分享到微信朋友圈
iphone6及iphone6plus已经出来一段时间了。很多移动端网站，以前写死body为320px的，现在估计也忙着做适配了。
大屏幕手机其实一直有，只是以前大家没怎么重视，移动端的H5页面大部分都以320px为基准宽度进行布局，那些大屏屌丝android用户也懒得去理，而现在iphone也搞起多屏幕，老板们重视程度就不一样了。
回归正题，兼容iphone各版本机型最佳的方式就是自适应。
1、viewport简单粗暴的方式：
&metaname="viewport"content="width=320,maximum-scale=1.3,user-scalable=no"&
直接设置viewport为320px的1.3倍，将页面放大1.3倍。
为什么是1.3？
目前大部分页面都是以320px为基准的布局，而iphone6的宽度比是375/320=1.171875，iphone6+则是414/320=1.29375
那么以1.29倍也就约等于1.3了。
2、ip6+的CSSmediaquery
@media(min-device-width:375px)and(max-device-width:667px)and(-webkit-min-device-pixel-ratio:2){
/*iphone6*/
@media(min-device-width:414px)and(max-device-width:736px)and(-webkit-min-device-pixel-ratio:3){
/*iphone6plus*/
PS:也可以直接使用实际的device-width：如device-width:375px
在原有页面的基础上，再针对相应的屏幕大小单独写样式做适配。
3、REM布局
REM是CSS3新增的一种单位，并且移动端的支持度很高，android2.x+，ios5+都支持。
REM是相对于dom结构的根元素来设置大小，也就是html这个元素。相较于em单位，rem使用上更容易理解及运用。
REM与PX的换算可以查看网址：/prototypes/rem-calculator/
假设，html我们设置font-size:12也就是说12px相对于1rem，那么18px也就是18/12=1.5rem。
那么我们以320px的设计布局为基准，将html设置为font-size:100px，即100px=1rem。(设置100px是为了方便计算)那么可以将大部分px单位除以100就可以直接改成rem单位了。
REM如何做响应式布局？
1、如果仅仅是适配ip6+设备，那么使用mediaquery就行。
伪代码如下：
/*320px布局*/
html{font-size:100}
body{font-size:0.14rem/*实际相当于14px*/}
/*iphone6*/
@media(min-device-width:375px)and(max-device-width:667px)and(-webkit-min-device-pixel-ratio:2){
html{font-size:117.1875}
/*iphone6plus*/
@media(min-device-width:414px)and(max-device-width:736px)and(-webkit-min-device-pixel-ratio:3){
html{font-size:129.375}
这样，在ip6下，也就将页面内的元素放大了1.17倍，ip6+下也就是放大了1.29倍。
2、如果是完全自适应，那么可以通过JS来控制。
(function(doc,win){
vardocEl=doc.documentElement,
resizeEvt='orientationchange'inwindow?'orientationchange':'resize',
recalc=function(){
varclientWidth=docEl.clientW
if(!clientWidth)
docEl.style.fontSize=100*(clientWidth/320)+'px';
//AbortifbrowserdoesnotsupportaddEventListener
if(!doc.addEventListener)
win.addEventListener(resizeEvt,recalc,false);
doc.addEventListener('DOMContentLoaded',recalc,false);
})(document,window);
页面初始化的时候计算font-size，然后再绑定resize事件。这种效果就和百分比布局一样了。
那么用REM做单位与百分比做单位有什么优势？
主要优势在于能更好的控制元素大小。（一般百分比应用在布局层，一般常见设置为50%，33.3%，25%之类的整数居多，难以运用在复杂的页面小部件内）。
但是相比百分比布局，需要借助JS或mediaquery实现，略有一点瑕疵。
4、图片自适应
刚说完REM布局，那么用百分比布局也能实现一样的效果，但是用百分比布局，必须要面临一个问题：图片宽度100%，页面加载时会存在高度塌陷的问题。.
那么可以用padding-top设置百分比值来实现自适应。
公式如下：
padding-top=(ImageHeight/ImageWidth)*100%
原理：padding-top值为百分比时，取值是是相对于宽度的。
相关代码实现：
&divclass="cover"&
&imgsrc="http://g./bao/uploaded/i1/TB1d6QqGpXXXXbKXXXXXXXXXXXX_!!0-item_pic.jpg_160x160q90.jpg"alt=""/&
.cover{position:padding-top:100%;height:0;overflow:}
.coverimg{position:top:0;width:100%;}
DEMO地址，缩放浏览器窗口看看。
5、图片高清化
大家都知道，iphone6plus是3倍高清图了，它的devicePixelRatio=3。
在ios8下，已经开始支持img的srcset属性了（目前移动端也就ios8开始支持），也就是说，可以对一张图片设置2个URL，浏览器自动加载对应的图片。
黄色表示仅支持旧的srcset规范，绿色表示支持全新的srcset规范，包括sizes属性，w描述符。这里不展开，详细了解可自行google。
不过目前前端这边图片的实现基本都用lazyload的方式实现。srcset的图片加载方式在实际项目中运用还比较少。
6、背景图高清化
mediaquery实现高清化
img标签的高清化，可以通过JS判断devicePixelRatio的值来加载不同尺寸的图片，但是对于背景图，写在CSS中的，用JS来判断就略麻烦了，还好CSS通过mediaquery也能判断dpr。
目前兼容性最好的背景图高清化实现方式，使用mediaquery的-webkit-min-device-pixel-ratio做判断：
/*普通显示屏(设备像素比例小于等于1)使用1倍的图*/
background-image:url(img_1x.png);
/*高清显示屏(设备像素比例大于等于2)使用2倍图&*/
@mediaonlyscreenand(-webkit-min-device-pixel-ratio:2){
background-image:url(img_2x.png);
/*高清显示屏(设备像素比例大于等于3)使用3倍图&*/
@mediaonlyscreenand(-webkit-min-device-pixel-ratio:3){
background-image:url(img_3x.png);
进一步，可以通过工具生成相应的3x，2x，1x的图片及css，在使用时直接引用即可。谁搞一个？
关于移动设备的-webkit-min-device-pixel-ratio值，可以查看该网页的整理：/articles/min-device-pixel-ratio/
image-set实现高清化
image-set，它是Webkit的私有属性，也是Css4的一个属性，它是为了解决Retina屏幕下的图像显示而生。
使用方式也很简单。伪代码如下：
background-image:url(1x.png);&&&/*不支持image-set的情况下显示*/
background:-webkit-image-set(
url(1x.png)1x,/*支持image-set的浏览器的[普通屏幕]下*/
url(2x.png)2x,/*支持image-set的浏览器的[2倍Retina屏幕]*/
url(3x.png)3x/*支持image-set的浏览器的[3倍Retina屏幕]*/
目前移动端的支持程度来看，ios7+，android4.4+下已经支持了。如果仅仅是做ip6+的高清适配方案。image-set也是一种实现方案。
使用image-set与mediaquery实现有什么区别及好处？
这篇文章里面做了很详细的阐述，大家可以看看：/safari-6-and-chrome-21-add-image-set-to-support-retina-images/
大体的意思是：image-set不需要告诉浏览器使用什么图像，而是直接提供了图像让浏览器选择。这就意味着，如果在低网速下，浏览器可以选择加载低分辨率的图片。（PS：好智能的样子）
但是相比如mediaquery的实现，image-set仅支持单个图片的高清化，不适合在csssprite下使用。并且兼容性也是一大硬伤。
但是一般来说，用在LOGO区域，单个图片图标的区域下，也是个不错的选择。
7、图片列表的自适应
关于适配，也就是要让布局更灵活，在电商网站里面，商品列表是一个非常常见的结构。
一种比较智能的列表方式是：两端对齐，间距自适应。
那么可以使用FLEXBOX布局来实现两端对齐的效果，也可以使用text-align:justify的方式实现。
先看个flex实现的例子，主要通过justify-content:space-between，来实现：
flexbox的布局方式，在PC端就不合适了，ie9以下都不支持，那么更友好的方式可以使用text-align:justify来实现，兼容各大主流浏览器，包括IE6。
但是这2种布局方式都有一定的局限性。就是列表个数必须凑整。目前还没找到一种能够兼容不限个数的实现方案，如果各位看官有更好的实现方式，也欢迎提出，一起交流。
移动端ip6的适配方案有很多，没有固定的套路及方法，请根据自身业务的特点，选择其中的一些方法组合使用。
跨无忧（）来自“跨屏无忧”的想法，我们首个推出永久的、不依赖第三方的跨屏幕适配方案，希望以我们专业的力量帮助每个企业都能实现在移动互联网的转变，让企业网站轻松无忧完成到移动设备的跨屏幕适配，快速抓住移动互联网机遇。
阅读：9223
分享到微信朋友圈
在手机阅读、分享本文
还可以输入250个字
推荐文章RECOMMEND
阅读：9037
阅读：2829
阅读：10万
热门文章HOT NEWS
二月求婚，八月领证，十月吸毒被抓，这就是宋冬野民谣之外的“节奏”，
百度新闻客户端
百度新闻客户端
百度新闻客户端
扫描二维码下载
订阅 "百家" 频道
观看更多百家精彩新闻Web前端性能优化之图片优化教程-设计基础-网页制作-壹聚教程网Web前端性能优化之图片优化教程
然现在的网速相比以前还说已经提高了很多，但是打开网页图片还是会有等待的。前端的性能对于Web应用的用户体验来说非常重要。不要以为你的Web应用的性能已经足够好了,其实还会有很多可以提升的地方。
HTTP Archieve有个统计，图片内容已经占到了互联网内容总量的62%，也就是说超过一半的流量和时间都用来下载图片。从性能优化的角度看，图片也绝对是优化的热点和重点之一，Google PageSpeed或者Yahoo的14条性能优化规则无不把图片优化作为重要的优化手段，本文覆盖了Web图片优化的方方面面，从基本的图片格式选择、到尚未被广泛支持的响应式图片均有所提及。
Google Web Fundamentals的说法我很喜欢：
图片优化既是一门艺术，也是一门科学，图片优化是一门艺术，是因为单个图片的压缩不存在最好的特定性方案，而图片优化之所以是一门科学，是因为许多开发得很出色的方法和算法可以明显减小图片的大小。要找到图片的最优设置，需要按照许多维度进行认真分析：格式能力、编码数据内容、像素尺寸等。
真的要用图片吗?
要实现需要的效果，真的需要图片吗?这是首先要问自己的问题。浏览器和Web标准的发展速度极快，记得数年前我在用微软Silverlight 1.0写视频播放器的时候，中文还不能使用自定义字体显示，所以那时候写了很多糟糕的代码把需要的文字在服务器上生成图片并缓存起来。用户下载起来很慢，也完全无法检索这些文字。
但是现在不一样了，很多特效(渐变、阴影、圆角等等)都可以用纯粹的HTML、CSS、SVG等加以实现，实现这些效果少则寥寥数行代码，多则加载额外的库(一张普通的照片比非常强大的效果库也大了许多)。这些效果不但需要的空间很小，而且在多设备、多分辨率下都能很好的工作，在低级浏览器上也可以实现较好的功能降级。因此在存在备选技术的情况下，应该首先选择这些技术，只有在不得不使用图片的时候才加入真正的图片。
CSS效果、CSS动画。提供与分辨率无关的效果，在任何分辨率和缩放级别都可以显示得非常清晰，占用的空间也很小。
网络字体。现在连很多图标库都是用字体方式提供，保持文字的可搜索性同时扩展显示的样式。
前端工程师最好能和设计师、产品经理保持沟通，帮助他们了解到什么样的效果比较&简洁、高效、可维护&，毕竟对于CSS来说改变圆角矩形的Radius可以实时看到效果，用图片的话至少要重新生成图片、切图并替换资源。Retina、高分辨率屏幕、多尺寸的设备，这些都加快了非图片特效的发展，想想在高分辨率屏幕下Windows 7的惨不忍睹，就知道原生的图片资源绝对不是多多益善。
图片格式的选择
如果效果真的需要图片来表现，那么选择图片格式是优化的第一步。我们经常听到的词语包括矢量图、标量图、SVG、有损压缩、无损压缩等等，我们首先说明各种图片格式的特点
图片格式压缩方式透明度动画浏览器兼容适应场景
JPEG有损压缩不支持不支持所有复杂颜色及形状、尤其是照片
GIF无损压缩支持支持所有简单颜色，动画
PNG无损压缩支持不支持所有需要透明时
APNG无损压缩支持支持Firefox
iOS Safari需要半透明效果的动画
WebP有损压缩支持支持Chrome
Android Chrome
Android Browser复杂颜色及形状
浏览器平台可预知
SVG无损压缩支持支持所有(IE8以上)简单图形，需要良好的放缩体验，需要动态控制图片特效
其中APNG和WebP格式出现的较晚，尚未被Web标准所采纳，只有在特定平台或浏览器环境可以预知的情况下加以采用，虽然均可以在不支持的环境中较好的功能降级，但本节暂不讨论这两种格式。图片格式选择过程如下：
颜色丰富的照片，JPG是通用的选择
人眼的结构很适合查看JPG压缩后的照片，可以充分的忽略并在脑中补齐细节
JPG在压缩率不高时保留的细节还是不错的
WebP能够比JPG减少30%的体积，但目前兼容性较差
如果需要较通用的动画，GIF是唯一可用的选择
GIF支持的颜色范围为256色，而且仅支持完全透明/完全不透明
GIF在显示颜色丰富的动画时可能出现颜色不全、边缘锯齿等问题
如果图片由标准的几何图形组成，或需要使用程序动态控制其显示特效，可以考虑SVG格式
SVG是使用XML定义的矢量图形，生成的图片在各种分辨率下均可自由放缩
SVG中可以通过JavaScript等接口自由变换图片特效，可以完成其中部分元素的自由旋转、移动、变换颜色等
如果需要清晰的显示颜色丰富的图片，PNG比较好
PNG-8能够显示256种颜色，但能够同时支持256阶透明，因此颜色数较少但需要半透明的情景(如微信动画大表情)可以考虑PNG-8
PNG-24可以显示真彩色，但不支持透明，颜色丰富的图片推荐使用(如屏幕截图、界面设计图)
PNG-32可以显示真彩色，同时支持256阶透明，效果最好但尺寸也最大
图片尺寸的选择
尺寸，曾经是最不需要讨论的话题，但自从Retina出现之后世界就变得复杂多了。关于移动设备上的像素和尺寸，展开说足够写一篇论文，我建议想详细了解的同学参考下面的文章：
浅谈移动Web开发(上)：深入概念
这里只说我们关心的部分和结论，我们需要分清不同类型的像素：CSS像素和设备像素。一个 CSS像素可能包含多个设备像素。对于图片来说，在高DPI的屏幕上需要使用分辨率更高的图片，如果我们讨论的是Retina，那么就需要2倍分辨率(几乎4倍尺寸)的图片。这几乎没有取巧的空间，屏幕就是那么大，需要的图片也就是那么大。(鸽子为什么那么大?^_^)
我们能够控制的地方是&恰好&显示所需尺寸的图片。例如在屏幕中通过CSS或者
标签的wihth/height属性，将一副200x200的图片调整为100x100大小，那么这其中就有(200x200)-(100x100)=30000个像素是浪费的，这占到了图片尺寸的75%!
之所以有这么大的浪费，是因为图片的尺寸与面积基本成正比，与宽高的平方成正比。因此良好的计算客户端实际显示的图片尺寸，能够大大减小图片的大小。即使只有长和宽都只有10px被浪费，但是当图片足够大时，这部分也将产生很大影响。
响应式图片
上面提到&恰好&显示客户端所需大小的图片，听上去很容易不是吗?但当响应式布局出现后，这就变得极其困难。我们要支持上至1920宽度，下至 320宽度的无数种设备，如果使用1920宽度的图片，那么在小型设备(这类设备往往对网速和流量更加敏感)上每个用户都要付出额外的带宽和等待时间，如果使用320宽度的图片，那么在1920的屏幕上就像是在高清屏上使用DOS那么让人难以接受。
很自然的，我们需要图片也能&响应式&加载，根据所在设备的不同，加载不同尺寸的图片。响应式图片尚没有写入Web标准，实现起来也有诸多不便和兼容性限制。我建议参考百度EFE团队的这篇文章：
实战响应式图片
响应式图片虽然尚未成为标准，但这是Web图片优化的一柄利器，一旦被广泛支持，再没有比缩小图片尺寸更有效的优化方法了。
优化JPG和PNG
选择了正确的图片格式，按照正确的大小生成了图片后，我们还需要对图片进行进一步优化，这种优化一般分两步进行：
有损优化，删除没有出现或极少出现过的颜色，合并相邻的相近颜色。这一步并不必须，如PNG格式就直接进入下一步
无损优化，压缩数据，删除不必要的信息
JPG和PNG格式的图片生成后，一般还有进一步优化的空间，例如JPG格式的照片中，可能携带有相机的Exif信息，PNG格式的图片中可能带有 Fireworks等软件的图层信息等。去除这些额外信息后，还可以通过减小图片的调色板，去除没有出现过的颜色，以及合并相邻的相同颜色等手段来进行优化。原理性的内容这里不再赘述，仅介绍工程中可用的优化工具。
不同格式的图片有一系列工具，这些工具有有更多种参数调节方案，常见的几种调节工具有：
jpegtran优化JPG图片
OptiPNG无损PNG优化
AdvPNG无损PNG优化
PNGQuant有损PNG优化
如果你真的需要追求各种图片的极限压缩，可以参阅这些工具的文档，但是对于一般的Web应用，面对的图片种类多样，几乎不可能在工程中实现对每种工具的独立配置，因此推荐使用以下工具来进行优化。这些工具往往使用了上表中的一种或几种优化工具。
ImageOptim (Mac)
主页：htt:///
Mac平台下非常赞的图片优化工具，只需要把需要优化的图片拖拽进ImageOptim，就能够完成对图片的优化。设置选择的也很丰富，目前支持JPG和PNG的优化。这是我在写文章时最常用到的工具，把网站用到的图片拖进去，优化就完成了~
Kraken (Web)
主页：https://kraken.io/
在免费模式下可以上传图片，优化后打包下载，很多国外企业也选择了它的收费服务。亲自测试Kraken的图片优化结果比ImageOptim一般要小3%左右，效果不错，当然价格也不错。适合偶尔有图片优化需求，或者不在开发机上没有优化软件可以使用的情况。
智图 (Web)
腾讯ISUX团队有篇文章介绍智图：/zhitu.html
国货当自强，腾讯的智图工具推出不久，但实测效果很好，而且提供了Gulp的自动化支持，这部分会在后面自动优化章节介绍。只想建议一句，Kraken的首页比智图美好几百倍&& 而且把压缩前的PNG和压缩后的JPG放在一起对比大小，真的没关系么~
所有较新的浏览器都支持可缩放矢量图(SVG)，SVG是基于XML的图片格式，适用于二维图片。可以将SVG标记直接嵌入网页，也可以作为外部资源嵌入。可以通过大多数基于矢量的绘图软件创建SVG文件。这是一段简单的SVG图形：
这个圆形轮廓为黑色，背景为红色，从Adobe Illustrator直接导出。可以从中看到大量元数据，例如图层信息、注释和XML名称空间等等，在浏览器中呈现资源时，通常不需要这些数据。因此我们需要使用一些工具去除这些不必要的元数据，仅保留必须的标记。
SVGO工具可以缩减SVG文件的体积，在这个的例子中，SVGO能够将Illustrator生成的SVG文件大小减小58%，从470字节缩减到199字节。
由于SVG是基于XML的格式，本质上是纯文本，所以，还可以采用GZIP压缩来减小传输大小，当然这需要一些服务器配置，例如在apache服务器中设置：
AddType image/svg+xml .svg
AddOutputFilterByType DEFLATE image/svg+xml
来对SVG文件启用GZip压缩(当然你还需要先加载deflate模块并进行适当配置，GZip的配置超出了本文的范畴，这部分内容请自行Google)
优化GIF和APNG
GIF有很多好处，在颜色数较低的时候能够大幅减小图片体积，而且他也是唯一能够较为通用的展示动画的图片格式。关于GIF格式的优化原理我并不熟悉，只是在工程中直接使用成型的压缩工具，在后文自动优化章节的Grunt中，会介绍通过Grunt Task进行自动优化的方法。
关于APNG，目前浏览器对他的支持还不够好，不过在支持HTML5的场景中，有成熟的开源工具apng-canvas可以用于支持APNG。
腾讯ISUX团队有篇文章介绍iSparta工具：/introduction-of-apng.html。这是目前几乎唯一能够批量处理APNG文件的工具，感兴趣的同学可以在那篇文章里得到更多地了解。
前面说了太多关于如何优化各种不同格式图片的方法和工具，优化图片需要大量重复性的劳动，作为工程师显然不会忍受这一点，因此也产生出了很多工具对图片进行自动优化，这里主要介绍CDN、Grunt/Gulp、Google PageSpeed三种方式。
自动优化：CDN
使用CDN对图片自动进行优化，我在国外的CDN提供商处很少见到这类服务，倒是国内的两大新秀CDN七牛和又拍在这方面都做了大量工作。其工作方式为，向CDN请求图片的URL参数中包含了图片处理的参数(格式、宽高等)，CDN服务器根据请求生成所需的图片，发送到用户浏览器。
七牛云存储的图片处理接口极其丰富，覆盖了图片的大部分基本操作，例如：
图片裁剪，支持多种裁剪方式(如按长边、短边、填充、拉伸等)
图片格式转换，支持JPG, GIF, PNG, WebP等，支持不同的图片压缩率
图片处理，支持图片水印、高斯模糊、重心处理等
七牛云存储的图片处理接口使用并不复杂，例如下面这张原图：
我们通过如下URL请求，裁剪正中部分，等比缩小生成200x200：
/gogopher.jpg?imageView2/1/w/200/h/200
自动优化：Grunt/Gulp
这里介绍用于图片优化的Grunt组件：grunt-image。前端工程师的重复性工作，例如合并静态资源、压缩JS和CSS文件、编译SASS等都可以使用Grunt等自动化工具批量完成，图片优化也是如此。
grunt-image非常强大，按照作者的介绍，其内部加载的图片优化工具包括了pngquant, optipng, advpng, zopflipng, pngcrush, pngout, mozjpeg, jpegRecompress, jpegoptim, gifsicle和svgo。支持批量自动优化PNG, JPG, SVG和GIF，速度也不错，配置方式支持单图片优化和全目录优化：
module.exports = function (grunt) {
grunt.initConfig({
// 指定单独的图片优化
options: {
pngquant: true,
optipng: true,
advpng: true,
zopflipng: true,
pngcrush: true,
pngout: true,
mozjpeg: true,
jpegRecompress: true,
jpegoptim: true,
gifsicle: true,
svgo: true
'dist/img.png': 'src/img.png',
'dist/img.jpg': 'src/img.jpg',
'dist/img.gif': 'src/img.gif',
'dist/img.svg': 'src/img.svg'
// 指定图片目录进行优化
dynamic: {
expand: true,
cwd: 'src/',
src: ['**/*.{png,jpg,gif,svg}'],
dest: 'dist/'
grunt.loadNpmTasks('grunt-image');
自动优化：Google PageSpeed
Google做事风格比较彻底，看见哪个软件不好用就拿来直接fork出新版本或者干脆重写，对于Web优化，Google发布了了Google PageSpeed这个服务器模块，可以在apache或ngnix中加载，通过在服务器配置文件中进行设置来进行自动化的优化。对于图片格式转换、图片优化甚至图片LazyLoad都有相关选项。这部分展开会非常长，请感兴趣的同学参考Google的手册。
上一页： &&&&&下一页：相关内容移动端开发中，关于适配问题的一点总结(一) - 简书
下载简书移动应用
写了13129字，被9人关注，获得了11个喜欢
移动端开发中，关于适配问题的一点总结(一)
我们第一次接触移动web的时候，直观印象样应该是：屏幕比pc小很多，所以对pc端设计的界面，不一定（或者说不完全）能很好的适用到移动端。下面这段代码，做过移动端项目的同学一定不会陌生。
假设你已经见过上面的代码，并有所应用，对响应式设计如何工作有大概的了解，但不一定清楚一些细节。最近在做一个移动端的项目，要求做到精确还原设计稿，像素级。现在我把自己的一些心得分享出来，给大家参考。下面我就关于像素，视口，分辨率，meta视口 相关的内容展开叙述。要实现像素级还原，首先我们要搞清楚什么是像素。#像素像素(pixel) 是网页布局的基础，web开发者，包括设计师，凭直觉去使用它。我们好像对它很熟悉，但依然还有很多关于这个基础构建模块的东西需要我们去学习。例如，一个像素到底是什么。乍一看，这似乎是个非常简单的问题，一个像素就是计算机能够显示一种特定颜色的最小区域。屏幕上像素越多，你就看到的越多。或者说，同样尺寸的设备，像素越多，效果就越细腻。对于开发者来说，给一个元素设置 width : 200会发生什么事情呢？//废话
lol ，就是给它设置宽度200px 呗，stupid question..但要注意的一点是，这里定义的200px 并不是上面提到的设备像素。
像素分为两种：1.CSS像素：为web开发者创造的，在CSS 和JavaScript 中使用的一个抽象的层。2.设备像素： 设备屏幕的物理像素，任何设备的物理像素的数量都是固定的。width : 200 这个声明 表示，这个宽度为200px的元素跨越了200个CSS 像素，200个css像素相当于多少个设备像素取决于屏幕和用户的缩放，比如，在苹果的视网膜设备上，以5s为例，其像素密度是普通屏幕的两倍，那这个元素就跨越了400个设备像素。如果用户放大，那它将跨越更多的设备像素。我们使用的时候，只是去定义它的css像素尺寸就行了，关于它用了多少设备像素，就不是我们去计算了，浏览器会进行计算的。＃视口
我们一直在使用这行代码，但是这样写有什么用 ？
加了这个和不加这个到底有什么区别？要解释这个问题，我们首先要了解一个概念 - 视口在解释视口之前，我们先回顾一下CSS的基础：css中，在没有声明任何宽度时，每个块级元素的默认宽度都是100% 。那这个100% 是相对于什么的100% 呢？ 对了，是它父元素的100% 。 每一个css百分比都是根据它的父元素的宽度来进行计算的，所以宽度为父元素 宽度的100% ，本质是：
这里，div.aside占用了它的父元素 body 宽度的100％，但我们没有给body 定义宽度，因此，它占用了它的父元素，也就是html 宽度的100% 。但，我们同样也没有给它定义宽度。因此，它占用的是它的父元素宽度的100% ;那html 的父元素是谁呢 ？这就是要说的 视口了。在CSS文档中，它叫做 初始包含块。这是百分比计算的根源，它给css布局限制了最大宽度。在pc 浏览器中，视口的宽度 和浏览器窗口的宽度是一致的（先不管margin 和padding）,html ,body 元素的宽度都和浏览器窗口的宽度一致。测试走起：
测试结果表明上面的叙述是对的，这不是什么开创性的发现，只是方便下面的讲述。布局视口小屏幕的移动端设备，主要是手机和部分平板（屏幕特别巨大的除外＝ ＝ ），如果让视口的宽度和浏览器宽度 保持一致的话，会导致一个结果-------页面很丑。手机，平板，浏览器的宽度一般在240-640像素之间，而大...大多数给pc设计的宽度至少为800，一般是960，或者1080。因此，如果用手机去看刚才的那个页面，宽度20%的aside将会非常窄。如图：
一个为桌面设计的网站 在780～ 1260px
的视口中应该会显示的很好，20% 宽度的元素也会大致像设计师希望的那样。如果移动端的浏览器也能展示为pc设计的网站，大家一定会很开心。但是这是有代价的，如上图，如果移动端浏览器遇到了没有为移动端做优化的网站，它会尽可能的缩小网站让用户看到网站的全貌。所以就显得很挤，字体很小，阅读性很差。
这样用户就只有通过放大，去看想看的信息。在手机上，视口与移动端浏览器屏幕宽度不再关联，而是完全独立的了。这个视口，叫布局视口，css布局会根据它来计算，并被它约束。如图：
左图是在chrome 中放大之后的效果，图右是在手机中，放大后的效果，仅为说明两个视口的关系。 视觉视口字面意思，它是用户正在看到的网站的区域。我们可以通过缩放去操作视觉视口，但不会影响布局视口，布局视口仍保持原来的宽度。一般情况下，视觉视口对于开发人员来说并不是那么重要，到那时如果有需要看到用户正在看什么区域的需求，可以用js来获取。##理想视口首先来解释一下这个概念默认情况下，移动设备的布局宽度为768～1024像素，虽然这能让桌面网站不被压扁，但这并不是理想情况，尤其是对于小屏幕的使用者，因为在狭小的屏幕上，更适合狭小的网站。简单的说，就是，布局视口的默认宽度并不是一个理想的宽度。这就是 苹果 和其他效仿苹果的 浏览器厂商 引进理想视口的原因。理想视口，对设备来讲，是最理想的视口尺寸。显示在理想视口中的网站拥有最理想的宽度，不需要缩放。但，只有当网站是手机（或者平板）的时候，才应该使用理想视口。所以，这行代码：
就是告诉浏览器，我要使用理想视口了。让布局视口的宽度和理想视口的宽度一样。哦，对了，只有我们人为添加这段代码，理想视口才会生效，否则，布局视口将会维持默认宽度。
缩放首先，什么是缩放...从技术上讲，缩放就是放大或者缩小css像素的过程。典型的例子就是我在手机上浏览pc端的网站，放大一点，好看清字。但是，这个缩放会影响页面上的所有元素。比如，宽度为200px的元素占用了200个css像素，由于这些像素被放大了，这些像素就跨越了更多的物理像素，缩小则相反。css像素的尺寸缩小了，跨越的设备像素也就少了。所以，缩放会影响视觉视口的尺寸。放大会使视觉视口变得更小，我们看到的内容就越少，因为屏幕上显示的css像素更少了。缩小则会使视觉视口变的更大，使我们看到更多的部分。因为屏幕上css像素更多了。所以，缩放程度和视觉视口的大小是逆相关的：缩放程度越大，视觉视口越小。一个重大区别在手机上，布局视口不会被缩放。但是在pc上会，因为它的布局视口和视觉视口大小是一样的，不可能改变一个的同时，另一个不会变。要注意的是：移动端的缩放虽然不会导致css布局被重新计算，但是频繁的操作会给cpu比较大的负担，耗电快，因此不重新布局对性能有很大好处。##最小缩放 和最大缩放initial-scale=1,maximum-scale=1"如果允许缩放，那用户可以缩放到什么程度呢 ？在手机上是5个因子， 换句话说就是20% － 500%。但是安卓-webkit-不大一样,不管有没有meta指令，它的缩放范围都是4个因子（25%－400%）;我们可以通过:
来禁止用户缩放。分辨率分辨率有两个含义。1.设备每英寸的点的个数。2.CSS 和 JavaScript 中也有分辨率的概念，不过他们并不是一回事。物理分辨率dpi所有的屏幕都有物理分辨率，衡量单位为DPI ,（dots per inch）.DPI 越大，画面越清晰。另外要注意的一点，web开发者不可能知道物理分辨率，因为没法获取这个信息。有些手机通过screen.width暴露设备像素个数，但这在不同浏览器之间是不可靠的。无论如何JavaScript 都无法获取设备的物理尺寸。##设备像素比 dprJavaScript 中，有个属性，window.devicePixelRatio ，CSS也有device-pixel-ratio 和分辨率的媒体查询，但是它们都是和物理分辨率无关的。取而代之的是，他们提供了设备像素个数和理想视口的比，成为设备像素比，device pixel ratio,简称DPR。官方文档的描述如下：
window.devicePixelRatio是设备上物理像素和设备独立像素(device-independent pixels (dips))的比例。公式表示就是：window.devicePixelRatio = 物理像素 / dips。dips:device-independent pixels设备独立像素，就是独立于设备之外的像素，也就是css像素。比如：5s的物理像素为640px, CSS像素为320px,那 pdr = 640/320 = 2.DPR不一定是整数,比如BlackBerry Z10 的宽度是768px 物理像素；CSS像素为342px,因此，它的dpr 大约为 2.25.#meta视口meta 视口标签 存在的目的
主要是 让布局视口的尺寸和理想视口的尺寸匹配。Apple 发明了这个标签，其他的厂商复制了它的大部分内容。meta 标签应该被放在&head&中，并按以下格式书写：&meta name="viewport" content = "name= value,name = value"&每一个名/值 都是一个给浏览器的指令，以逗号分隔，常用的有5个：width设置布局视口的宽度，为一个正整数initial-scale设置页面的初始缩放程度 和布局视口的宽度minimum-scale允许用户的最小缩放程度，为一个数字，可以带小数maximum-scale允许用户的最大缩放值，为一个数字，可以带小数user-scalable是否允许用户进行缩放，值为"no"或"yes", no 代表不允许，yes代表允许完美的meta 视口在safari中，当设置initial-scale= 1 时，理想视口的尺寸会随着屏幕的旋转改变。在竖屏时，布局视口的宽度是320px ,横屏下，是480px 或者568px.但在ie10中却有完全相反的问题：initial-scale = 1
时，在横屏模式下宽度也保持为320px ,但width = device-width 时，它会从320px变为480px.所以为了在所有浏览器上解决类似的问题，我们需要如下写法：
字体和尺寸有了上面的理论基础，我们就能愉快的处理移动端尺寸的问题了。移动端的尺寸，主要是间距，宽高，字体，和图像 的尺寸。由于移动设备千差万别，如何才能保证效果呢？来看一下淘宝：
要注意的有三点：1. html
头部meat标签中的DPR2. width,height 的 rem 3.font-size 的rem：font size of the root element，那么rem是个单位，单位大小由根元素font-size的大小决定。关于动态修改font-size,具体的做法，可以参考 ,这里不再赘述。解决移动端尺寸问题的关键就是根元素的尺寸问题。现在普遍的做法是动态修改根元素的font-size,这样rem 会随着设备的变化有着不同的参考值，那尺寸问题就迎刃而解了。除了使用rem,另一种做法是使用来解决适配问题，这里暂时就不讨论了。还有一个是字体的问题，用一幅图表达就是：
字体的问题说大不大，说小也不小，关乎到用户体验，马虎不得。在字体的设置上，不推荐使用rem。我的做法是根据DPR 设置字体。当然，在开发的时候，我们不用手动去做这件事，可以借助来解决。如果不想用gulp，也可以使用scss 来解决。我简单定义了一下字体的mixin,基本能用，也给大家看看吧，欢迎拍砖。
也可以这样：
可以这样用：
生成的代码：
也可以看看了解webapp 中有关字体的更多信息。ios、android 等是不支持微软雅黑字体，为了满足产品的需要，保证视觉稿的还原度，手机端是如何定义微软雅黑字体呢？大家可能会想到 @font-face 定义为微软雅黑字体并存放到 web 服务器上，在需要使用时被自动下载.
但是这样做有两个比较突出的问题：1.中文字库文件往往很大，一来消耗用户的流量，二来对页面的打开速度造成了延迟。2.虽然可以用字蛛这样的工具去提取用到的字体，但是不方便后期维护。ios 系统默认中文字体是默认英文字体是默认数字字体是HelveticaNeue无微软雅黑字体android 系统默认中文字体是Droidsansfallback默认英文和数字字体是Droid Sans无微软雅黑字体winphone 系统默认中文字体是Dengxian(方正等线体)默认英文和数字字体是Segoe无微软雅黑字体做了个小测试，下图为测试机 iphone 5s、三星 GT-N7000 android 2.3.6、HTC windows Phone 8.0 三种手机中的默认中文字体和英文字体展现：
可以看出三种不同的中文字体和微软雅黑一样是，有无衬线只是一个小原因，而无论页面中使用哪种字体，肉眼很难看出它们的差异，对产品的体验几乎没有影响。有关衬线字体和无衬线字体的差别，参考下图：
使用系统默认的字体所达到的视觉效果跟使用微软雅黑字体没有明显的差别。结论：各个手机系统有自己的默认字体，且都不支持微软雅黑.如无特殊需求，手机端无需定义中文字体，使用系统默认.英文字体和数字字体可使用 Helvetica ，三种系统都支持.body {font-family: "Helvetica Neue", Helvetica, STHeiTi, sans-}
iOS 4.0+ 使用英文字体 Helvetica Neue，之前的iOS版本降级使用 Helvetica。中文字体设置为华文黑体STHeiTi（中文名称叫黑体-简）。设计时候一般用华文黑体来代替，两者差异微小。#结语第一、首先如果不设置meta viewport标签，那么移动设备上浏览器默认的宽度值为800px，980px，1024px等这些，总之是大于屏幕宽度的。这里的宽度所用的单位px都是指css中的px，它跟代表实际屏幕物理像素的px不是一回事。第二、使用 &meta name="viewport" content="width=device-width, initial-scale=1"&来得到一个理想视口。第三、市面上虽然有那么多不同种类不同品牌不同分辨率的手机，但它们的理想viewport宽度归纳起来无非也就 320、360、384、400等几种，都是非常接近的，理想宽度的相近也就意味着我们针对某个设备的理想viewport而做出的网站，在其他设备上的表现也不会相差非常多甚至是表现一样的。第四、使用rem 处理尺寸，使用font-size处理字体。最后的最后，由于本人还是前端路上的小菜鸟，见识有限，才疏学浅，有表述错误的地方，还请指正，以上。附参考资料：推荐：
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
打开微信“扫一扫”，打开网页后点击屏幕右上角分享按钮
被以下专题收入，发现更多相似内容：
· 3人关注
如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！
选择支付方式：