【五個非常重要的移動Web內容適應設計理念】

英文原文：Mobile web content adaptation techniques

　　譯者：趙建光

　　如果你要構建移動網站，那末本文可以幫你選擇適合的技術方案。本文并沒有具體描寫如何去開發，只是介紹應當如何選擇正確的方法。在開始之前我們有必要明確1下這次實踐的目標。1般來講，想要構建網站的人可分為兩大類：

• 改造現有的網站，使其可以通過移動裝備訪問；
• 從頭開始構建全新的移動網站。
  

　　這兩種目標是截然不同的，所以相應的技術方法也不同。前者的目標可以歸結為：構建1個無縫縮放的網站。這樣的網站可以在不同尺寸的屏幕上正常顯示，而網站原本的結構、導航等則保持不變；后者的目標是構建1個全新的移動網站，以滿足移動用戶的需求（不管用戶是不是處于運動狀態），這需要不同的視圖設置和交互設計。

　　為了辨別現有的不同技術，本文使用了術語：“無縫縮放”和“內容自適應”。前者的意思是當現有的網站面向不同分辨率的屏幕時具有更大的靈活性和適應性；后者的意思是為移動用戶量身定做。

　　內容自適應技術的演化

　　21世紀的頭 10 年里，移動 Web 和桌面 Web 之間的區分還是很明顯的。當時只有1種技術可以實現不同裝備之間的內容適應――即在服務器端進行內容適應。這就意味著服務器要對裝備進行辨認以切換內容保證其正確顯示。

　　實際上，服務器真個內容適應技術很重要。如果沒有此技術，Web 上的內容將沒法在裝備上正確顯示。但是，在近 5 年情況變得更加復雜了。各種手機、平板電腦的出現使得移動閱讀器與桌面閱讀器之間的功能差異愈來愈小了。即便是最普通的功能手機也內嵌了功能豐富的閱讀器。這就致使了3種結果：

• 移動裝備和桌面裝備之間將不再有明顯區分。
• 既然這么多的裝備都具有了功能強大且支持 JavaScript 的閱讀器，也就有愈來愈多的新技術為這些新裝備提供內容適應服務。
• 有些人質疑內容適應技術的必要性，理由是智能手機幾近可以顯示所有網站的內容。
  

　　本文旨在介紹諸多內容自適應技術，說明各技術的優缺點，以供參考。

　　下表列出了現今的主流技術：

此表可能存在爭議，由于，為了簡潔起見，1些復雜的及細微的特點在表中沒有表現出來。

　　1、響應式設計

　　響應式設計這個術語之所以如此流行是由于 Ethan Marcotte 于 2010 年 5 月份在超具影響力的網站A List Apart 上發表的1篇文章及其 2011 年發表的書籍《Responsive Web Design》中都極力推行該術語。Ethan 介紹了1系列的設計原則和技術，能夠保證網站在任何情況下都可以在移動裝備上運行。實際上，流暢的設計1直是資深 Web 開發人員的尋求目標，但是 Ethan 所介紹的是1套具體的技術，大多數 Web 開發者都可以在不使用其它新工具的情況下輕松實現這些技術，這就是該解決方案的誘人的地方。

　　上述的響應式設計是基于以下3種技術的：

• 流體網格――確保底層頁面的網格可以很好地適應于各種尺寸的屏幕。
• 響應式圖象――圖象在可變網格中可以正確顯示。
• CSS media queries――所使用的 CSS 樣式可適用于不同分辨率、不同類型的裝備。
  

　　這些技術使得1個 HTML 頁面可以運行于不同裝備，到達我們所期望的結果：采取這類技術所構建的網站可以很好地支持舊版本的閱讀器，可以在所有桌面閱讀器及大多數智能手機上運行。Media Queries 上有很多這樣的例子。(注：Ethan 那本書的發行者 Jeffrey Zeldman 后來指出，響應式設計不應僅僅局限于 Ethan 所介紹的技術，而應當包括所有可以實現這1目標的方法。)

　　響應式設計這1術語只是該技術的標簽。該技術包括了1整套的設計原則，以實現無縫縮放功能?？墒牵憫皆O計容易與移動 Web 相混淆，致使開發者產生錯覺，他們會以為只要使用了響應式設計的網站就是對移動用戶友好的網站，就完成了移動網站的開發。固然了，做1個反應速度快的網站是好事，但缺少1個充分發揮移動裝備本身功能的解決方案。

　　說實話，Ethan 其實不提倡用這類方法來構建移動網站，他有1個很明智的建議：要根據具體項目來選擇適合的方法。他在書中指出：“最重要的是，Web 響應式設計不是用來代替移動網站的。響應式設計只是1個設計理念，1個前真個開發策略。既然是開發策略，這就意味著要根據具體項目來做出正確的評估。

　　作為1種實現移動網站的方法，響應式設計存在以下3個問題：

• 只可以做到無縫縮放，而沒有實現內容自適應。從移動領域的角度來看，這類技術效力低下。（即便圖片在某移動裝備上不能全屏查看或根本沒法顯示，也需要將全部圖片下載下來。）
• 由于響應式設計理念中，HMTL 代碼是要傳遞到所有裝備中的（不管大?。@就使得它不能很好地支持低端裝備。波士頓環球報網站上大肆宣揚：“所謂的響應式設計杰作，在主流手機（如：Motorola RAZR、Nokia 6100）上卻不能很好地運行，乃至根本沒法運行?！?/li>
• 不能很好地處理實時數據，所以用戶體驗不夠好。
  

　　響應式設計雖然可以實現無縫縮放，但是所支持的用例很有限，其實不是1個很好的移動 Web 解決方案。

　　2、Mobile-First 響應式設計

　　自從 Ethan 的文章及著作發表以來，許多人指出，如果將響應式設計反過來用可能會更公道：如果你設計的網頁風格默許就是對移動用戶友好的，那末1些響應式設計問題也就不存在了。特別地，避免下載沒必要要的大圖片問題就能夠由該方法來解決。目前，這類技術的最好實踐是：首先為所有裝備提供適合的圖片，然后用這些圖片來代替大圖片。來自The Filament Group 的 Scott Jehl 已做到了這點。

　　Mobile-First 設計理念的另外一個優點是：該設計理念可以作為1個楔子，使得設計人員找到了1個充分的理由來清除多年來在桌面網站上積累下來的沒必要要的混亂。由于依照 Mobile-First 的設計理念，這些混亂是必須要被剔除的。

　　Mobile-First 響應式設計是對原有技術的重大革新，但也存在以下問題：

• 只實現了無縫縮放，而沒有實現內容自適應。
• 桌面網站需要從頭開始重新設計?；蛟S你認為這反倒是件好事。
  

　　總之，如果你的目標是構建移動網站，Mobile-First 響應式設計是唯1實用的響應式設計理念，由于從低端裝備到桌面閱讀器都可使用該方案。

　　3、漸進增強（PE）

　　漸進增強（PE）是1個新近流行的有關內容適應方面的術語。最初是在約 10 年前由 Steven Champeon 和 Nick Finck 在他們的文章《Inclusive Web Design Future》中提出來的，該文章發表于SXSW。漸進增強的核心思想是：在單1的網頁上實現 JavaScript 增強邏輯，使其能夠服務于所有類型的裝備。如果裝備過于簡陋，則 JavaScript 可能得不到運行或報錯，因此用戶體驗會很差；如果是智能裝備或桌面閱讀器，則 JavaScript 會逐步向頁面增加新的功能，充分發揮裝備的硬件功能。理論上講，分層是沒有上限的，可以逐步從功能手機閱讀器漸漸過度到臺式電腦閱讀器。

　　PE 的誘人的地方是很明顯的：它可以滿足所有類型的裝備（包括低端裝備），由于它是故障安全的解決方案；高端裝備的功能又不會由于這個“最低限度共同點”而遭到限制。剛剛發布的 jQuery Mobile 庫就用到了 PE 解決方案，實際上，PE 將內容適應邏輯從服務器端移到了客戶端。這類方案存在兩個問題：

• 該技術的核心“漸進增強”的履行是需要1定時間的，所需時間的長短主要取決于裝備的硬件性能，固然也可能與網速有關。舉個例子，某些型號的黑莓手機理論上是支持 JavaScript 的，但實際上運行速度太慢以致于沒有甚么實際用處。
• 和以往的技術1樣，該技術中多個用例共用同1個基本的 HTML 文件，這在功能上似乎很受限。
  

　　實際上，PE 技術的最好利用是消除移動裝備之間的差異，而不是作為1個綜合的內容適應解決方案。

　　4、服務器端內容適應技術

　　服務器端內容適應技術早在 12 年前移動 Web 剛剛出現時就開始使用了。該技術依賴于裝備檢測庫或依賴于安裝在 Web 服務器（或遠程 Web 服務）上的數據庫，檢測訪問網站的裝備并返回裝備的性能信息。服務器端可以根據這些信息對頁面進行微調，使之很好的適應裝備的性能。由于服務端內容適應技術中包括了裝備檢測技術，所以有時也被稱為“閱讀器嗅探”。雖然也有很多反對者，但閱讀器嗅探確切很穩定很精準，據統計，該解決方案檢測裝備的精準度到達了 99.5% 以上。

　　該技術的有效性不言自明：它依然是迄今為止最經常使用的內容適應技術，幾近所有重視移動用戶體驗的知名互聯網公司都在使用該技術，包括 Google、Facebook、Amazon、Youtube、Ebay 和 Yahoo。你很難找到1個沒使用服務器端內容適應技術而又獲得成功的移動網站。

　　但是，服務器端內容適應技術也不是沒有缺點。其缺點主要有以下兩點：

• 所用到的裝備檢測技術需要 Web 開發者不斷進行更新，并且大多數裝備檢測技術都是商業化的。
• 不能很好地使用閱讀器的實時數據（例如，GPS 定位或裝備當前的方向）以幫助 Web 開發者更好地服務于用戶。
  

　　目前，WURFL 和 DeviceAtlas 是裝備檢測方面的領軍產品，這兩款產品都是商業化的。

　　5、混合方法

　　最后要介紹的技術是混合方法，該方法把服務器端內容適應技術與漸進增強技術結合在了1起。這類技術的工作原理是，當服務器收到客戶真個頁面要求時，服務器端首先向客戶端提交1個基于服務器端內容適應原則的初始頁面，然后由客戶真個 JavaScript 來捕獲裝備的性能信息并返回給服務器端，服務器端根據所捕獲的信息對發向該裝備的后續頁面進行微調，使頁面更好地適應當裝備。

　　該技術首先是由 Bryan Rieger 和 Stephanie Rieger 發布的，他們在 yiibu.com 上很詳細地記錄了他們探索各種內容適應技術的曲折而漫長的道路。有趣的是，他們在嘗試該技術之前幾近已嘗試過了所有上文已介紹過的技術。

　　他們使用了裝備檢測技術和閱讀器屬性“隱性數據庫”，還使用了 modernizr-like JavaScript 腳本。在此不詳述細節，建議大家看看他們的介紹：“適應：為何響應式設計始于服務器端？”

　　這類混合方法對用戶端和服務器端來講都是最適合的方式――既可以利用高速的服務器端內容適應，又可以利用來源于裝備本身的屬性來調劑頁面。用戶可以得到1個初始的合適當前裝備的頁面，又不會有甚么性能開消，并且后續頁面會根據此頁面自動進行調劑。但是，這類方法也存在兩個缺點：

• 實現起來相對復雜，這點 Riegers 兩位也悵然承認。復雜性源于以下兩個因素：復雜性源于以下兩個因素：1）需要建立1個數據庫以保存閱讀器的屬性；2）需要寫 JavaScript 代碼，以實現從閱讀器中提取屬性并存入數據庫。
• 首次訪問服務器時，在用戶得到有用信息之前，需要1個從閱讀器到服務器之間的來回時間的延遲開消。在后續要求中可使用 cookies 來消除該延遲。
  

　　總結：

　　所有可用的技術都介紹過了，接下來你會如何選擇呢？固然，要視具體情況而定。筆者認為，任何以“單個 HTML 文檔來滿足所有裝備”為條件的技術，本是就是有缺點的，就猶如：大多數的電視內容不是屢次播放的電影，大多數的網站也不是紙質報紙的完善復制品。用戶對某些類型的網站（例如博客）的交互需求是有限的，這樣單1的1套交互方案是可以同時滿足桌面與移動用戶的。但是，在更1般的情況下，如果也讓桌面與移動用戶共用同1套方案，最好的結果是：功能嚴重受限； 最壞的結果是：根本沒法運行。

　　正如1位 CTO 所說：“客戶端功能檢測如何將1個航空公司的介紹性網站轉變成為移動電子登機服務呢？漸進增強理念是以‘所有用戶的需求都相同，只是界面布局不同’的假定為條件的?！?/span>

　　如果航空公司所構建的移動網站和桌面網站采取相同的基本模板，這樣真的可行嗎？如果你真的想提供1流的移動用戶體驗，那末響應式設計和漸進增強將得不到很好的體現。你在 Alexa 網站上快速看1眼就會知道，想要提供優良的移動用戶體驗需要對 HTML 進行量身定做，而不是簡單地調劑像素和 div 元素。

　　總之，如果你的網站只是運行在1些高端移動裝備上，并且你不會特地去照顧某些移動 Web 用戶，那末你可以采取響應式設計方案，或 Mobile-First 響應式設計方案。如果你的網站元素不太復雜，那末這兩種方案會很見效。

　　如果你想提供1個全新的移動用戶體驗設計或你想滿足所有的移動裝備，那末你只能使用服務器端內容適應方案或混合方法。這也是所有知名互聯網公司都采取這類方案的緣由。

　　上述觀點都是基于對新媒體的信仰：移動 Web 是1種新媒體，絕不是舊媒體的縮略版本；是1種功能強大的媒體，而不是功能弱小的媒體；是1種全新的 Web，而不是合成的雜牌 Web。只有這樣看待和使用該新媒體，它才能得到最公道、最成功的利用。

　　參考文章：

• Not a mobile web, merely a 320px-wide one
• There is no Mobile Web
• Responsive images part 1
• State of mobile web development, part 1/3: the problem
• State of mobile web development, part 2/3: progressive enhancement
• State of mobile web development, part 3/3: the mobile industry’s failings
• Benchmarking your device detection solutions

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈