Native App與Web App的爭(zhēng)論從未停息過(guò)，盡管很多人在批判Web App的各種不是，但也阻止不了各種各樣的Web App如雨后春筍般出現(xiàn)，尤其是伴隨智能手機(jī)的普及而受到重視的Mobile Web App。這是一種在非議聲里成長(zhǎng)起來(lái)的產(chǎn)品形態(tài)，無(wú)論其結(jié)果如何，都應(yīng)該吸引開(kāi)發(fā)者和設(shè)計(jì)師的關(guān)注。

筆者通過(guò)自己在參與Mobile Web App的項(xiàng)目，總結(jié)出本文，也許還不能稱(chēng)之為方法，但目的是希望能對(duì)感興趣的讀者提供一些有價(jià)值的參考。如有謬誤，在所難免，煩請(qǐng)聯(lián)系本人更改，感激不盡。

一. Web App定義

維基百科對(duì)Web App的定義是：Web App是指使用瀏覽器支持語(yǔ)言編寫(xiě)的App，運(yùn)行于瀏覽器中，通過(guò)網(wǎng)絡(luò)訪(fǎng)問(wèn)。所以移動(dòng)Web App就特指特指運(yùn)行在智能手機(jī)瀏覽器中的Web App。

我認(rèn)為在用戶(hù)眼里，它是App；在開(kāi)發(fā)者眼里，它是Web。

二. Web App的特點(diǎn)

Google Chrome開(kāi)發(fā)小組推出的《Web App開(kāi)發(fā)指南》提出了如下對(duì)Web App的判斷標(biāo)準(zhǔn)：

• 是否獨(dú)立，完成當(dāng)前任務(wù)不需要鏈接到另一個(gè)完全不同的使用環(huán)境？
• 使用它是否可通過(guò)交互、參與并完成特定任務(wù)？
• 是否具有良好的用戶(hù)界面，看起來(lái)非常美觀，并且占據(jù)全屏？
• 是否使用和本地應(yīng)用一樣的界面模型，比如按鈕、對(duì)話(huà)框或者其他元素？
• 是否可以離線(xiàn)工作？
• 是否應(yīng)用了設(shè)備的某些功能，比如使用到來(lái)自GPS的定位和動(dòng)作傳感器的數(shù)據(jù)？
• 是否隱藏了傳統(tǒng)的網(wǎng)站導(dǎo)航欄和導(dǎo)向鏈接？
• 應(yīng)用是否是參照客戶(hù)端架構(gòu)模型設(shè)計(jì)？

這也不是本文討論的重點(diǎn)，僅供讀者參考。

另外就是談Web App和HTML5的文章必提的Web App相對(duì)于Native App所存在的優(yōu)勢(shì)和不足。

【優(yōu)勢(shì)】

跨平臺(tái)和終端

更新實(shí)時(shí)，無(wú)需用戶(hù)手動(dòng)升級(jí)

開(kāi)發(fā)成本和技術(shù)門(mén)檻很低，前段開(kāi)發(fā)工程師可快速上手

無(wú)需安裝、占空間少

易于維護(hù)

搜索引擎索引優(yōu)化

調(diào)試，發(fā)布方便

【劣勢(shì)】

受限于瀏覽器，性能和界面效果存在差距

嚴(yán)重依賴(lài)網(wǎng)絡(luò)連接

調(diào)用硬件和本地文件不便

無(wú)法在app store里上架銷(xiāo)售，但未來(lái)搜索引擎可以扮演Web App的分發(fā)入口也說(shuō)不定

 

下面是關(guān)于開(kāi)發(fā)各平臺(tái)應(yīng)用的語(yǔ)言、開(kāi)發(fā)工具、應(yīng)用格式和應(yīng)用商店的對(duì)比圖：

三. 發(fā)展現(xiàn)狀

截止到目前，app store和google play中的app數(shù)量均已接近70萬(wàn)，marketplace的app數(shù)量接近13萬(wàn)。而且隨著iOS、Android、Windows Phone各平臺(tái)層出不窮的新設(shè)備的發(fā)布和普及，app數(shù)量始終保持著增長(zhǎng)態(tài)勢(shì)。

Web app由于其定義比較模糊，所以暫時(shí)還沒(méi)有一個(gè)比較準(zhǔn)確的統(tǒng)計(jì)數(shù)據(jù)。但國(guó)內(nèi)主流的手機(jī)瀏覽器都將Web App放在很重要的位置（從左到右依次是遨游、百度、360、QQ、UC瀏覽器的應(yīng)用中心）：

 

根據(jù)的調(diào)查顯示開(kāi)發(fā)者對(duì)開(kāi)發(fā)HTML5 Web App的興趣也在與日俱增：

jQuery, Sencha, JQ.Mobi, Zepto等移動(dòng)UI組件和框架的發(fā)展也使得Mobile Web App的開(kāi)發(fā)越來(lái)越簡(jiǎn)單、和性能更好。

封裝了webView的Hybrid App則兼具Web App和Native App特點(diǎn)，在開(kāi)發(fā)成本和用戶(hù)體驗(yàn)上取到了一個(gè)很好的平衡點(diǎn)。好的Hybrid App完全能媲美Native App的用戶(hù)體驗(yàn)。這種開(kāi)發(fā)模式正在得到越來(lái)越多的開(kāi)發(fā)商和開(kāi)發(fā)者的青睞。Facebook，百度都使用過(guò)這種方式開(kāi)發(fā)過(guò)自己的產(chǎn)品。

四. 設(shè)計(jì)

1. 屏幕適配

移動(dòng)設(shè)備的屏幕是各式各樣的，對(duì)設(shè)計(jì)影響較大的主要是屏幕分辨率、尺寸、屏幕方向這些因素。現(xiàn)在的iOS設(shè)備有320×480，640×960，1136×640，1024×768，2048×1536這些分辨率，3.5寸、4寸、7.9寸、9.7寸這些尺寸。Android設(shè)備的碎片化則更嚴(yán)重。所以需要關(guān)注Web app在不同屏幕下的界面適配問(wèn)題。

1.1 適配不同分辨率

通過(guò)響應(yīng)式網(wǎng)頁(yè)的設(shè)計(jì)方法提升頁(yè)面在不同分辨率下的兼容性：

由于手機(jī)屏幕尺寸下，一般來(lái)說(shuō)只能一個(gè)模塊一個(gè)模塊地從上到下排列。此時(shí)設(shè)計(jì)者就需要考慮模塊擺放的優(yōu)先級(jí)了。一般來(lái)說(shuō)，用戶(hù)重點(diǎn)關(guān)注的、最近更新、與用戶(hù)相關(guān)的信息應(yīng)該放在前面。

另外最好以主流分辨率480×800進(jìn)行設(shè)計(jì)，對(duì)略高于和略低于該分辨率的屏幕可將界面元素進(jìn)行縮放，對(duì)間距、邊距進(jìn)行適當(dāng)調(diào)整。

所以，在設(shè)定容器、圖片、文本框的寬度時(shí)最好避免使用px單位，使用%可使頁(yè)面在不同分辨率屏幕下保持布局和頁(yè)面結(jié)構(gòu)不發(fā)生改變。

1.2 平板電腦

使用CSS3的媒體查詢(xún)（media query）語(yǔ)句可獲得瀏覽器的高寬和設(shè)備的像素比，并可根據(jù)開(kāi)發(fā)者的需要對(duì)不同的設(shè)備應(yīng)用不同的樣式表。所以開(kāi)發(fā)者可以控制一個(gè)頁(yè)面在不同設(shè)備上的表現(xiàn)。

由于手機(jī)屏幕和平板電腦的屏幕尺寸和像素都相去甚遠(yuǎn)，所以為了充分利用平板電腦的大屏優(yōu)勢(shì)，以獲得良好的用戶(hù)體驗(yàn)，最好在兩種設(shè)備上使用不同的界面布局。相信iOS用戶(hù)都有這樣的感覺(jué)：有的App只適配iPhone，在iPad上運(yùn)行則無(wú)法布滿(mǎn)屏幕，只能點(diǎn)“2X”按鈕顯示一個(gè)粗糙的界面。還有一種App可同時(shí)兼容iPhone和iPad，在手機(jī)和平板的屏幕上都能完美顯示，用戶(hù)也無(wú)需單獨(dú)下載兩個(gè)版本。很明顯，后者使用起來(lái)更方便，更美觀。

Mobile Web App使用媒體查詢(xún)功能即可實(shí)現(xiàn)這種功能。那么在平板電腦上，有哪些需要注意的設(shè)計(jì)點(diǎn)呢？

因?yàn)槠桨咫娔X多在橫屏下使用，所以使用分欄視圖可在一個(gè)界面內(nèi)顯示兩個(gè)層級(jí)的內(nèi)容，方便用戶(hù)快速切換item。

首頁(yè)多以宮格視圖、Tab為主，微博、QQ這種以?xún)?nèi)容為主的界面將分欄視圖作為默認(rèn)首頁(yè)也是可以的。在手機(jī)上最常使用的list在平板上就不是很常用了，整個(gè)屏幕顯示list，不僅浪費(fèi)空間，也沒(méi)有分欄視圖的操作。

需要注意的是，IE9以下的瀏覽器不支持media query.

1.3 橫豎屏切換

由于目前還不能在webkit內(nèi)核里禁止設(shè)備方向的旋轉(zhuǎn)，所以如果用戶(hù)的設(shè)備開(kāi)啟了屏幕方向根據(jù)重力自動(dòng)旋轉(zhuǎn)，那么運(yùn)行于瀏覽器的Web App也是會(huì)跟著旋轉(zhuǎn)的。

如果能夠捕捉到設(shè)備的方向，可以對(duì)橫豎屏分別進(jìn)行布局設(shè)計(jì)，但最好能保證界面風(fēng)格和樣式不會(huì)有大的變化。

反例就是iPhone的音樂(lè)App，在豎屏下會(huì)顯示歌曲list，但是切換到橫屏下顯示專(zhuān)輯封面。兩種界面風(fēng)格跳動(dòng)太大會(huì)導(dǎo)致部分用戶(hù)不適應(yīng)，以為是兩個(gè)不同的頁(yè)面。計(jì)算器App也只有在橫屏下才顯示科學(xué)計(jì)算模式，豎屏下用戶(hù)根本無(wú)法切換到該模式，連引導(dǎo)也沒(méi)有。

宮格視圖是橫豎屏切換最平滑的布局，看看iOS系統(tǒng)的主屏幕就知道了。一個(gè)個(gè)應(yīng)用程序圖標(biāo)在橫豎屏切換時(shí)，幾乎只是圖標(biāo)旋轉(zhuǎn)了一下方向。

還有一點(diǎn)就是切換到橫屏?xí)r，可自動(dòng)進(jìn)入全屏模式以顯示更多的內(nèi)容。否則標(biāo)題欄和底部欄將會(huì)占去很多空間

2.動(dòng)效

受瀏覽器性能影響，很多Native App能實(shí)現(xiàn)的華麗動(dòng)畫(huà)在Web App里的表現(xiàn)并不是很好。所以應(yīng)該果斷去掉非必要的動(dòng)效以保證Web App能夠運(yùn)行流暢。

因?yàn)楹芏鄤?dòng)效會(huì)對(duì)用戶(hù)起到很好的引導(dǎo)作用，如果沒(méi)有這些動(dòng)畫(huà)，可能會(huì)導(dǎo)致用戶(hù)對(duì)界面邏輯關(guān)系的理解產(chǎn)生混亂。這就對(duì)動(dòng)效的設(shè)計(jì)提出了較高的要求?？偨Y(jié)了一下Web App的幾點(diǎn)動(dòng)效設(shè)計(jì)原則：

• 盡量不使用不必要的動(dòng)效。
• 優(yōu)先使用簡(jiǎn)單的動(dòng)畫(huà)。如平移、縮放。盡量避免使用3D動(dòng)畫(huà)。
• 避免刷新頁(yè)面。因?yàn)檎麄€(gè)頁(yè)面白屏，瀏覽器走進(jìn)度條的體驗(yàn)會(huì)給用戶(hù)瀏覽網(wǎng)頁(yè)的感覺(jué)，而不是在使用app
• 框架元素優(yōu)先顯示。只在內(nèi)容加載區(qū)域顯示loading動(dòng)畫(huà)
• 避免跳變。在不影響性能的情況下，可盡量用縮放和平移動(dòng)畫(huà)，保證用戶(hù)視覺(jué)焦點(diǎn)的延續(xù)性和理解的延續(xù)性。
• 同類(lèi)界面/對(duì)象，同層級(jí)界面/對(duì)象的動(dòng)效保持一致?？蓭椭脩?hù)理解產(chǎn)品架構(gòu)和導(dǎo)航邏輯。
• 高層級(jí)界面的動(dòng)效對(duì)應(yīng)高級(jí)物理位置。如果左右平移的動(dòng)畫(huà)是用來(lái)切換上下一層級(jí)，那么首頁(yè)應(yīng)該是在最左邊，如iOS。如果前后切換的動(dòng)畫(huà)是用來(lái)切換上下一層及，那么首頁(yè)應(yīng)該是在最上面，如Windows Phone。

3.信息架構(gòu)

講導(dǎo)航和信息架構(gòu)的文章眾多，Mobile Web App既然要實(shí)現(xiàn)Native App的操作體驗(yàn)，照傳統(tǒng)的移動(dòng)客戶(hù)端的設(shè)計(jì)模式去設(shè)計(jì)即可。只需要記住你設(shè)計(jì)的Web App需要運(yùn)行在iOS, Android, Windows Phone等多個(gè)平臺(tái)，多種設(shè)備上即可。

由于iOS相比其他平臺(tái)，沒(méi)有back按鍵，所以在iOS上運(yùn)行需要保證界面內(nèi)的導(dǎo)航能夠?qū)崿F(xiàn)閉環(huán)。所以Android上有些操作可以通過(guò)Menu鍵喚出，但是在iOS上就需要直接暴露出來(lái)。

下圖左側(cè)是Zaker的Android版，右側(cè)是iPhone版。Android版的菜單欄需要點(diǎn)擊Menu鍵才出現(xiàn)。

        

 

4.使用Native App的UI控件

使用Native App的UI控件，可以讓Mobile Web App更有Native App的操作體驗(yàn)。常見(jiàn)的如Badge，Back button，Bubble，Picker，Indicator，Title bar，Dialog，Toast，Loading，Drap down to refresh，Notification等。下圖分別是Facebook的Native App和Web App，由于后者使用了客戶(hù)端常見(jiàn)的一些UI控件，所以用戶(hù)很難從視覺(jué)上識(shí)別出后者是Web App.

避免使用傳統(tǒng)的Web UI控件，如面包屑、文字鏈：

另外，在控件尺寸上也應(yīng)該像Native App那樣提供盡量大點(diǎn)擊區(qū)域的控件。參照經(jīng)驗(yàn)和各平臺(tái)的官方人機(jī)界面指南，可以知道適合用戶(hù)手指點(diǎn)擊的尺寸應(yīng)該在7-9mm之間，不能小于7mm。相鄰點(diǎn)擊控件的行距不應(yīng)小于2mm。

5. 針對(duì)瀏覽器優(yōu)化

為了兼顧瀏覽器的性能和交互，需要注意以下幾點(diǎn)：

• 頁(yè)面使用盡量少的DOM元素；
• 簡(jiǎn)化動(dòng)效；
• 避免與瀏覽器的交互沖突，如左右滑動(dòng)，如瀏覽器的tab bar, action bar, 以及瀏覽器全屏后的虛擬按鈕；
• 考慮保存用戶(hù)的哪些數(shù)據(jù)：設(shè)置、個(gè)人數(shù)據(jù)、閱讀錨點(diǎn)、跳出頁(yè)面等。
• 規(guī)則圖形用Canvas繪制，避免向服務(wù)器請(qǐng)求img.
• 注意離線(xiàn)數(shù)據(jù)存儲(chǔ)，通過(guò)manifest定義需要被緩存的文件，以便用戶(hù)離線(xiàn)時(shí)使用。
• 減少數(shù)據(jù)請(qǐng)求頻率。

6. 其他

Track：建立Track機(jī)制可以快速獲取用戶(hù)的操作習(xí)慣和頁(yè)面的瀏覽情況。從而方便設(shè)計(jì)師和產(chǎn)品人員快速改善產(chǎn)品。這一點(diǎn)比在Google Analytics獲取到的數(shù)據(jù)更方便，更準(zhǔn)確。

SEO：使用SEO提升Mobile Web App的曝光率。因?yàn)楹芏嗍謾C(jī)用戶(hù)會(huì)通過(guò)搜索引擎進(jìn)入你的website，而不是地址欄。

域名指向：m.site.com，mobile.site.com，site.mobi，www.site.com/mobile，3g.site.com，wap.site.com，shouji.site.com，www.site.com/mobile等帶有明顯手機(jī)網(wǎng)站含義的域名都應(yīng)該指向你的Mobile Web App（或Wap站）所在站點(diǎn)。如果條件所限只能綁定一個(gè)的話(huà)，請(qǐng)使用m.site.com。ps.這一點(diǎn)來(lái)自Nielsen的《Usability of Mobile Websites》.

五. 優(yōu)秀Mobile Web App推薦

目前百度垂直搜索站點(diǎn)的Web App均已上線(xiàn)，體驗(yàn)還不錯(cuò)。大家可以去體驗(yàn)一下。另外的還有如新浪微博，F(xiàn)inancial Times，Gmail，Linkedin，騰訊美閱等。