如果你要构建移动网站，那么本文可以帮你选择合适的技术方案。本文并没有具体描述如何去开发，只是介绍应该如何选择正确的方法。在开始之前我们有必要明确一下这次实践的目标。一
般来说，想要构建网站的人可分为两大类：
改造现有的网站，使其可以通过移动设备访问；
从头开始构建全新的移动网站。
这两种目标是截然不同的，所以相应的技术方法也不同。前者的目标可以归结为：构建一个无缝缩放的网站。这样的网站可以在不同尺寸的屏幕上正常显示，而网站原有的结构、导航等
则保持不变；后者的目标是构建一个全新的移动网站，以满足移动用户的需求（无论用户是否处于运动状态），这需要不同的视图设置和交互设计。
为了区分现有的不同技术，本文使用了术语：“无缝缩放”和“内容自适应”。前者的意思是当现有的网站面向不同分辨率的屏幕时具有更大的灵活性和适应性；后者的意思是为移动用户量
身定做。
内容自适应技术的演变
21世纪的头 10 年里，移动 Web 和桌面 Web 之间的区别还是很明显的。当时只有一种技术可以实现不同设备之间的内容适应——即在服务器端进行内容适应。这就意味着服务器要
对设备进行识别以切换内容保证其正确显示。
实际上，服务器端的内容适应技术很重要。如果没有此技术，Web 上的内容将无法在设备上正确显示。然而，在近 5 年情况变得更加复杂了。各种手机、平板电脑的出现使得移动浏览
器与桌面浏览器之间的功能差异越来越小了。即使是最普通的功能手机也内嵌了功能丰富的浏览器。这就导致了三种结果：
移动设备和桌面设备之间将不再有明显区别。
既然这么多的设备都具有了功能强大且支持 JavaScript 的浏览器，也就有越来越多的新技术为这些新设备提供内容适应服务。
有些人质疑内容适应技术的必要性，理由是智能手机几乎可以显示所有网站的内容。
此表可能存在争议，因为，为了简洁起见，一些复杂的及细微的特征在表中没有表现出来。
1、响应式设计
响应式设计这个术语之所以如此流行是因为 Ethan Marcotte 于 2010 年 5 月份在超具影响力的网站A List Apart 上发表的一篇文章及其 2011 年发表的书籍《Responsive Web
Design》中都极力推广该术语。Ethan 介绍了一系列的设计原则和技术，能够保证网站在任何情况下都可以在移动设备上运行。实际上，流畅的设计一直是资深 Web 开发人员的追求目标
，但是 Ethan 所介绍的是一套具体的技术，大多数 Web 开发者都可以在不使用其它新工具的情况下轻松实现这些技术，这就是该解决方案的诱人之处。
上述的响应式设计是基于以下三种技术的：
流体网格——确保底层页面的网格可以很好地适应于各种尺寸的屏幕。
响应式图像——图像在可变网格中可以正确显示。
CSS media queries——所使用的 CSS 样式可适用于不同分辨率、不同类型的设备。
这些技术使得一个 HTML 页面可以运行于不同设备，达到我们所期望的结果：采用这种技术所构建的网站可以很好地支持旧版本的浏览器，可以在所有桌面浏览器及大多数智能手机上
运行。Media Queries 上有很多这样的例子。(注：Ethan 那本书的发行者 Jeffrey Zeldman 后来指出，响应式设计不应仅仅局限于 Ethan 所介绍的技术，而应该包含所有可以实现这一
目标的方法。)
响应式设计这一术语只是该技术的标签。该技术包含了一整套的设计原则，以实现无缝缩放功能。可是，响应式设计容易与移动 Web 相混淆，导致开发者产生错觉，他们会以为只要使
用了响应式设计的网站就是对移动用户友好的网站，就完成了移动网站的开发。当然了，做一个反应速度快的网站是好事，但缺少一个充分发挥移动设备本身功能的解决方案。
说实话，Ethan 并不提倡用这种方法来构建移动网站，他有一个很明智的建议：要根据具体项目来选择合适的方法。他在书中指出：“最重要的是，Web 响应式设计不是用来代替移动
网站的。响应式设计只是一个设计理念，一个前端的开发策略。既然是开发策略，这就意味着要根据具体项目来做出正确的评估。
作为一种实现移动网站的方法，响应式设计存在以下三个问题：
只可以做到无缝缩放，而没有实现内容自适应。从移动领域的角度来看，这种技术效率低下。（即使图片在某移动设备上不能全屏查看或者根本无法显示，也需要将整个图片下载下来。）
由于响应式设计理念中，HMTL 代码是要传递到所有设备中的（无论大小），这就使得它不能很好地支持低端设备。波士顿环球报网站上大肆宣扬：“所谓的响应式设计杰作，在主流手机（
如：Motorola RAZR、Nokia 6100）上却不能很好地运行，甚至根本无法运行。”
不能很好地处理实时数据，所以用户体验不够好。
响应式设计虽然可以实现无缝缩放，但是所支持的用例很有限，并不是一个很好的移动 Web 解决方案。
2、Mobile-First 响应式设计
自从 Ethan 的文章及著作发表以来，许多人指出，如果将响应式设计反过来用可能会更合理：如果你设计的网页风格默认就是对移动用户友好的，那么一些响应式设计问题也就不存在
了。特别地，避免下载不必要的大图片问题就可以由该方法来解决。目前，这种技术的最佳实践是：首先为所有设备提供合适的图片，然后用这些图片来代替大图片。来自 The Filament
Group 的 Scott Jehl 已经做到了这点。
Mobile-First 设计理念的另一个优点是：该设计理念可以作为一个楔子，使得设计人员找到了一个充分的理由来清除多年来在桌面网站上积累下来的不必要的混乱。因为按照 Mobile-
First 的设计理念，这些混乱是必须要被剔除的。
Mobile-First 响应式设计是对原有技术的重大革新，但也存在以下问题：
只实现了无缝缩放，而没有实现内容自适应。
桌面网站需要从头开始重新设计。也许你认为这反倒是件好事。
总之，如果你的目标是构建移动网站，Mobile-First 响应式设计是唯一实用的响应式设计理念，因为从低端设备到桌面浏览器都可以使用该方案。
3、渐进增强（PE）
渐进增强（PE）是一个新近流行的有关内容适应方面的术语。最初是在约 10 年前由 Steven Champeon 和 Nick Finck 在他们的文章《Inclusive Web Design Future》中提出来的
，该文章发表于 SXSW。渐进增强的核心思想是：在单一的网页上实现 JavaScript 增强逻辑，使其能够服务于所有类型的设备。如果设备过于简陋，则 JavaScript 可能得不到运行或报错
，因此用户体验会很差；如果是智能设备或桌面浏览器，则 JavaScript 会逐渐向页面增加新的功能，充分发挥设备的硬件功能。理论上讲，分层是没有上限的，可以逐渐从功能手机浏览器
渐渐过度到台式电脑浏览器。
PE 的诱人之处是很明显的：它可以满足所有类型的设备（包括低端设备），因为它是故障安全的解决方案；高端设备的功能又不会因为这个“最低限度共同点”而受到限制。刚刚发布的
jQuery Mobile 库就用到了 PE 解决方案，实际上，PE 将内容适应逻辑从服务器端移到了客户端。这种方案存在两个问题：
该技术的核心“渐进增强”的执行是需要一定时间的，所需时间的长短主要取决于设备的硬件性能，当然也可能与网速有关。举个例子，某些型号的黑莓手机理论上是支持 JavaScript 的，但
实际上运行速度太慢以至于没有什么实际用途。
和以往的技术一样，该技术中多个用例共用同一个基本的 HTML 文件，这在功能上似乎很受限。
实际上，PE 技术的最佳应用是消除移动设备之间的差异，而不是作为一个综合的内容适应解决方案。
4、服务器端内容适应技术
服务器端内容适应技术早在 12 年前移动 Web 刚刚出现时就开始使用了。该技术依赖于设备检测库或依赖于安装在 Web 服务器（或远程 Web 服务）上的数据库，检测访问网站的设
备并返回设备的性能信息。服务器端可以根据这些信息对页面进行微调，使之很好的适应设备的性能。由于服务端内容适应技术中包含了设备检测技术，所以有时也被称为“浏览器嗅探”。尽
管也有不少反对者，但浏览器嗅探确实很稳定很精准，据统计，该解决方案检测设备的精准度达到了 99.5% 以上。
该技术的有效性不言自明：它仍然是迄今为止最常用的内容适应技术，几乎所有重视移动用户体验的知名互联网公司都在使用该技术，包括 Google、Facebook、Amazon、Youtube
、Ebay 以及 Yahoo。你很难找到一个没使用服务器端内容适应技术而又取得成功的移动网站。
然而，服务器端内容适应技术也不是没有缺点。其缺点主要有以下两点：
所用到的设备检测技术需要 Web 开发者不断进行更新，并且大多数设备检测技术都是商业化的。
不能很好地使用浏览器的实时数据（例如，GPS 定位或者设备当前的方向）以帮助 Web 开发者更好地服务于用户。
目前，WURFL 和 DeviceAtlas 是设备检测方面的领军产品，这两款产品都是商业化的。
5、混合方法
最后要介绍的技术是混合方法，该方法把服务器端内容适应技术与渐进增强技术结合在了一起。这种技术的工作原理是，当服务器收到客户端的页面请求时，服务器端首先向客户端提交
一个基于服务器端内容适应原则的初始页面，然后由客户端的 JavaScript 来捕获设备的性能信息并返回给服务器端，服务器端根据所捕获的信息对发向该设备的后续页面进行微调，使页面
更好地适应该设备。
该技术首先是由 Bryan Rieger 和 Stephanie Rieger 发布的，他们在 yiibu.com 上很详细地记录了他们探索各种内容适应技术的曲折而漫长的道路。有趣的是，他们在尝试该技术之
前几乎已经尝试过了所有上文已经介绍过的技术。
他们使用了设备检测技术和浏览器属性“隐性数据库”，还使用了 modernizr-like JavaScript 脚本。在此不详述细节，建议大家看看他们的介绍：“适应：为什么响应式设计始于服务器
端？”
这种混合方法对用户端和服务器端来说都是最合适的方式——既可以利用高速的服务器端内容适应，又可以利用来源于设备自身的属性来调整页面。用户可以得到一个初始的适合当前设
备的页面，又不会有什么性能开销，并且后续页面会根据此页面自动进行调整。但是，这种方法也存在两个缺点：
实现起来相对复杂，这点 Riegers 两位也欣然承认。复杂性源于以下两个因素：复杂性源于以下两个因素：1）需要建立一个数据库以保存浏览器的属性；2）需要写 JavaScript 代码，以
实现从浏览器中提取属性并存入数据库。
首次访问服务器时，在用户得到有用信息之前，需要一个从浏览器到服务器之间的往返时间的延迟开销。在后续请求中可以使用 cookies 来消除该延迟。
总结：
所有可用的技术都介绍过了，接下来你会如何选择呢？当然，要视具体情况而定。笔者认为，任何以“单个 HTML 文档来满足所有设备”为前提的技术，本是就是有缺陷的，就如同：大
多数的电视内容不是多次播放的电影，大多数的网站也不是纸质报纸的完美复制品。用户对某些类型的网站（例如博客）的交互需求是有限的，这样单一的一套交互方案是可以同时满足桌面
与移动用户的。但是，在更一般的情况下，如果也让桌面与移动用户共用同一套方案，最好的结果是：功能严重受限； 最坏的结果是：根本无法运行。
正如一位 CTO 所说：“客户端功能检测如何将一个航空公司的介绍性网站转变成为移动电子登机服务呢？渐进增强理念是以‘所有用户的需求都相同，只是界面布局不同’的假设为前提的
。”
如果航空公司所构建的移动网站和桌面网站采用相同的基本模板，这样真的可行吗？如果你真的想提供一流的移动用户体验，那么响应式设计和渐进增强将得不到很好的体现。你在
Alexa 网站上快速看一眼就会知道，想要提供优质的移动用户体验需要对 HTML 进行量身定做，而不是简单地调整像素和 div 元素。
总之，如果你的网站只是运行在一些高端移动设备上，并且你不会特意去照顾某些移动 Web 用户，那么你可以采用响应式设计方案，或者 Mobile-First 响应式设计方案。如果你的网
站元素不太复杂，那么这两种方案会很奏效。
如果你想提供一个全新的移动用户体验设计或者你想满足所有的移动设备，那么你只能使用服务器端内容适应方案或混合方法。这也是所有知名互联网公司都采用这种方案的原因。
上述观点都是基于对新媒体的信仰：移动 Web 是一种新媒体，绝不是旧媒体的缩略版本；是一种功能强大的媒体，而不是功能弱小的媒体；是一种全新的 Web，而不是合成的杂牌
Web。只有这样看待和使用该新媒体，它才能得到最合理、最成功的应用
