閱讀890 返回首頁    go 阿裏雲 go 技術社區[雲棲]


再談多端適配


165738io4wmaljjonlvn6m.jpg

多端適配其實已經是個老生常談的話題了,隨著移動端的興起到趨於穩定,WEB也已經發展到相對成熟的階段。在經曆了一番番的更新演進後,業界有了非常豐富的多端適配的方案。PC與移動也從分離 → 融合 → 分離走了完整的一個過程。今天小劇就來聊聊我個人對多端適配的一些想法。

為什麼要做多端適配?

為什麼需要做多端適配呢?因為前麵提到移動端的興起,帶來的是用戶訪問我們網站的途徑越來越多樣化的。傳統PC的站點已經很難在移動設備上使用,所以我們需要通過多端適配的方案來讓WEB產品在各個設備下具有良好體驗。

關於多端適配的定義有很多,小劇認為的多端適配應該是一套完整的,能同時兼容PC、移動端這兩大類主流設備的WEB方案。

有哪些方案可以實現多端適配?

實際操作起來多端適配的實現方式非常多,小劇總結下來最基本的套路主要有以下三種:響應式設計、多站點跳轉、多視圖切分。下麵小劇分別來介紹下這三種方案以及各自的優劣勢。

1、響應式設計

響應式設計是早些時候炒的比較火的一個技術方案,甚至有種被神話的感覺。那什麼是響應式設計呢?響應式設計是利用 media query 和 CSS3 的一些其他特性實現的多端適配方案,本質是同一套代碼同時響應多個設備。

響應式設計有什麼好處呢?首先響應式設計在視覺上具有高度的統一性,在合理的前期設計配合下可以大幅度減輕多端適配的工作量。可以做到一次開發適配多種設備平台。

然而響應式設計同時也是一種交互、視覺、前端高度配合的開發方式,需要更為緊密的上下遊溝通交流。同時在設計時需要在多種設備的交互模式上做平衡,無法將各類設備特有的交互模式做個性化的發揮。若是前期預見產品在多端下的功能模塊、交互模式有差異的可能,最好不要考慮使用響應式設計的方案。另外如果設想通過一套代碼完全適配從PC到移動端各類設備及各類瀏覽器,難度也是不言而喻的。以上均是響應式設計存在的弊端。

2、多站點跳轉

在實際應用中多站點跳轉應該是使用最為廣泛的一種多端適配方案。這類實現方式相對簡單易於操作。多站點跳轉是:針對PC、移動端各開發一套網站,通過對UA的判斷由nginx或各個站點自身做相互跳轉。比較常見的表現就是PC URL為xxx.com,移動端URL為m.xxx.comxxx.com/m

這樣分析下來多站點跳轉的優勢就很明顯了。其一是因為站點是相互獨立的,所以項目可以拆分給不同的團隊使用不同的後端環境各自獨立開發;其二是多端代碼分離,可以有效利用各個設備下的交互模式並發揮到極致。相對於後麵要說的多視圖切分的方案還有第三個優勢,這一點後麵再做描述。

多站點跳轉的弊端總的來說還是比較少的。勉強算一個的話,在跨設備訪問的時候,細心的用戶可以感知到URL的變化。另外就是需要特別處理好多端下的URL映射規則,需要保證線上多個站點下的URL同時存在,不至於由於頁麵缺失導致不必要404的存在。

3、多視圖切分

多視圖切分從URL上來看有點兒像響應式設計,但是從實現方式上來看又和多站點跳轉非常類似。多視圖切分一般是由同一個後端環境處理,在MVC結構上通過對各個設備開發獨立的views,由controller根據UA做出views的選擇。所以在多端適配的過程中用戶不會感知到任何URL的變化。

多視圖切分的優勢和多站點跳轉有點類似,隻是工作拆分粒度沒那麼粗,僅僅是在views層麵做切分。其次由於views的相互獨立,同樣可以針對各個設備開發相對獨立的交互模式。

從上麵的總結來看,多視圖切分看起來在一定程度上同時具備了響應式設計和多站點跳轉的優勢,也同時缺少了各自的弊端,理論上應該是市麵上應用最多的一種適配方案。然而觀察市麵上一些流行的大型站點,幾乎很少能看見這種方案蹤影,這是為什麼呢?

可能有同學已經能猜到了,原因就是在CDN上。為了緩解服務器壓力,運維同學通常需要對網站做緩存優化。目前市麵上通用的緩存方案的最小粒度是URL,而多視圖切分卻是同一個URL對應多種響應,處理不好很容易導致緩存的混亂。這也就是在多站點跳轉時提到的第三個優勢,可以非常容易的進行CDN優化。

這三種方案改如何選擇?

這三種方案總的來說各有利弊,所以如何在特定場景下做準確的選擇是非常重要的。小劇從網站功能和交互模式上來分類,一般會有下麵幾種對應關係。

一類是純展示類的官網、活動宣傳網站。通常這類網站交互模式較輕,可以很方便的用同一套代碼響應多類設備,因此響應式設計是最好的選擇。無論是設計成本還是前端的還原成本都可以大幅度的降低。

另一類是交互模式較重的網站,如電商、社交平台。通常需要在各個設備下充分使用自身的交互模式,像PC的鼠標和移動的觸摸事件,甚至某些場景下需要利用特定設備的特有特性如PC的拖放事件和移動端的陀螺儀。這類網站一般隻能在多站點跳轉和多視圖切分兩者間做出選擇。

至於在後兩者中推薦使用哪個方案,其實在一般中小型站點下並沒有明顯的區別。一來是開發模式比較像,僅僅是拆分粒度不同而已;二來是部分網站的緩存並不針對頁麵,主要的目的還是減輕靜態資源的訪問壓力。

如果一定要問小劇更推薦哪個方案,我認為應該是多站點跳轉。原因很簡單就是簡單、幹淨。


雖然小劇關於三種方案的描述比較獨立,但是實際使用中它們並不是絕對互斥的存在。在同一個網站下麵對不同的需求做出針對性的選擇,可能會收到更為顯著的效果。

仔細分析的話,市麵上絕大多數的網站一般都是糅合了小劇提到的這三種方案。


PS:如果你看到了這一行,很感謝你沒有因為小劇幹澀的描述方式而走開。本文隻是根據小劇的開發經驗談談多端適配思路上的一些想法,並不一定完整、嚴謹。

PPS:舉個小栗子,小劇客棧的從大的邏輯來看使用了多視圖切分的方式,用來區分IE678等低端瀏覽器和高級瀏覽器。具體到高級瀏覽器下的視圖又使用了響應式的來做PC、移動端的適配。操作上和本文提到的方案略有出入,但是總體思路是互通的。


by 小劇客棧


最後更新:2017-09-25 15:03:46

  上一篇:go  擁抱大數據 助力雲產業 ——專訪上海良信電器
  下一篇:go  十年的堅守與執著 CDN行業需要匠人精神