讓網站支援多種用戶端

引言

現在的手機上網已經很普及，尤其是智能手機，在一些稍大的城市，幾乎是滿天飛了，在一些中小城市，普及的也比較廣。在我國，手機上網使用者，已經快達到4億，可見市場是多麼的誘人。

智能手機常見的作業系統有：android，apple os，windows phone，還有以前的symbian，smart phone等。

而且，這兩年又加入了一種新的用戶端，那就是pad。pad相比較手機而言，螢幕更大，7寸，8寸，10寸，存儲空間更大，甚至處理能力更強。

pad的作業系統主要是兩種：android和apple os。

手機和pad上網一般都支援手機卡上網，或者是無線連接配接上網。

是以現在的網站，有相當一部分在建立的時候，就考慮要支援手機浏覽。就算是已經建立好的網站，很多也開始考慮加入對手機浏覽的支援。更有一些，同時還做了手機用戶端，充分利用手機的資源，提供更進一步的服務。

今天我們讨論的話題就是如何讓網站支援多種用戶端浏覽，以及在設計的時候有哪些因素需要考慮。手機及pad用戶端不在今天的讨論範圍，以後會再開一篇來讨論這些用戶端的設計開發。

三種用戶端類型

通路網站的用戶端主要有三種類型：

手機

pad

pc

為什麼要區分三種類型呢？

因為這三種用戶端的螢幕尺寸是不一樣的，代表所能看到的内容的容量是不同的，更有甚者，三種裝置使用者的操作習慣也是不同的。是以需要針對三種類型，分開設計界面和使用流程，包括常說的使用者體驗，肯定要設計三類。

有人說了，pc還有各種尺寸呢，分辨率呢。手機也是有3.7的，有4.0的，有4.5的，有5.0的。pad也有7寸的，有8寸的，有10寸的。你怎麼不針對每一種做區分呢？

每一中類型雖然都各自有不同的分辨率，也有一些螢幕大小的差别。但是，在他們的内部差别，相對和其他類型的差别來說，是不大的，其實是可以考慮在一起的。如果想要做的更精細的，才需要精确設計到每一種尺寸，否則不需要考慮太多内部的差距，但是也要做好測試，做一些針對内部差距的自适應設計。

讓網站支援多種用戶端，有三種方式：

一種就是根據使用者的請求資訊，判斷使用者的類型，然後引導使用者進入合适頁面。

一種就是設計獨立的m.域名，例如www.baidu.com是提供給pc通路的，m.baidu.com是提供給手機通路的。

還有一種就是結合上面的情況，做更好的更人性化的設計。

根據請求區分使用者類型

使用者通路網站，有的是用pc，有的是用pad，有的是用pc，首先要做好區分，要知道通路的使用者是那種類型，然後才好根據類型把使用者引導到适當的頁面。

從技術角度來講，最常用，最主要，最精準的方法就是使用http的request的header中的user-agent資訊。通過分析這個資訊，可以知道請求的用戶端類型，是手機，還是pad，還是pc。甚至可以知道用戶端的作業系統，分辨率，生産廠商，用戶端型号，浏覽器類型，浏覽器核心，手機型号，pad型号等等資訊。

user-agent資訊的内容還取決于浏覽器的類型，不同的浏覽器可能會加入不同的資訊。

讓我們來看幾個例子。

關于擷取user-agent，有很多工具可以使用。例如：firefox的插件firebug，chrome自帶的developer tool，以及IE9及以上版本的開發者工具。

首先看一個chrome通路www.baidu.com的例子。

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 

從上面就可以看出來用戶端的作業系統是windows，浏覽器是chrome。

再來看兩個例子，都是中興手機通路網站之後，在日志中留下的資訊。

MQQBrowser/3.7/Adr (Linux; U; 2.2.2; zh-cn; ZTE-U V880 Build/UNI_CN_V880 1.1;480*800) 

MQQBrowser/3.7/Mozilla/5.0 (Linux; U; Android 2.2.2; zh-cn; ZTE-U V880 Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 

第一個裡面就包含了分辨率的資訊，手機浏覽器是QQ浏覽器，ZTE手機。第二個裡面的資訊要多一些，但是沒有分辨率。

其實利用user-agent還可以做一些統計。例如一些網站經常會釋出，有多少通路量，有多少手機通路量，手機通路占總通路的比例，有多少android通路量，有多少iphone通路量。甚至是手機上網占的比例，什麼時段手機上網量大，都可以從user-agent分析總計出來，結合時間資訊，結合referer，可以做很多的通路統計。

這是我們需要做的一件事，就是根據請求類型，引導使用者進入不同的頁面，或者給使用者呈現不同的内容。

設計獨立的m.域名

在建立www域名的同時，建立m.域名，專供手機通路，建立pad.專供pad通路。獨立設計，獨立開發，互相影響不大。

引導+獨立的m.域名

前兩種的原則就是講多種通路分開，各自通路各自的頁面，有各自的效果。你非要在pc上敲入m.域名，也可以看到内容，但是内容是給m.域名設計的。你非要在手機敲入www也行，我就給你看www域名下面的結構和内容。

這個有利有弊，把決定權交給使用者，“你通路什麼，我給你什麼”，在開發方面，各自獨立，沒有牽連，各自設計考慮，沒有太多交集和幹擾。

弊端就是不夠人性化，比如說我隻是知道有個網站www.example.com，不知道你還有域名m.example.com，我進入www.example.com一看，内容這麼多，字型很小，排版也很不舒服，不好操作，是啊，這都是給pc設計的，手機通路效果肯定不好。或者說，我手機大，而且我也不嫌小，我就想通路www.example.com，但是你就是幫我做了跳轉，使得我沒有辦法在手機通路www.example.com。這個也不太好。

我覺得好一點的話，需要考慮下面幾個因素：

m.獨立域名一定要有，可以友善的通路支援手機浏覽的網站。

但是如果你想通路www域名，也是可以的。

在頁面上可以友善的切換，同時在需要自動判斷的時候，引導使用者進入合适的頁面或者域名。

這就需要我們在能區分使用者通路類型之後，還要考慮使用者的通路流程，就是可能的幾種情況。

比如說使用者在pc上通路www，那就直接顯示www下面的頁面結構和内容就可以了。但是如果使用者在pc上敲入了m.，就存在一個分歧，是引導使用者進入www呢？還是顯示m.，但是提示使用者進入更合适的www，還是隻在界面上保留切換連結，讓使用者自己切換呢？這個可能還需要考慮應用的類型，應用主要的通路者類型。

還比如說，使用者通過過手機通路m.，那麼就顯示m.的結構和内容，頁面有切換連結，如果使用者非要切換，那麼就給他看切換之後的。如果使用者不知道有m.域名，隻是敲入www.域名，我覺的就不用提示使用者了，直接把他引到進入m.域名就可以了，因為m.域名更适合手機浏覽，不會使他對網站産生不好的印象。如果在後續，他還是要點選了切換連結，那麼就切換到www.域名。

本文轉自 virusswb 51CTO部落格，原文連結：http://blog.51cto.com/virusswb/1088691，如需轉載請自行聯系原作者