㈠ web网站怎么获取访问的移动设备的屏幕大小
相比较桌面端，用户越来越多的从移动设备端访问网页，这已经不是什么新鲜事。然而开发者还是需要努力去让网站更好的适应现在的移动设备，与此同时，从谷歌最近宣布的消息可以看出，它可能会惩罚那些不能为移动设备用户提供良好用户体验的网站，这也迫使开发者努力做好这方面事宜。本文介绍了一些技巧可以帮助你更好的提供良好的移动用户体验。 以下为译文： 最近，谷歌员工暗示，不能提供友好用户体验的网站将受到来自谷歌搜索通信量的惩罚，谷歌在最近几年已经介绍了多个算法的变化，伤害了许多网站的流量。 不过谷歌的惩罚不应该是你努力使网站友好的主要动机，你的主要动机应该是为你的用户提供他们想要的东西，为他们提供最好的用户体验。所以确保你的网站友好的对象是移动用户，而不是谷歌。 选择一个移动方案，着眼于更好的满足网站用户的需求 这里主要有四个方法可以为用户提供更好的移动用户体验： 1. 创建一个单独的手机网站 如果你想提供一个不同于桌面网站用户体验的移动用户体验，创建一个单独的网站，让移动用户只有一个选择。 这个解决方案可能在某些情况下有意义，但是由于其过程类似于建立一个全新的网站，因此许多Web开发者都避免这种方法。 由于谷歌认为这样的移动用户网站是不同于桌面网站的另一个网站，所以你应该在桌面网站设置一个rel=alternate链接tag，类似于： 而在移动网站页面应包含rel=canonical链接tags，类似于： 2. 动态服务 移动和桌面网站不同URL的存在可能会给用户造成一些混淆。另一方面，仅从屏幕宽度来判断用户设备是否是移动设备并不是一个可靠的方法。 因此你或许可以考虑动态服务，它可以用相同的URL服务于移动和桌面网站，只需根据用户设备提供不同的HTML。 这种方法有点复杂，因为你需要有能力检测用户所使用设备的类型，如User-Agent(浏览器向服务器发送的数据头)。你可以在PHP中实现它(variable $_SERVER['HTTP_USER_AGENT'])，然后你需要查询数据库来确定设备尺寸，以此来计算设备是否是一个小屏幕。 当你通过相同的URL为不同的设备提供不同的HTML时，你还需要发送HTTP Vary响应，让谷歌机器人知道你依赖用户设备的网站，其工作是不同的，你可以使用下面的方法实现： Header('Vary: User-Agent'); ?> 3. 响应Web页面 响应Web页面是指页面在Web页面尺寸中适应性的调整变化。这意味着，如果Web页面改变其尺寸，使用相同HTML代码的页面布局将在某种程度下适应本身。 在实践中，不仅不同尺寸屏幕上出现的页面纬度不同，而且这些页面也需要适应设备方向的变化。比如说，当用户旋转设备的时候，如果开启了重力感应，其页面也会随之改变。因为屏幕的宽度和高度发生了改变。 这种方法被称为响应，因为它使用相同的HMTL动态的适应屏幕的变化，所以它非常的灵活。这种响应通常是使用CSS media查询来实现，这里有个示例： .c640 { display: block; } @media (max-width: 640px) { .c640 { display: none; } } 4. 移动应用 这种方法可以说是一种互补的解决方案，它包含在可以安装在用户设备上的移动应用中，有利用本地设备的能力。而且有些原生功能，用户无法通过访问你的网站来获得，例如向他们的设备发送一些推送通知等。 十个网站响应的技巧 1. 从网站访问次数最多的页面开始 如果你使用的是类似Wordpress这样的常见内容管理系统，你的工作将简单很多，因为你只需要通过一个响应站点更换主题即可。 如果你有一个基于定制开发的网站，比如说是PHP类的情况下，你将需要为适应移动用户做一些定制开发。 如果你有一个拥有上千页面的大网站，还要适应PHP类。你的工作将是巨大的，可能需要数月时间才能完成。因此你需要为这些影响更多用户的页面制定一个标准。 在PHP类网站的情况下，很容易确定影响更多用户的页面是发布于网站上的包，因为它们获得更多的访问量。除此之外，其他被访问最多的网页类型就不是很明确了。 因此你需要考虑站点谷歌分析报告，如果你担心谷歌启动算法更新，处罚非移动友好站点，那么最好看一下网站管理员工具报告，特别是Search Queries和Top Pages。 你可以使用PHP网站管理员工具API类来提取你所需要的页面报告。 2. 使用浏览器开发者工具在小屏幕上预览你的页面 一旦你找到了首要处理的页面，你需要掌控目前可能出现的问题，防止它们呈现在移动设备的屏幕上。 现在的浏览器(如Chrome)会提供工具，可以上你在不同的屏幕尺寸上预览页面。 3. 使视窗适应屏幕尺寸 在这一点中，你首先要做的事是定义一个可以根据屏幕尺寸调整的视窗。(视窗是指一个页面的可见部分)，如果一个页面太大，不适应当前的屏幕分辨率，这时可能需要滚动条。 定义视窗可以通过窗口宽度匹配设备宽度来实现，可以通过HTML标记指定的视窗参数。下面的这个例子里，我们定义窗口宽度匹配设备宽度，初始缩放范围从1开始。这意味着移动浏览器将调整页面宽度缩放比例来适应设备宽度。 4. 从页眉页脚开始 当你通过窗口宽度匹配设备宽度定义视窗后，你可能会注意到针对桌面的页面不适应小型移动设备屏幕，会出现溢出问题。这是你需要构建HTML响应。通常情况下，所有的网站都有带有页面和页脚HTML的页面。你可以从这里开始，因为你改变这些页面和页脚将影响所有的页面。 5. 使用菜单按钮收缩导航栏 PHP类网站下，可以使用两个水平菜单：一个常见的导航，另一个用于记录用户操作。 横向菜单可以利用可用的水平空间的优势，所以基本上所有的响应页面，其导航菜单都会有两个版本：一个是宽屏幕时，整个菜单选项可以水平显示，另一个则是菜单搜索按键加一个搜索栏。 网站使用media查询来显示单一类型的导航(或另一个)，下面代码演示的是HTML和CSS实现该功能的简化版本： Desktop menu here Mobile menu here @media (max-width: 1024px) { .c1025 { display: none; } } @media (min-width: 1025px) { .u1025 { display: none; } } 用PHP类构建的菜单按钮使用了一个很好的技巧来避免对JavaScript的需求。它使用一个隐藏的表单复选框来控制下拉菜单的可见性。 下面是使用HTML和CSS渲染这类菜单的简化版本： All class groups Latest entries Top 10 charts Blog Forums Help FAQ Icon Image here .menu-items { position: absolute; z-index: 1001; background-color: #103754; border-color: #cccccc; border-style: solid; border-width: 1px; padding: 4px; top: 32px; line-height: 36px; } .menu-items a { color: #C3F0FF; font-weight: bold; text-decoration: none; } #navigation-menu { display: inline-block; padding: 6px 10px 0px 10px; } #navigation-menu .menu-items { display: none; } #navigation-button:checked + .menu-items { display: inline-block; } #navigation-menu input[type="checkbox"], #navigation-menu ul span.drop-icon { display: none; } 6. 牺牲不重要页面元素 完成页眉页脚，你还要继续你的步伐，穿梭于网站每个类型页面中，按照页面访问优先级(参照前文)。 使用浏览器开发工具在小屏幕上预览页面，减少视窗分离器宽度，直到页面元素溢出视窗。 这时你需要找出哪些不重要的页面元素，你可以使用CSS样式通过media查询牺牲和隐藏它们。 下面演示的是media查询定义逐渐减少点，用于隐藏不同页面元素： @media (max-width: 1024px) { .c1025 { display: none; } @media (min-width: 1025px) { .u1025 { display: none; } } @media (max-width: 499px) { .c499 { display: none; } } @media (max-width: 799px) { .c799 { display: none; } } @media (max-width: 640px) { .c640 { display: none; } } @media (max-width: 360px) { .c360 { display: none; } } 7. 使用Google Page Speed Insights来解决悬而未决的问题 谷歌验证一个网站是否移动友好的标准有什么?在视窗上显示恰好的可见内容只是其中的一个标准，还有其他一些不太好评估的，比如接触点的距离(如链接和按钮)。 幸运的是，谷歌提供了一个工具来帮助我们发现需要修复的问题，这只是Google Page Speed Insights工具的一部分。 你只需要输入一个你制作的页面URL，它会向你展示一个等级(0%-100%)，让你知道你的页面在手机上的可用性等级，它还会显示该页面目前所存在的问题。 8. 图像适应页面宽度限制 你可能会遇到这样一个问题，需要适应小屏幕的页面存在很多的图片元素。这时你有两种选择，一是如前面提到的，牺牲图片元素;二是自动的调节图片的宽度和高度，该方法适用于有可用的空间。 第二种方法可以通过将图片的宽度设置为100%(或其他百分比)来实现，然后将图片高度设置为自动，以此来保证原始图片的比例。如下段代码所示例的那样： @media (max-width: 55em) { .blog-post-body p img { width: 100%; height: auto; } } 与图像相关的另一个方面是，如果你的菜单和图标使用的是小图像时，当浏览器缩放视窗来匹配设备宽度，那些小图片看起来会很大，如果那些图片分辨率很低的时候，更是会破坏整个页面的质量。而解决这种问题的一个方法是使用高分辨率图片，设置较小值的宽度来匹配设备。 9. 安全“填充”链接和按钮四周 谷歌工具可能会报告的另一个典型问题是，你的链接或按钮太接近对方了，这很容易导致错误操作。你可以利用CSS样式表“填充”这些链接和按钮的空间，下面是一个简单的示例： .safe-padding { padding: 2px; line-height: 200%; } 10.使用谷歌网站管理员工具：移动可用性报告 谷歌在Google Webmaster Tools网站上为我们提供了另一种工具：Mobile Usability(移动可用性)。它可以给你一个进程的概念，以及任何你可能或者你认为没有解决的问题。 这个工具显示不同类型的问题：触摸元素太近、小字体尺寸、宽度固定窗口……。它可以给你提供拥有这些问题的页的总数以及URL。不过工具不会实时报告这些，实际报告大概会延迟一个星期，所以它的报告中或许会存在你已修复的问题。尽管如此，它也是很有用处的，任何页面的问题都会有一个链接，你对此会一目了然。 总结 对Web开发者来说，调整网站以适应移动设备是乏味和无聊的任务，远没有前端工作给人带来的兴奋。然而这是必须的进行的一项任务。 移动适应工作仍在继续，只有部分页面适应了移动设备，所以在未来我们会看到更多的变化。 无论如何，本文是为了分享一些有用的信息给那些正处于网站适应移动设备过程的人们。如果您已经经历过类似的过程，或者您有其他相比较本文所分享的技巧而言更好的方法。您可以留下您的观点，分享您的经验。
㈡ 移动端Web页面适配方案（整理版）
<meta charset="utf-8">
@(概述)[基本概念|百分比|rem|vw/vh|响应式设计]
移动端web页面的开发，由于手机 屏幕尺寸 、 分辨率 不同，或者需要考虑 横竖屏 问题，为了使得web页面在不同移动设备上具有相适应的展示效果，需要在开发过程中使用合理的适配方案来解决这个问题。
早期网页设计采用 静态布局 ，通过 <meta> 标签中的 applicable-device 应用设备标识识别移动设备，即 <meta name = 'applicable-device' content = 'mobile'> ，在 <meta> 标签中的 viewport 标签中设置 width ，通过 js 动态修改标签的 initial-scale 使得页面等比缩放，刚好占满整个屏幕。一些文章中有提到静态布局中页面各个元素采用 px 为单位，这种方案实现简单，不存在兼容性问题，但用户体验很不友好。
后面出现 流式布局 ，使用百分比 % 定义宽度，高度使用 px 固定，根据可视区域大小实时进行尺寸调整，通常使用 max-width/min-width 控制尺寸范围过大或者过小。这种方案实现比较简单，但在大屏手机或横竖屏切换场景下可能会导致页面元素被拉伸变形，字体大小无法随屏幕大小发生变化。
顺应不同页面字体大小展现问题，出现了 弹性布局 。这种布局方案下，包裹文字的元素的尺寸采用 em/rem 为单位，页面主要划分区域的尺寸依据情况使用 px 、百分数或者 em/rem 。如一些高校的网站 jlu ，页面的主要划分区域使用 px 和百分比，包裹文字的元素和文字采用 em 。
上面的这几种方案下，页面元素的大小按照屏幕分辨率进行适配调整，但是整体布局不变，对于 响应式web设计 ，网页布局会随着访问它的视口及设备的不同呈现不同的样式，在实现上可能会以上多种方案的结合，同时搭配 媒体查询 技术使用，使得一个页面在多个终端 (PC, mobile, pad) 呈现满意效果，如 mashable 。
[TOC]
像素，是屏幕上显示数据的最基本的点，表示相对大小。不同分辨率下相同长度的 px 元素显示会不一样，是因为像素点的个数相同情况下，不同分辨率下每个像素点对应的像素宽度不同。比如同样是 14px 大小的字，在 1366×768 显示屏下会显示的小，在 1024×768 显示屏下会相对大。也称为 物理像素（设备像素 ），是分辨率的尺寸单位。
印刷行业常用单位，能够使用测量设备测得的长度，等于 1/72 英寸。
在不同屏幕上， css 像素呈现的物理尺寸一致，但 css 像素对应的物理像素具数不同。标准的显示密度下， 1 个 css 像素对应一个物理像素，缩放时， 1 个 css 像素对应的物理像素会减增。是一种 设备独立像素(device independent pixels: DIPs)
像素密度，每英寸所拥有的像素数。值越高，显示画面细节越丰富。计算公式为：[图片上传失败...(image-245547-1621406560980)]
，其中 [图片上传失败...(image-2b7617-1621406560980)]
和 [图片上传失败...(image-f0525f-1621406560980)]
是分辨率的宽高，[图片上传失败...(image-2b6254-1621406560980)]
是屏幕尺寸。
打印设备每英寸印刷出来的点有多少个，值越高，图片越细腻。
设备物理像素和设备独立像素比 ，即[图片上传失败...(image-6bbc3c-1621406560980)]
是指在理想布局宽度，使用多少个物理像素来渲染一个css像素。js中通过 window.devicePixelRatio 获取，css中通过 -webkit-device-pixel-ratio , -webkit-min-device-pixel-ratio , -webkit-max-device-pixel-ratio 进行媒体查询。
<meta> 标签中定义了一些元数据信息，通过设置 <meta name = "viewport"> ，提供有关 视口初始大小 的信息，供 移动设备 使用。属性值为
移动端涉及 布局视口 （Layout Viewport）、 视觉视口 （Visual ViewPort）和 理想视口 （Ideal ViewPort）。
与移动端web页面适配有关的手机屏幕特性包括
硬件所支持的，屏幕每行的像素 * 每列的像素点数，单位是 px 。
设备独立的，软件可以达到的，个人理解是使得软件/页面在不同屏幕上显示出来的效果一致。
像素分辨率 ÷ 逻辑分辨率等于 倍率 ，如 @3x 表示分辨率的 3 倍。一个已知物理像素大小的元素，如果在普通屏中其设备像素等于 css 像素，但在一些高清屏中，如 Retina 显示屏，一个css像素对应 2 或 3 个设备像素，这时显示出来的元素会变小。为了让元素如期待显示，需要传入 原始设计稿尺寸 × 倍率 的设计稿，根据 DPR 的定义，这样加载后能够达到同样的效果。
手机屏幕对角线长度换算成英寸的大小
贴上 源码 分析
视口 是浏览器中用于呈现网页的区域，移动端的视口通常指的是 布局视口
使用 css 预处理器把设计稿尺寸转换为 vw 单位，包括 文本 ， 布局高宽 ， 间距 等，使得这些元素能够随视口大小自适应调整。以 1080px 设计稿为基准，转化的计算表示为
响应式设计 使得一个网站同时适配 多种设备 和 多个屏幕 ，让网站的布局和功能随用户的使用环境（屏幕大小、输出方式、设备/浏览器能力而变化），使其视觉合理，交互方式符合习惯。如使得内容区块可伸缩与自由排布，边距适应页面尺寸，图片适应比例变化，能够自动隐藏/部分显示内容，能自动折叠导航和菜单。
㈢ 如何调整网页大小与屏幕适应
第一种方法：可以按着Ctrl键，然后滚动鼠标滑轮对网页大小进行调整。调整到与电脑屏幕大小相适应的程度即可。
第二种方法：点击浏览器右下角的缩放页面比例，然后对网页进行相对应的调整即可。
㈣ 移动端web 怎么调整table使用各种手机屏幕的大小
设置width 100%就可以了，另外在html顶端，需要设置<meta name="viewport" content="width=device-width, minimum-scale=1, maximum-scale=1">
㈤ 移动web终端 viewport设置
移动web，顾名思义就是在移动端的web页面，比如我们可以在手机的UC浏览器中访问淘宝等网站：
可以发现淘宝的移动web版本和pc上web版本有很大的不同，在移动web版本中更像是模拟了native应用中的页面。所以移动web的开发和pc上web的开发肯定也是有很大的不同。
先看正常的pc上web页面在移动设备上的展示：
从上图可以看出，正常PC上的网页在移动设备被缩放了，这样对于商城购物类的网站来说，用户体验非常差，所以就更应该要有适配移动设备的页面了。
那么究竟是怎样适配移动端的页面呢？答案就是viewport，可以将viewport理解为浏览器中用来承载网页的那一层。默认情况下移动设备上浏览器会自动将viewport的值设置为980px或者1024px，不过手机的屏幕没有那么大，这时候网页就缩放了。
到这里，web适配移动设备的方案就出来，让viewport=手机的宽度就好了。是的，正常情况下都是这么用的：
在meta标签中设置viewport的宽度为设备的宽度， initial-scale=1 的意思是页面的缩放比例为1， user-scalable=no 的意思是禁止用户缩放页面， minimum-scale=1,maximum-scale=1 的意思是设置用户的最大最小缩放比，当设置了 user-scalable=no 之后这两个属性值就没有意义了。
以上就是viewport的主流设置，不错淘宝（m.taobao.com）就是非主流的设置，淘宝的移动web页面中viewport没有设置宽度：
所以淘宝的viewport的width应该是用js动态获取的。
㈥ 移动端网页设计尺寸标准
涉移动端设计和开发的同学们，基本都会在尺寸问题上纠结好一阵子才能摸到头绪。那么大家知道移动端网页设计尺寸标准是多少呢?下面一起来看看!
现象
首先说现象，大家都知道移动端设备屏幕尺寸非常多，碎片化严重。尤其是Android，你会听到很多种分辨率：480x800, 480x854, 540x960, 720x1280, 1080x1920，而且还有传说中的2K屏。近年来iPhone的碎片化也加剧了：640x960, 640x1136, 750x1334, 1242x2208。
不要被这些尺寸吓倒。实际上大部分的app和移动端网页，在各种尺寸的屏幕上都能正常显示。说明尺寸的问题一定有解决方法，而且有规律可循。
像素密度
要知道，屏幕是由很多像素点组成的。之前提到那么多种分辨率，都是手机屏幕的实际像素尺寸。比如480x800的屏幕，就是由800行、480列的像素点组成的。每个点发出不同颜色的光，构成我们所看到的画面。而手机屏幕的物理尺寸，和像素尺寸是不成比例的。最典型的例子，iPhone 3gs的屏幕像素是320x480，iPhone 4s的屏幕像素是640x960。刚好两倍，然而两款手机都是3.5英寸的。
所以，我们要引入最重要的一个概念：像素密度，也就是PPI(pixels per inch)。这项指标是连接数字世界与物理世界的桥梁。
Pixels per inch，准确的说是每英寸的长度上排列的像素点数量。1英寸是一个固定长度，等于2.54厘米，大约是食指最末端那根指节的长度。像素密度越高，代表屏幕显示效果越精细。Retina屏比普通屏清晰很多，就是因为它的像素密度翻了一倍。
倍率与逻辑像素
再用iPhone 3gs和4s来举例。假设有个邮件列表界面，我们不妨按照PC端网页设计的思维来想象。3gs上大概只能显示4-5行，4s就能显示9-10行，而且每行会变得特别宽。但两款手机其实是一样大的。如果照这种方式显示，3gs上刚刚好的效果，在4s上就会小到根本看不清字。
在现实中，这两者效果却是一样的。这是因为Retina屏幕把2x2个像素当1个像素使用。比如原本44像素高的顶部导航栏，在Retina屏上用了88个像素的高度来显示。导致界面元素都变成2倍大小，反而和3gs效果一样了。画质却更清晰。
在以前，iOS应用的资源图片中，同一张图通常有两个尺寸。你会看到文件名有的带@2x字样，有的不带。其中不带@2x的用在普通屏上，带@2x的用在Retina屏上。只要图片准备好，iOS会自己判断用哪张，Android道理也一样。
由此可以看出，苹果以普通屏为基准，给Retina屏定义了一个2倍的倍率(iPhone 6plus除外，它达到了3倍)。实际像素除以倍率，就得到逻辑像素尺寸。只要两个屏幕逻辑像素相同，它们的显示效果就是相同的。
Android的解决方法类似，但更复杂一些。因为Android屏幕尺寸实在太多，分辨率高低跨度非常大，不像苹果只有那么几款固定设备、固定尺寸。所以Android把各种设备的像素密度划成了好几个范围区间，给不同范围的设备定义了不同的倍率，来保证显示效果相近。像素密度概念虽然重要，但用不着我们自己算，iOS与Android都帮我们算好了。
如图所示，像素密度在120左右的屏幕归为ldpi，160左右的归为mdpi，以此类推。这样，所有的Android屏幕都找到了自己的位置，并赋予了相应的倍率：
ldpi [0.75倍]
mdpi [1倍]
hdpi [1.5倍]
xhdpi [2倍]
xxhdpi [3倍]
xxxhdpi [4倍]
各型号iPhone的倍率比较简单，我们后面会讲到。那么Android手机那么多，具体怎么分?哪些手机是几倍的倍率呢?我们先看一张表，这是友盟2014年10月到2015年03月的数据：
就目前市场状况而言，各种手机的分辨率可以这样粗略判断。虽然不全面，但至少在1年内都还有一定的参考意义：
ldpi 如今已绝迹，不用考虑
mdpi [320x480](市场份额不足5%，新手机不会有这种倍率，屏幕通常都特别小)
hdpi [480x800、480x854、540x960](早年的低端机，屏幕在3.5英寸档位;如今的低端机，屏幕在4.7-5.0英寸档位)
xhdpi [720x1280](早年的中端机，屏幕在4.7-5.0英寸档位;如今的中低端机，屏幕在5.0-5.5英寸档位)
xxhdpi [1080x1920](早年的高端机，如今的中高端机，屏幕通常都在5.0英寸以上)
xxxhdpi [1440x2560](极少数2K屏手机，比如Google Nexus 6)
自然地，以1倍的mdpi作为基准。像素密度更高或者更低的设备，只需乘以相应的倍率，就能得到与基准倍率近似的显示效果。
不过需要注意的是，Android设备的'逻辑像素尺寸并不统一。比如两种常见的屏幕480x800和1080x1920，它们分别属于hdpi和xxhdpi。除以各自倍率1.5倍和3倍，得到逻辑像素为320x533和360x640。很显然，后者更宽更高，能显示更多内容。所以，即使有倍率的存在，各种Android设备的显示效果仍然无法做到完全一致。
单位
不难发现，真正决定显示效果的，是逻辑像素尺寸。为此，iOS和Android平台都定义了各自的逻辑像素单位。iOS的尺寸单位为pt，Android的尺寸单位为dp。说实话，两者其实是一回事。
单位之间的换算关系随倍率变化：
1倍：1pt=1dp=1px(mdpi、iPhone 3gs)
1.5倍：1pt=1dp=1.5px(hdpi)
2倍：1pt=1dp=2px(xhdpi、iPhone 4s/5/6)
3倍：1pt=1dp=3px(xxhdpi、iPhone 6)
4倍：1pt=1dp=4px(xxxhdpi)
单位决定了我们的思考方式。在设计和开发过程中，应该尽量使用逻辑像素尺寸来思考界面。设计Android应用时，有的设计师喜欢把画布设为1080x1920，有的喜欢设成720x1280。给出的界面元素尺寸就不统一了。Android的最小点击区域尺寸是48x48dp，这就意味着在xhdpi的设备上，按钮尺寸至少是96x96px。而在xxhdpi设备上，则是144x144px。
无论画布设成多大，我们设计的是基准倍率的界面样式，而且开发人员需要的单位都是逻辑像素。所以为了保证准确高效的沟通，双方都需要以逻辑像素尺寸来描述和理解界面，无论是在标注图还是在日常沟通中。不要再说“底部标签栏的高度是96像素，我是按照xhdpi做的”这样的话了。
Web怎么办
移动端页面的绝对单位仍然是px，至少代码里这么写，但它的道理也和app一样。由于像素密度是设备本身的固有属性，它会影响到设备中的所有应用，包括浏览器。前端技术可以善加利用设备的像素密度，只需一行代码，浏览器便会使用app的显示方式来渲染页面。根据像素密度，按相应倍率缩放。
以iPhone 5s为例，屏幕的分辨率是640x1136，倍率是2。浏览器会认为屏幕的分辨率是320x568，仍然是基准倍率的尺寸。所以在制作页面时，只需要按照基准倍率来就行了。无论什么样的屏幕，倍率是多少，都按逻辑像素尺寸来设计和开发页面。只不过在准备资源图的时候，需要准备2倍大小的图，通过代码把它缩成1倍大小显示，才能保证清晰。
实际应用
大家最关心的还是实际运用，画布该怎么设置。我们就iOS、Android、Web三个平台来分别梳理一下。不过在这之前，我要为使用PS进行设计的朋友介绍一个小技巧。
之前我说过，我们要以逻辑像素尺寸来思考界面。体现到设计过程中，就是要把单位设置成逻辑像素。打开PS的首选项——单位与标尺界面，把尺寸和文字单位都改成点(Point)。这里的点也就是pt，无论设计iOS、Android还是Web应用，单位都用它。当然，各平台单位名称还是要记住的。这里我们用的只是它的原理，不用在意名称。
要调节倍率，则通过图像大小里的DPI来控制。这个DPI，其实就是PPI，像素密度。有个常识大家都知道，屏幕上的设计DPI设成72，印刷品设计DPI设成300。为什么是这两个数字?
首先说300，这和人眼的分辨能力有关。由于1英寸是固定长度，每1英寸有多少个像素点决定了画质清晰程度。之前说过，这就是像素密度，也就是DPI。DPI达到300以上，其细腻程度就会给人真实感，像真实世界中的物件。相反，DPI只有10的话，在你一个食指指节大小的长度内只有10个像素，这明显就是马赛克了。所以印刷品要设成300，才能保证清晰。
再说72，这有一定的历史原因。最早的图形设计是在mac电脑上进行的，mac本身的显示器分辨率就是72。PS中把图像DPI也设成72，就能保证屏幕上显示的尺寸和打印尺寸相同，便于设计。72的PC显示器分辨率逐渐成为一种默认的行业标准，这套规则就这么沿用下来。
现在回到正题，我们怎么通过DPI来调节倍率?既然屏幕本身的分辨率是72，DPI设成72刚好是1倍尺寸，那设成72的两倍就是倍率为2的屏幕了，就这么简单。
下面来看看3个平台各自的画布设置：
iPhone
iPhone的屏幕尺寸各不相同，我说的是逻辑像素尺寸，这确实是让人很头疼的事情。如果想用一套设计涵盖所有iPhone，就要选择逻辑像素折中的机型。
从市场占有率数据来看，目前最多的是iPhone5/5s的屏幕。倍率为2，逻辑像素320x568。上升势头最猛，未来有望登上第一的是iPhone 6的屏幕。倍率为2，逻辑像素375x667。
按照这两种尺寸来设计，都是比较主流的做法。可以兼顾短一些的iPhone 4s，大一点的6 plus也不会过于空旷。
不过在切图的时候要注意，由于iPhone 6 plus的3倍图是由2倍图放大而来，所以位图要注意保证清晰。
Android
都说Android碎片化严重，但它现在反而比iOS好处理。因为如今的Android屏幕逻辑像素已经趋于统一了：360x640，就看你设成几倍了。想以xhdpi为准，就把DPI设成72x2=144。想以xxhdpi为准，就把DPI设成72x3=216。
对于那些比较老的低端机，宽度是480px的那批，画面确实会小一些，显示内容会更少。稍微留意一下，重要内容尽量保持在界面中上部分。
当然，这些机型不出一年就会被边缘化，基本淘汰。现在能运转的也是当作功能机在用，软件多了必卡无疑，用户体验无从谈起。不作考虑也是OK的。
Web
手机端网页就没有统一标准了，比较流行的做法是按照iPhone 5的尺寸来设计。倍率2，逻辑像素320x568。
这样的做法比较实在，倍率2的屏幕无论在iOS还是Android方面都是主流，而且又是2倍屏幕中逻辑像素最小的。所以图片的尺寸可以保持在较小的水平，页面加载速度快。当然，缺点就是在倍率3的设备上看，图片不是特别清晰。
如果追求图片质量，愿意牺牲加载速度，那么可以按照最大的屏幕来设计。也就是iPhone 6 plus的尺寸，倍率3，逻辑像素414x736。
总结
移动端的尺寸比PC端复杂，关键就在倍率。但也正因为倍率的存在，把大大小小的屏幕拉回到同一水平线，得以保证一套设计适应各种屏幕。站在这条水平线的角度看，会发现它很好理解。
㈦ 如何移动桌面上web项目或调整其大小
首先确定你的 web项目没有锁定(桌面--右击--排列图标）
然后将鼠标移到图片的顶上，出现控制条 OK啦
㈧ web前端 移动端和pc端显示比例一般都要怎么调整
如果你自己拿不准的话用一套ui框架是比较好的，他能同时兼容各个屏幕的样式，如果你不想用框架，那么你要想想你的网页是否适合做PC和手机的兼容
㈨ 手机移动web开发 如何做到控制页面大小不变
手机的屏幕有大有小，移动web最好做成响应式布局，也就是自适应屏幕，没有固定宽高，这样的话，在所有手机上都可以正常显示。ico的话可以使用字体图标，现在大部分手机浏览器都支持html5和css3的。
Web前端开发工程师是一个很新的职业，在国内乃至国际上真正开始受到重视的时间不超过7年。Web前端开发是从网页制作演变而来的，名称上有很明显的时代特征。在互联网的演化进程中，网页制作是Web 1.0时代的产物，那时网站的主要内容都是静态的，用户使用网站的行为也以浏览为主。
㈩ 移动Web怎么做屏幕适配
业内比较流行的做法（参考阿里的flexible），有以下要点： 1、设置viewport为设备宽度（这里不一定，但目前先这样足矣） 2、将viewport分成10rem，并计算出1rem在当前浏览器的像素值，把它赋予html标签的font-size（分成10rem只是为了方便计算而已） 3、写CSS代码时，遇到要适配的地方，比如width，margin，padding等，就不要再用px了，改成用rem JS和Html代码如下： CSS代码做了类似如下的修改： 运行结果如下：边距和头像图片都随屏幕变化而变化了。