随着3G的普及，越来越多的人使用手机上网。
移动设备正超过桌面设备，成为访问互联网的***常见终端。于是，网页设计师不得不面对一个难题：如何才能在不同大小的设备上呈现同样的网页
手机的屏幕比较小，宽度通常在600像素以下；PC的屏幕宽度，一般都在1000像素以上（目前主流宽度是1366×768），有的还达到了2000像素。同样的内容，要在大小迥异的屏幕上，都呈现出满意的效果，并不是一件容易的事。
很多网站的解决方法，是为不同的设备提供不同的网页，比如专门提供一个mobile版本，或者iPhone / iPad版本。这样做固然保证了效果，但是比较麻烦，同时要维护好几个版本，而且如果一个网站有多个portal（入口），会大大增加架构设计的复杂度。
于是，很早就有人设想，能不能"一次设计，普遍适用"，让同一张网页自动适应不同大小的屏幕，根据屏幕宽度，自动调整布局（layout）
一、"自适应网页设计"的概念
2010年，Ethan Marcotte提出了"自适应网页设计"（Responsive Web Design）这个名词，指可以自动识别屏幕宽度、并做出相应调整的网页设计。
他制作了一个范例，里面是《福尔摩斯历险记》六个主人公的头像。如果屏幕宽度大于1300像素，则6张图片并排在一行
如果屏幕宽度在600像素到1300像素之间，则6张图片分成两行。
如果屏幕宽度在400像素到600像素之间，则导航栏移到网页头部。
如果屏幕宽度在400像素以下，则6张图片分成三行。
mediaqueri.es上面有更多这样的例子。
这里还有一个测试小工具，可以在一张网页上，同时显示不同分辨率屏幕的测试效果，我推荐安装。
二、允许网页宽度自动调整
"自适应网页设计"到底是怎么做到的？其实并不难。
首先，在网页代码的头部，加入一行viewport元标签。
<meta name="viewport" content="width=device-width, initial-scale=1" />
viewport是网页默认的宽度和高度，上面这行代码的意思是，网页宽度默认等于屏幕宽度（width=device-width），原始缩放比例（initial-scale=1）为1.0，即网页初始大小占屏幕面积的100%。
所有主流浏览器都支持这个设置，包括IE9。对于那些老式浏览器（主要是IE6、7、8），需要使用css3-mediaqueries.js。
<!--[if lt IE 9]>
<script src=https://www.yuntask.com/news/"http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script>
<![endif]-->
三、不使用***宽度
由于网页会根据屏幕宽度调整布局，所以不能使用***宽度的布局，也不能使用具有***宽度的元素。这一条非常重要。
具体说，CSS代码不能指定像素宽度：
width:300px;
只能指定百分比宽度：
width: 98%;或者width:auto;
四、相对大小的字体
字体也不能使用***大小（px），而只能使用相对大小（em）。
body {
font: normal 100% Helvetica, Arial, sans-serif;
}
上面的代码指定，字体大小是页面默认大小的100%，即16像素。
h1 {
font-size: 1.5em;
}
然后，h1的大小是默认大小的1.5倍，即24像素（24/16=1.5）。
small {
font-size: 0.875em;
}
small元素的大小是默认大小的0.875倍，即14像素（14/16=0.875）。
五、流动布局（fluid grid）
"流动布局"的含义是，各个区块的位置都是浮动的，不是固定不变的。
.main {
float: rightright;
width: 70%;
}
.leftBar {
float: left;
width: 25%;
}
float的好处是，如果宽度太小，放不下两个元素，后面的元素会自动滚动到前面元素的下方，不会在水平方向overflow（溢出），避免了水平滚动条的出现。
另外，***定位（position: absolute）的使用，也要非常小心。
六、选择加载CSS
"自适应网页设计"的核心，就是CSS3引入的Media Query模块。
它的意思就是，自动探测屏幕宽度，然后加载相应的CSS文件。
<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 400px)" href=https://www.yuntask.com/news/"tinyScreen.css" />
上面的代码意思是，如果屏幕宽度小于400像素（max-device-width: 400px），就加载tinyScreen.css文件。
<link rel="stylesheet" type="text/css"
media="screen and (min-width: 400px) and (max-device-width: 600px)"
href=https://www.yuntask.com/news/"smallScreen.css" />
如果屏幕宽度在400像素到600像素之间，则加载smallScreen.css文件。
除了用html标签加载CSS文件，还可以在现有CSS文件中加载。
@import url("tinyScreen.css") screen and (max-device-width: 400px);
七、CSS的@media规则
同一个CSS文件中，也可以根据不同的屏幕分辨率，选择应用不同的CSS规则。
@media screen and (max-device-width: 400px) {
.column {
float: none;
width:auto;
}
#sidebar {
display:none;
}
}
上面的代码意思是，如果屏幕宽度小于400像素，则column块取消浮动（float:none）、宽度自动调节（width:auto），sidebar块不显示（display:none）。
八、图片的自适应（fluid image）
除了布局和文本，"自适应网页设计"还必须实现图片的自动缩放。
这只要一行CSS代码：
img { max-width: 100%;}
这行代码对于大多数嵌入网页的视频也有效，所以可以写成：
img, object { max-width: 100%;}
老版本的IE不支持max-width，所以只好写成：
img { width: 100%; }
此外，windows平台缩放图片时，可能出现图像失真现象。这时，可以尝试使用IE的专有命令：
img { -ms-interpolation-mode: bicubic; }
或者，Ethan Marcotte的imgSizer.js。
addLoadEvent(function() {
var imgs=document.getElementById("content").getElementsByTagName("img");
imgSizer.collate(imgs);
});
不过，有条件的话，***好还是根据不同大小的屏幕，加载不同分辨率的图片。有很多方法可以做到这一条，服务器端和客户端都可以实现。
Web app向Native app发起挑战已经有好些年了。以各大公司志向宏大的操作系统为例就有：名噪一时现在栖身于LG TV的WebOS，Google 力推在教育领域还算混的不错的ChromeOS， Samsung和Intel主导但是一直雷声大雨点小的Tizen, Mozilla面向低端设备的FirefoxOS。还有各种开发、打包web/hybrid应用的产品：Cordova, Crosswalk，nw.js，Electron。它们也许在各自领域有所成功，但整体的现状和处境很难说web app对native app的世界造成了足够威胁。
WEB APP和NATIVE APP的设计差异和发展趋势
但Web app也在不断反思和演进，近来一系列技术革新与发展让web app成为操作系统头等公民的目标变得不同以往的清晰。让我们看看“扬长避短”之后的web app是不是真的可以开始跟native app掰掰手腕了。
Web app之长首先源自web。Web不是于某家藩篱之内的封闭花园，它是一个任意提供了标准支持的终端都可以平等访问的野蛮生长的开放大草原。Web协议栈让全世界的网页成为即时更新并通过URL相互联系的网络。回顾W3C Packaged App(Widget)标准和SysApps(System Application Working Group)的衰落很大程度上也在于放弃了web的这些核心竞争力。
Web app之长也源自HTML，CSS，JavaScript。它们虽然招到很多诟病，但它们也是***广泛使用的开发工具。而新的ES6，Web Components标准也在让它们变得具有更强的开发、表达能力。当然HTML的语义话表达也是搜索的基石之一，这让web app易于被索引和发现。
Web app之短首先在于能力的缺失。虽然有Cordova之类工具架起和native API之间桥梁，但打包之后web app的“长”呢？所以web标准化组织一方面在努力提供各种硬件访问的接口。另一方面提出了Service Worker来解决web app本身存在的无法通过简单增加API来处理的关键问题：
其一，web app缺少在后台运行的能力，Web Worker可以在后台运行，但是它依赖于页面，不能在页面不存在的时候运行；
其二，通过URL访问的web 页面是彼此孤立的，虽然可以通过Web Messaging来相互通信，但是这是一种弱联系，并需要消息传递之间的页面有关联。
WEB APP和NATIVE APP的设计差异和发展趋势
Service Worker通过一个新的web app编程模型和一套API统一解决了这两个问题。简单的说service worker就是一个生命周期短暂的、事件驱动的后台线程，它处理来自系统和被其控制的页面的事件。目前可以通过Service Worker实现的功能包括：替代坑坑洼洼的Application Cache的可编程离线缓存，Push Notification（消息推送），Background Sync（后台同步）。Service Worker能成为诸多需要跨越页面处理能力的入口。比如如果你怀念Web Intents的话，Service Worker也许也能成为它复活的平台：通过Service Worker注册某个intent事件，在事件到来时worker被启动，针对不同的intent worker可以选择打开不同的页面或重新聚焦某个已经打开的页面。
辅助以W3C Manifest标准，web app有了理论上足以超脱浏览器成为系统一部分的能力。
Web app之短也在性能。当然性能的问题不在于比较和native app跑分一较高下，而在于用户体验。在JavaScript方面各个浏览器厂商一直在挖掘更高的性能，而近日多个巨头同时参与的Web Assembly的提出更让业界更是充满期望。请想象一下，浏览器直接执行的游戏引擎代码是优化过的二进制中间表达形式(IR)，甚***是可能是缓存下来的后端转换过的机器码。另外在渲染引擎方面，60FPS的性能也一直是近一年来Blink的主要目标，相信Edge、WebKit等也不会被拉在后面。
“扬长避短”之后的web app应该以一种怎样的形式进入系统并成为系统一员呢？Alex Russell***近就提出了一种渐进式web app的理念，而且这一理念已经可以在Android上看到萌芽。
在Android Chrome上通过搜索或者链接发现了并使用了某个页面。当这个页面或者某个域范围内的页面在一定时间内被多次访问后，浏览器会认为这些网页是可以被升级成app的，并弹出对话框让用户选择是否安装这个web app到系统。这个web app可以享有和native app类似的权利，比如主界面启动，独立的应用选择栏。目前在Chrome上指定了只有使用了Service Worker 和 Manifest 的网页能够升级成web app被安装，用来保证app的质量。
这种渐进式web app的理念在我看来可以用人和人的交往来类比，一个人从陌生，到熟悉，再到相信。展开想象，是不是web app的权限管理也可以渐进呢？ 安全、隐私级别高的API访问控制会随着你对这个app的相信程度来适配。
各种web操作系统和hybrid打包工具已经向native app主导的世界发起了挑战，随着web技术的进一步成熟，open web也逐渐能通过渐进的方式像native app一样成为系统的一部分。我期望着某***自由、平等、开放的web能成为***的***平台。
WEB APP、HYBRID APP与NATIVE APP的设计差异
WEB APP和NATIVE APP的设计差异和发展趋势
编者按：这3类主流应用你都了解吗？设计师除了要有视觉功夫，对不同形式的APP也应当了然于胸，今天百度的同学写了一篇非常全面的总结，帮你迅速搞定3类主流APP的设计方法，附带一大波避雷针，带你巧妙跳过APP设计的雷区，涨姿势是分分钟刻不容缓的事咯！
目前主流应用程序大体分为三类：Web App、Hybrid App、 Native App。
WEB APP和NATIVE APP的设计差异和发展趋势
一、Web App、Hybrid App、Native App 纵向对比
首先，我们来看看什么是 Web App、Hybrid App、 Native App。
1. Web APP
Web App 指采用Html5语言写出的App，不需要下载安装。类似于现在所说的轻应用。生存在浏览器中的应用，基本上可以说是触屏版的网页应用。
优点
（1）开发成本低，
（2）更新快，
（3）更新无需通知用户，不需要手动升级，
（4）能够跨多个平台和终端。
缺点：
（1）临时性的入口
（2）无法获取系统级别的通知，提醒，动效等等
（3）用户留存率低
（4）设计受限制诸多
（5）体验较差
2. Hybrid App
Hybrid APP指的是半原生半Web的混合类App。需要下载安装，看上去类似Native App，但只有很少的UI Web View，访问的内容是 Web 。
例如Store里的新闻类APP，视频类APP普遍采取的是Native的框架，Web的内容。
Hybrid App 极力去打造类似于Native App 的体验，但仍受限于技术，网速，等等很多因素。尚不***。
3. Native App
Native APP 指的是原生程序，一般依托于操作系统，有很强的交互，是一个完整的App，可拓展性强。需要用户下载安装使用。
优点：
（1）打造***的用户体验
（2）性能稳定
（3）操作速度快，上手流畅
（4）访问本地资源（通讯录，相册）
（5）设计出色的动效，转场，
（6）拥有系统级别的贴心通知或提醒
（7）用户留存率高
缺点：
（1）分发成本高（不同平台有不同的开发语言和界面适配）
（2）维护成本高（例如一款App已更新***V5版本，但仍有用户在使用V2， V3， V4版本，需要更多的开发人员维护之前的版本）
（3）更新缓慢，根据不同平台，提交–审核–上线 等等不同的流程，需要经过的流程较复杂
二、Web App、Hybrid App、Native App 技术特性
WEB APP和NATIVE APP的设计差异和发展趋势
由上图可见，Web APP 的开发基于Html5语言。而Html5语言本身又有着不可避免的局限性。正是这些局限性的存在，使得Web App在体验中要逊于Native App。
三、Web App受限制因素及设计要点
WEB APP和NATIVE APP的设计差异和发展趋势
相比Native App，Web App体验中受限于以上5个因素：网络环境，渲染性能，平台特性，受限于浏览器，系统限制。
1. 网络环境，渲染性能
Web APP对网络环境的依赖性较大，因为Web APP中的H5页面，当用户使用时，去服务器请求显示页面。如果此时用户恰巧遇到网速慢，网络不稳定等其他环境时，用户请求页面的效率大打折扣，在用户使用中会出现不流畅，断断续续的不良感受。同时，H5技术自身渲染性能较弱：对复杂的图形样式，多样的动效，自定义字体等的支持性不强。
因此，基于网络环境和渲染性能的影响，在设计H5页面时，应注意以下几点：
简化不重要的动画/动效
简化复杂的图形文字样式
减少页面渲染的频率和次数
从下图移动Web版 jing.fm和Native版jing对比后可以看出：Web APP首页去除冗余的功能，回溯本源，只给用户提供了jing.fm***初的本质需求——电台。既符合H5精简功能又达到了突出核心功能的设计原则。无疑给用户眼前一亮的气息。
正如书中《瞬间之美》的一个核心观点：重要的并不是我们提供的信息量有多大，而是我们能否给他们提供真正需要的信息。
用户是否真的在意准确的信息？这篇文章给你另一个全新的视角！
WEB APP和NATIVE APP的设计差异和发展趋势
WEB APP和NATIVE APP的设计差异和发展趋势
再如：百度***新推出的直达号，以良子健身为例：
从Native App和Web App（百度直达号）的对比中，我们可以看出Native良子以九宫格的形式展现，且属于双重导航，功能入口太多；弊端是用户不知道聚焦在哪里，分散用户的注意力。而Web版良子整合并减少了导航的入口，增强用户的专注度；界面清爽，整洁，很好地传达了良子本身的寓意——轻松、愉悦、休闲、舒适。
WEB APP和NATIVE APP的设计差异和发展趋势
2. 受限于浏览器
通常Web App生存于浏览器里，宿主是浏览器。不同的浏览器自身的属性不尽相同，如：浏览器自带的手势，页面切换方式，链接跳转方式，版本兼容问题等等。
例如下图：UC 浏览器和百度浏览器自身支持手势切换页面。手指从左侧滑动页面，返回***上一级。百度手机助手H5页面，顶部Banner支持手势左右滑动切换。这一操作与浏览器自身手势是冲突的。
WEB APP和NATIVE APP的设计差异和发展趋势
再如，基于浏览器的Web APP在打开新的模块中的页面时，大多会新开窗口来展现。例如用户在使用购物类APP时，浏览每日精选模块时，每当打开新的商品时，默认新开一个窗口。这样的优劣势显而易见：优势是能够记录用户浏览过的痕迹，浏览过的商品，以便后续横向对比；劣势是过多的页面容易使用户迷失在页面中。
正如Google开发手册里描述：当用户打开一个Web App的时候，他们期待这个应用就像是一个单个应用，而不是一系列网页的结合。然而，什么情况下需要跳转页面，什么情况下在当前页面展示则需要设计师细致考量。
WEB APP和NATIVE APP的设计差异和发展趋势
因此，Web App基于浏览器的特性，从设计角度应该遵循以下了两点：
少用手势，避免与浏览器手势冲突。
减少页面跳转次数，尽量在当前页面显示。
3. 系统限制，平台特性
由于Html5语言的技术特性，无法调用系统级别的权限。例如，系统级别的弹窗，系统级别的通知，地理信息，通讯录，语音等等。且与系统的兼容性也会存在一些问题。以上限制通常导致APP的拓展性不强，体验相对较差。例如百度地图：
WEB APP和NATIVE APP的设计差异和发展趋势
Web版地图基于浏览器展现，因此，不能全屏显示地图，给用户的眼界带来局限感；相反，Native 版地图以全屏展现的形式，很好的拓展了用户的视野。整个界面干净简洁，首页去除冗余功能。
在制定路线的体验中，如图：
WEB APP和NATIVE APP的设计差异和发展趋势
Web 版地图耗费的流量大于Native版，且不能预先缓存离线地图。对于地理位置的判断也是基于宿主浏览器，而非Web地图本身。获取路线后，对于更换到达方式，相对来说是不便利的。
相反，Native 版地图，能够直接访问用户的地理位置，能够很清晰的为用户展现App规划的路线，并能轻松的查看多种路线方案，以便做出符合自己的***佳方案。对于切换公交，走路，自驾等路线方式也是只需一键操作。
Native 版地图相对于 Web版地图增加更多情感化，易用的功能，如：能够记录用户的生活轨迹，记录用户的点滴足迹，能够享受躲避拥堵方案等。而Web版地图基于技术框架，很难实现以上功能，从用户体验角度来看，弱于Native版地图。
四、小结
综述所述，在设计Web APP时，应当遵循以下几点：
1. 简化
简化不重要的动画/动效
简化复杂的图形文字样式
2. 少用
少用手势，避免与浏览器手势冲突
少用弹窗
3. 减少
减少页面内容
减少控件数量
减少页面跳转次数，尽量在当前页面显示
4. 增强
增强Loading时的趣味性
增强页面主次关系
增强控件复用性