名詞介紹
Native APP
Native APP 指的是原生程序,一般依托于操作系統,有很強的交互,是一個完整的App,可拓展性強,需要用戶下載安裝使用。(簡單來說,原生應用是特別為某種操作系統開發的,比如iOS、Android、黑莓等等,它們是在各自的移動設備上運行的)
該模式通常是由“云服務器數據+APP應用客戶端”兩部份構成,APP應用所有的UI元素、數據內容、邏輯框架均安裝在手機終端上。
原生應用程序是某一個移動平臺(比如iOS或安卓)所特有的,使用相應平臺支持的開發工具和語言(比如iOS平臺支持Xcode和Objective-C,安卓平臺支持Eclipse和Java)。原生應用程序看起來(外觀)和運行起來(性能)是最佳的。
WebAPP
Web App 指采用Html5語言寫出的App,不需要下載安裝。類似于現在所說的輕應用。生存在瀏覽器中的應用,基本上可以說是觸屏版的網頁應用。(Web應用本質上是為移動瀏覽器設計的基于Web的應用,它們是用普通Web開發語言開發的,可以在各種智能手機瀏覽器上運行)
Web App開發即是一種框架型APP開發模式(HTML5 APP 框架開發模式),該開發具有跨平臺的優勢,該模式通常由“HTML5云網站+APP應用客戶端”兩部份構成,APP應用客戶端只需安裝應用的框架部份,而應用的數據則是每次打開APP的時候,去云端取數據呈現給手機用戶。
HTML5應用程序使用標準的Web技術,通常是HTML5、JavaScript和CSS。這種只編寫一次、可到處運行的移動開發方法構建的跨平臺移動應用程序可以在多個設備上運行。雖然開發人員單單使用HTML5和JavaScript就能構建功能復雜的應用程序,但仍然存在一些重大的局限性,具體包括會話管理、安全離線存儲以及訪問原生設備功能(攝像頭、日歷和地理位置等)。
HybridAPP
Hybrid APP指的是半原生半Web的混合類App。需要下載安裝,看上去類似Native App,但只有很少的UI Web View,訪問的內容是 Web 。
混合應用程序讓開發人員可以把HTML5應用程序嵌入到一個細薄的原生容器里面,集原生應用程序和HTML5應用程序的優點(及缺點)于一體。
混合應用大家都知道是原生應用和Web應用的結合體,采用了原生應用的一部分、Web應用的一部分,所以必須在部分在設備上運行、部分在Web上運行。不過混合應用中比例很自由,比如Web 占90%,原生占10%;或者各占50%。
有些應用最開始就是包了個原生客戶端的殼,其實里面是HTML5的網頁,后來才推出真正的原生應用。比較知名的APP,比如手機百度和淘寶客戶端 Android版,走的也是Hybrid App的路線,不過手機百度里面封裝的不是WebView,而是自己的瀏覽內核,所以體驗上更像客戶端,更高效。
三種APP技術特性
Native APP
Native APP的優點:
- 能夠與移動硬件設備的底層功能,比如個人信息,攝像頭以及重力加速器等等。
- 可訪問手機所有功能(GPS、攝像頭)。
- 速度更快、性能高、整體用戶體驗不錯。
- 可線下使用(因為是在跟Web相對地平臺上使用的)。
- 支持大量圖形和動畫
- 容易發現(在App Store里面和應用商店里面)和重新發現(應用圖標會一直在主頁上),對于蘋果而言,應用下載能創造盈利(當然App Store抽取20-30% 的營收)
- 比移動Web App運行快
- 一些商店與賣場會幫助用戶尋找原生App
- 官方賣場的應用審核流程會保證讓用戶得到高質量以及安全的App
- 官方會發布很多開發工具或者人工支持來幫助你的開發
- 頁面存放于本地
Native APP的缺點:
- 開發成本高,尤其是當需要多種移動設備來測試時
- 因為是不同的開發語言,所以開發,維護成本也高
- 因為用戶使用的App版本不同,所以你維護起來很困難
- 支持設備非常有限(一般是哪個系統就在哪個平臺專屬設備上用)
- 官方賣場審核流程復雜且慢,會嚴重影響你的發布進程
- 上線時間不確定(App Store審核過程不一)
- 內容限制(App Store限制)
- 獲得新版本時需重新下載應用更新(提示用戶下載跟新,用戶體驗差)
WebAPP
WebAPP的優點:
- 跨平臺開發、用戶不需要去賣場來下載安裝App,開發速度快
- 任何時候都可以發布App,因為根本不需要官方賣場的審核
- 純H5 APP快速開發、低成本、多平臺,與很多APP開發方式不同的是-圖文混合的排版(正是這些復雜多變的CSS樣式消耗了性能,但是它帶來了排版的多樣性,能夠細致到每一個字寬行高和風格的像素級處理,才是H5的優異之處)
- 支持設備廣泛
- 較低的開發成本
- 可即時上線
- 無內容限制
- 用戶可以直接使用最新版本(自動更新,不需用戶手動更新)
- 跨平臺開發
- 用戶不需要去賣場來下載安裝App
- 如果你已經有了一個Web App,你可以使用 responsive web design來輔助改進
- 頁面存放于web服務器(受限于UIwebview)(減少了內存,但是會增加服務器的壓力)
WebAPP的缺點:
- 只能使用有限的移動硬件設備功能,無法使用很多移動硬件設備的獨特功能
- 要同時支持多種移動設備的瀏覽器讓開發維護的成本也不低(也要適配不同的瀏覽器),如果用戶使用更多的新型瀏覽器,那問題就更不好處理了
- 對于用戶來說,這種App很難被用戶發現
- 這里的數據獲取都是在資源頁面上異步完成的,因為只有這樣才能讓這些資源頁面完成預加載或者渲染。(異步的話都涉及到耗時的問題)
- 表現差(對聯網的要求比較大)
- 用戶體驗沒那么炫
- 圖片和動畫支持性不高
- 沒法在App Store中下載、無法通過應用下載獲得盈利機會
- 對手機特點有限制(攝像頭、GPS等)
- 無法體會包括會話管理、安全離線存儲以及訪問原生設備功能(攝像頭、日歷和地理位置等)
- 頁面跳轉更加費力,不穩定感更強
- 更小的頁面空間(由于瀏覽器的導航本身占用一部分屏幕空間),更大的信息記憶負擔
- 導航不明顯,原有底部導航消失,有效的導航遇到挑戰
- 交互動態效果收到限制,影響一些頁面場景、邏輯的理解。比如登錄注冊流程的彈出、完成及異常退出,做好文字提示。
Hybrid APP
(1)第一種方案:Web架構為重
優點:
- 全Web開發,一定程度上有利于Web前端技術人員快速地構建頁面樣式
- 有利于在不同的平臺上面展示同一個交互層
- 便于調試,開發的時候可以通過瀏覽器的
- 方式進行調試,工具豐富。
- 兼容多平臺
- 順利訪問手機的多種功能
- App Store中可下載(Wen應用套用原生應用的外殼)
- 可線下使用
- 頁面存放于本地和服務器兩種方式,部署應用程序(受限于UIwebview)
缺點:
- 不確定上線時間
- 雖然說你可以專注在界面以及交互開發上了,但是這頁會成為一個缺點,比如說要仿造一個iOS的默認設置界面,就需要大量的html以及css代碼了,而且效果不一定和iPhone上面的界面一樣好
- 用戶體驗不如本地應用
- 性能稍慢(需要連接網絡)
- 技術還不是很成熟(比如Facebook現在的應用屬于混合應用它可以在許多App Store暢通無阻,但是摻雜了大量Web特性,所以它運行速度比較慢,而現在為了提高性能FB又決定采用原生應用)
(2)第二種方案:編譯轉換方式
優點:
利用自己熟悉的語言進行應用開發。
缺點:
嚴重依賴于其工具廠商提供的工具包,調試的時候就要有全套的工具。
(3)第三種方案:Native架構為重(主流)
優點:
最穩定的Hybrid App開發方式了,交互層的效率上由Native的東西解決了,而且架構上基本就是在App內寫網頁,連App Store都是采用了該種方案;
缺點:
團隊至少需要兩個工程師,一個是Web的,一個是iOS或者Android的。當然如果開發人員會兩種技術也可獨立承擔;還是運行效率,要權衡好多少界面采用Web來渲染,畢竟WebView的效率會相對降低,以前Facebook就是因為Web的渲染效率低下,把整個應用改為原生的解決方案。當然這里面可以通過優化來解決,但是優化也是有限度的。
3種APP對比分析
對用戶來講差別主要是用戶體驗,如果WebApp做得好也能接近原生App的效果;對于開發人員,WebApp更加易于移植到多個平臺,減少非常多的工作量。
1.主要區別
原生APP中:
每一種移動操作系統都需要獨立的開發項目;
每種平臺都需要獨立的開發語言。Java(Android), Objective-C(iOS)以及Visual C++(Windows Mobile)等等,需要使用各自的軟件開發包,開發工具以及各自的控件。
Native App(原生型APP)需要開發“云服務器數據中心”和“APP客戶端”
每次獲取最新的APP功能,需要升級APP應用
原生型APP應用的安裝包相對較大,包含UI元素、數據內容、邏輯框架;
手機用戶無法上網也可訪問APP應用中以前下載的數據
原生型的APP可以調用手機終端的硬件設備(語音、攝像頭、短信、GPS、藍牙、重力感應等)
APP應用更新新功能,涉及到每次要向各個應用商店進行
提交審核。
適用企業:游戲、電子雜志、管理應用、物聯網等無需經常更新程序框架的APP應用。
WebAPP中:
因為運行在移動設備的瀏覽器上,所以只需要一個開發項目
這種應用可以使用HTML5,CSS3以及JavaScript以及服務器端語言來完成(PHP,Ruby on Rails,Python),這里可沒有標準的SDK,基本任意選擇別忘了有一些跨平臺的開發工具,比如PhoneGap, Sencha Touch 2,APPcan以及Appcelerator Titanium等等。
Web APP需開發“html5云網站”和“APP客戶端”
每次打開APP,都要通過APP框架向云網站取UI及數據
手機用戶無法上網則無法訪問APP應用中的數據
框架型的APP無法調用手機終端的硬件設備,(語音、攝像頭、短信、GPS、藍牙、重力感應等)
框架型APP的訪問速度受手機終端上網的限制,每次使用均會消耗一定的手機上網流量
框架型APP應用的安裝包小巧,只包含框架文件,而大量的UI元素、數據內容剛存放在云端
APP用戶每次都可以訪問到實時的最新的云端數據
APP用戶無須頻繁更新APP應用,與云端實現的是實時數據交互
適用企業:電子商務、金融、新聞資訊、企業集團,需經常更新內容的APP應用。
2.開發難度區別
移動web和混合App開發難度對于web開發者來說相對較低,而且可以充分利用現有的web開發工具和工作流程
3.發布渠道和更新方式
混合App可以在應用商店App Store發布,但可以自主更新,而原生App的更新必須通過應用商店App Store。
4.移動設備本地API訪問
混合App可以通過JavaScript API訪問到移動設備的攝像頭、GPS;而原生App可以通過原生編程語言訪問設備所有功能。
5.跨平臺和可移植性
基于瀏覽器的移動web最好的可移植性和跨平臺表現;混合App也能節省跨平臺的時間和成本,只需編寫一次核心代碼就可部署到多個平臺,而原生App的跨平臺性能最差。
6.搜索引擎友好
只有移動web對搜索引擎友好,可與在線營銷無縫整合。
7.貨幣化
混合App除廣告外,還支持付費下載及程序內購買;原生App的程序內購買金額2012年首次超過下載收費。
8.消息推送
只有混合App和原生App支持消息推送,這能增加用戶忠誠度。
9.獲取方法區別
原生APP中:
直接下載到設備
以獨立的應用程序運行(并不需要瀏覽器)
用戶必須手動去下載并安裝這些原生App
有一些商店與賣場來幫助用戶尋找你的App,
WebAPP中:
從移動設備上的瀏覽器訪問
不需要安裝額外的軟件
軟件更新只需要服務器就夠了
因為現在沒有什么商品或賣場提供這種App,所以如何搜索這些移動Web App相當不簡單
10.版本控制區別
原生APP中:
用戶可以自由地選擇是否更新軟件版本,所以會出現不同用戶同時使用不同版本的情況
WebAPP中:
所有的用戶都是用同樣的版本
如何判斷一個混合APP開發的頁面形式
斷網檢查不是絕對的,web app并不一定是在遠程服務器上的, 也能pack在程序里,load本地的資源也能算是web app。
在系統設置里進入“開發者選項”,勾選“顯示布局邊界”,然后就可以看得出來了。(比較靠譜)
一般web界面有明顯的加載的過程,你看頁面的最上面一般有一個加載的進度條,不過這個進度條一般加載也比較快,有些應用在這樣的說明頁面會有刷新操作、這樣你斷網再刷新就會提示網址找不到
網頁的一般就在手機的當前界面加載一個url地址。
(快速)滾動起來是否比較卡
圖片加載失敗的圖標
怎樣選擇開發模式(視情況而定)
近年來隨著移動設備類型的變多,操作系統的變多,用戶需求的增加,對于每個項目啟動前,大家都會考慮到的成本,團隊成員,技術成熟度,時間,項目需求等一堆的因素。
因此,開發App的方案已經變得越來越多了。無數的人參與或者看到過一個討論:原生開發還是混合開發,又或者是Web開發?要結實踐和自身的情況。
- 比如,你的預算是多少?預算充足的話可以開發幾個本地應用加一個Web應用
- 你的應用需要什么時候面市?Web應用可以很快地開發然后直接推出來
- 你的應用需要包含什么特點和功能?如果跟手機的某些功能深度整合了,比如攝像頭,需要呈現大量圖形和動畫就選原生 應用好點
- 你的應用是否一定需要網絡
- 你的應用的目標硬件設備是所有的移動設備還是僅僅只是一部分而已
- 你自己已經熟悉的開發語言,或者說現有資源
7.這個應用對于性能要求是否苛刻
8.如何靠這個應用贏利我想這幾個問題應該能讓你做出明智的選擇
9.你的應用是否需要使用某些設備的特殊功能,比如攝像頭,攝像頭閃光燈或者重力加速器
10.移動Web無所不在,移動Web是目前唯一的支持各種設備訪問的平臺,與桌面Web一樣,移動Web支持各種標準的協議。移動Web也是唯一一個可供開發者發布移動應用的,平臺,它將各種移動交互與桌面任務有效地連接了起來;而開發Native App可以充分利用設備的特性,而這一點往往是Web瀏覽器做不到的,所以對一個產品本身而言,Native App是最佳的選擇。
11.為應用收費(人們的觀念webApp是不收費的)用原生開發模式
12.Web Apps是唯一一個經久不衰的移動內容、服務、應用開發平臺。
13.使用定位功能、使用攝像頭、使用感應器、訪問文件系統、離線用戶、多點觸控:雙擊、縮放及其他組合的用戶界面(UI)手勢;快速圖形API:原生平臺為你提供了顯示最快速的圖形。如果你顯示只有寥寥幾個元素的靜態屏幕,這個功能可能不太重要,但如果你使用大量數據,需要快速刷新,這項功能卻很重要;流暢動畫:與快速圖形API有關的是實現流暢動畫的功能。這在動畫、高度交互的報表或者轉換照片和聲音的計算密集型算法中顯得尤為重要;內置部件:攝像頭、地址簿、地理位置及設備的其他原生功能可以無縫地整合到移動應用程序中。另一個重要的內置部件是加密的存儲裝置,這方面稍后會有詳細介紹;易于使用:原生平臺是人們耳熟能詳的平臺,所以如果你在這個熟悉的平臺上添加人們期望的所有原生功能,也就擁有了一款使用起來完全更容易的應用程序時用原生
14.是原生App還是移動Web App,主要受商業目標,目標用戶,以及技術需要這些因素影響的。其實更多時候你也不要為選擇那種App模式煩惱,正如本文提到,類似Facebook這樣的公司就為用戶提供了兩種選擇。然而對于大部分人來說,預算,資源限制將會逼迫我們只能選擇其中一種(或者只能以其中一種為重點
六、WebAPP和原生APP交互區別
1.Web APP受限因素
相比Native App,Web App體驗中受限于以上5個因素:網絡環境,渲染性能,平臺特性,瀏覽器限制,系統限制。
(1)網絡環境,渲染性能
Web APP對網絡環境的依賴性較大,因為Web APP中的H5頁面,當用戶使用時,去服務器請求顯示頁面。如果此時用戶恰巧遇到網速慢,網絡不穩定等其他環境時,用戶請求頁面的效率大打折扣,在用戶使用中會出現不流暢,斷斷續續的不良感受。同時,H5技術自身渲染性能較弱:對復雜的圖形樣式,多樣的動效,自定義字體等的支持性不強。 因此,基于網絡環境和渲染性能的影響,在設計H5頁面時,應注意以下幾點:
簡化不重要的動畫/動效
簡化復雜的圖形文字樣式
減少頁面渲染的頻率和次數
具體案例:設計Web APP要去除冗余的功能,回溯本源,只給用戶提供最初的本質需求。既符合H5精簡功能又達到了突出核心功能的設計原則。
切記重要的并不是我們提供的信息量有多大,而是我們能否給他們提供真正需要的信息。
切記要減少功能入口,增強用戶的專注度,不要分散用戶的注意力。
(2)瀏覽器限制
通常Web App生存于瀏覽器里,宿主是瀏覽器。不同的瀏覽器自身的屬性不盡相同,如:瀏覽器自帶的手勢,頁面切換方式,鏈接跳轉方式,版本兼容問題等等。
具體案例1:UC 瀏覽器和百度瀏覽器自身支持手勢切換頁面。手指從左側滑動頁面,返回至上一級。百度手機助手H5頁面,頂部Banner支持手勢左右滑動切換。這一操作與瀏覽器自身手勢是沖突的。
具體案例2:基于瀏覽器的Web APP在打開新的模塊中的頁面時,大多會新開窗口來展現。例如用戶在使用購物類APP時,瀏覽每日精選模塊時,每當打開新的商品時,默認新開一個窗口。這樣的優劣勢顯而易見:優勢是能夠記錄用戶瀏覽過的痕跡,瀏覽過的商品,以便后續橫向對比;劣勢是過多的頁面容易使用戶迷失在頁面中。
正如Google開發手冊里描述:當用戶打開一個Web App的時候,他們期待這個應用就像是一個單個應用,而不是一系列網頁的結合。然而,什么情況下需要跳轉頁面,什么情況下在當前頁面展示則需要設計師細致考量。
因此,Web App基于瀏覽器的特性,從設計角度應該遵循以下了兩點:
少用手勢,避免與瀏覽器手勢沖突。
減少頁面跳轉次數,盡量在當前頁面顯示。
(3)系統限制,平臺特性
由于Html5語言的技術特性,無法調用系統級別的權限。例如,系統級別的彈窗,系統級別的通知,地理信息,通訊錄,語音等等。且與系統的兼容性也會存在一些問題。以上限制通常導致APP的拓展性不強,體驗相對較差。具體案例:百度網頁地圖與百度APP地圖。
Web版地圖基于瀏覽器展現,因此,不能全屏顯示地圖,給用戶的眼界帶來局限感;相反,Native 版地圖以全屏展現的形式,很好的拓展了用戶的視野。整個界面干凈簡潔,首頁去除冗余功能。
Web 版地圖耗費的流量大于Native版,且不能預先緩存離線地圖。對于地理位置的判斷也是基于宿主瀏覽器,而非Web地圖本身。獲取路線后,對于更換到達方式,相對來說是不便利的。
相反,Native 版地圖,能夠直接訪問用戶的地理位置,能夠很清晰的為用戶展現App規劃的路線,并能輕松的查看多種路線方案,以便做出符合自己的最佳方案。對于切換公交,走路,自駕等路線方式也是只需一鍵操作。
Native 版地圖相對于 Web版地圖增加更多情感化,易用的功能,如:能夠記錄用戶的生活軌跡,記錄用戶的點滴足跡,能夠享受躲避擁堵方案等。而Web版地圖基于技術框架,很難實現以上功能,從用戶體驗角度來看,弱于Native版地圖。
2.Web APP設計要點
(1)簡化
簡化不重要的動畫/動效
簡化復雜的圖形文字樣式
(2)少用
少用手勢,避免與瀏覽器手勢沖突
少用彈窗
(3)減少
減少頁面內容
減少控件數量
減少頁面跳轉次數,盡量在當前頁面顯示
(4)增強
增強Loading時的趣味性
增強頁面主次關系
增強控件復用性
3.有效的WebAPP產品設計
有效的導航設計:基本的快捷導航中包括返回常用頁面(如首頁、我的等)的快捷方式
出現深層架構時,及時補充返回重要層級頁面的快捷方式。
情境式導航,方便用戶快捷跳轉到ta想去的頁面,如購買結束時提供查看訂單詳情的按鈕。
WebAPP更加需要畫頁面跳轉的流程圖,摸清各個頁面的入口,尤其是頁面返回的流程;有些簡化的返回按鈕,可以特殊注明返回到的頁面。