智能手機之普及不用多說,手機APP滲投到各個行業:電商(淘寶、京東等)、金融(各手機行業、P2P借貸等)、醫療(智慧醫療)、交通(滴滴、Uber等)、教育(慕課網等)、餐飲(餓了嗎、美團等)……反正只要是個企業,不管規模大小,都已經訂製或將要訂製本身的APP。這麼多APP無外乎就三種模式:Native App、Web App、Hybrid App。css
Native技術主要用於提供原生支持,要作到跨平臺,就須要掌握部分Android和iOS的知識,除了多線程,文件存儲等基礎知識,Android須要很是熟練的掌握WebView、WebSettings、WebChromeClient、WebClient四大對象。iOS須要很是熟練掌握UIWebView對象。html
Native App,原生APP,使用原生(即Android或iOS)開發的APP。html5
優勢:web
1,應用的性能好,體驗好,適配起來相對容易。在APP競爭如此白熱化的當下,體驗是決定APP「生死」的必要因素。讓用戶感受不爽了,只有一個下場,就是「卸載」,「卸載」,「卸載」。讓APP常駐用戶手機的夢想破滅。編程
2,技術成熟。瀏覽器
3,和原平生臺API無縫對接,打造優質體驗。安全
缺點:服務器
一、沒法跨平臺:Android和iOS都須要開發各自平臺的版本——開發成本高;微信
二、升級麻煩:每次升級都要下載安裝包,Android還好,反正不須要審覈,下載就下載吧,但iOS就麻煩了,發佈每一個版本還得通過App Store的審覈,這致使第三個問題;網絡
三、Android和iOS很難同步發佈。
4,成本高。
二、WebApp
所謂的Web App,就是把手機當作一個瀏覽器(Android使用WebView,iOS使用UIWebView),作幾個頁面掛在服務器端,相似於一個小網站。這樣說雖然不太貼切,但實際上給人的感受就是這樣的。雖然開發成本大大下降,但頁面訪問速度慢、操做體驗差。因而第三種模式誕生了。
HTML5技術的興起給Web App注入了新的生機。
Web App具備開發成本低、週期短、使用方便、維護簡單等特色。
隨着HTML5被過分熱炒和實際開發中遇到的性能以及體驗問題,WebApp逐漸勢弱。
一樣,以AppStore爲首的App分發平臺固然是不但願webapp破壞本身創建的生態系統的。
html5遲遲沒有得不到一個公認的標準,也阻礙着webapp的發展。可是這些都不足以阻礙webapp的發展。
如今APP的數量已經達到數以百萬計,實際上用戶根本不須要這麼多的App,不少App被用戶下載後,一個月都不會被打開一次。
而webapp用戶根本不須要安裝,只須要打開手機瀏覽器,輸入網址或搜索目標,點擊便可到達想要的網頁,基本和PC互聯網的思路是一致的,這也說明百度一樣在移動入口上有這很大的優點。在NativeApp上用戶只有安裝了App,才能瀏覽,而webapp是直接經過手機瀏覽器爲入口,或者推送的信息爲入口,這麼看webapp在流量上是有很大的優點的。
可是目前webapp得不到很好的發展主要有如下幾個方面的緣由:
一、無有效且普遍的webapp發行渠道(NativeApp有AppStore等);
二、webapp表現和體驗不佳(這點算硬傷吧);
三、適配難度(一套web很難兼容全部的手機,特別是國內某些自覺得很牛B的手機,大可樂算一個吧,哈哈);
四、配套的標準還沒有成熟(主要指html5吧)。
網站移動化是必然的,目前知道webapp比較好的解決方案有以下幾個:
一、雲適配 號稱引入一段神奇的代碼就能將PC網站移動化。陳本峯老師也是我學習的榜樣,html5佈道官。瞭解更多信息能夠連接到http://www.yunshipei.com/
二、百度site App 網址:http://siteapp.baidu.com/
三、還知道個作微站的網站,號稱把微信、微博入口都已打通,企業用戶營銷很好的平臺:http://www.weizhan360.com/
固然有實力的公司也有許多都有本身的移動團隊,從新開發一套本身的移動端網站。如:最近剛剛上市的58同城 http://m.58.com
這裏說的幾種解決方案,開發者也得根據本身的須要去選擇,仍是拿58同城舉例子,58同城不可能去雲適配,原本PC端的網頁就夠亂了,這也和58同城分類信息特徵有關係,若是雲適配,在手機端得不到很好的展現,只會更加的亂了。
技術:
一、 HTML5
熟練掌握HTML5的各個標籤,如何編寫最優的文檔結構。
二、 CSS
熟練掌握CSS2和CSS3的新特性,能按照效果圖編寫最高性能的樣式。
使用SCSS生成CSS,將CSS可編程化。
三、 JavaScript
實現業務邏輯控制。我的理解JavaScript主要包含兩大內容:DOM編程和麪向對象編程。大部分JS開發人員就只掌握DOM編程,諸如document.getElementById()等,但面向對象是很重要的一個方面。
四、 性能和開發
模塊化編程:編寫可複用的組建;
CSS渲染:瞭解瀏覽器的CSS渲染引擎才能編寫更高效率的樣式;
JS解析:瞭解瀏覽器的JS解析引擎才能優化JS腳本;
HTTP協議:熟練掌握HTTP請求的各個內容;
AJAX:和服務器端的交互大都採用AJAX。
三、HybridApp
Hybrid App發展示狀
目前中國70%以上的Native APP都已經混合了Web技術,例如淘寶、大衆點評、58同城、去哪兒等超級App都嵌入了大量的HTML5頁面,尤爲是內容頁面中體現。讓部分功能在WebView技術基礎上縮短開發週期、實現靈活業務調整。然而不少中小技術團隊嵌入的Html5部分,用戶體驗仍是比較差、功能比較弱。讓Native App開發團隊開發出體驗好和功能強的HTML5頁面並非簡單的事情。
究其緣由,Hybrid App的學習成本較高,須要同時掌握Native技術和Web技術,所以專業作Hybrid開發的程序猿並很少,學習資料天然也少,你們都是摸着石頭過河,一點一點的摸索屏幕適配、UI響應速度以及如何使Native語言與Web語言在同一產品中獲得很好的協調和配合。
開發一款高性能的Hybrid App,最終仍是要將兩種語言化爲一體,;例如APICloud的半翻譯式原理,將大量網頁代碼在運行時翻譯成可調用原生的API,如此一來既得到了Hybrid App的優點,又不會產生兩種語言協調不均形成的用戶體驗差的問題。Deep Engine強大的混合渲染引擎提供了更完善的性能體驗。聚合API中擁有衆多Native語言開發的功能模塊,在開發中調用Native API無疑更增長產品總體用戶體驗。
混合APP的將來:
移動應用的大勢已來,超級App即將誕生,此時不管是Native App仍是Web App都將不能知足人們對於移動應用的需求,對於企業來講是開發快、成本低;
對於用戶來講則是性能好、體驗佳。Hybrid App的需求必然猛增,而此時咱們應考慮的是如何將原有的App快速轉成Hybrid模式。
汽車有混合動力Hybrid,移動應用一樣也有混合模式。Hybrid App(混合模式移動應用)兼具「Native App良好用戶交互體驗的優點」和「Web App跨平臺開發的優點」。不少人不知道市場上一些主流移動應用都是基於Hybrid App的方式開發,好比國外有Facebook、國內有百度搜索等。但究竟什麼是Hybrid App?如何定義?
咱們來拆解一下里面的含義:
一、mobile application:Hybrid App就是一個移動應用
二、both browser-supported language and computer language:同時使用網頁語言與程序語言編寫
三、available through application distribution platforms:經過應用商店進行分發
四、a target device:區分目標平臺
五、install to run:用戶須要安裝使用
綜合一下就是:「Hybrid App同時使用網頁語言與程序語言開發,經過應用商店區分移動操做系統分發,用戶須要安裝使用的移動應用」。整體特性更接近Native App可是和Web App區別較大。只是由於同時使用了網頁語言編碼,因此開發成本和難度比Native App要小不少。所以說,Hybrid App兼具了Native App的全部優點,也兼具了Web App使用HTML5跨平臺開發低成本的優點。
Hybrid App的興起是現階段移動互聯網產業的一種偶然。移動互聯網的熱潮颳起後,衆多公司前赴後繼的進入。可是很快發現移動應用的開發人員太少,因此致使瘋狂的人才爭奪。市場機制下移動應用開發人才的待遇扶搖直上,最終變成衆多企業沒法負擔養一個具有跨平臺開發能力的專業移動應用開發團隊。而HTML5的出現讓Web App露出曙光,HTML5開發移動應用的跨平臺和廉價優點讓衆多想進入移動互聯網領域的公司開始心動。但是當下基於HTML5的Web App更是霧裏看花,在用戶入口習慣、分發渠道和應用體驗這三個核心問題沒解決以前,Web App也很可貴以爆發。正是在這樣是機緣巧合下,基於HTML5低成本跨平臺開發優點又兼具Native App特質的Hybrid App技術殺入混戰,而且很快吸引了衆人的目光。大幅的下降了移動應用的開發成本,能夠經過現有應用商店模式發行,在用戶桌面造成獨立入口等等這些,讓Hybrid App成爲解決移動應用開發困境不錯的選擇,也成爲現階段Web App的代言人。Hybrid App像刺客同樣,在Native App和Web App混戰之時,偶然間的在移動應用開發領域佔有了一席之地。
Hybrid App一般分爲三種類型:多View混合型,單View混合型,Web主體型。
多View混合型:(目前經常使用的方法)
即Native View和Web View獨立展現,交替出現。目前常見的Hybrid App是Native View與WebView交替的場景出現。這種應用混合邏輯相對簡單。即在須要的時候,將WebView當成一個獨立的View(Activity)運行起來,在WebView內完成相關的展現操做。這種移動應用主體一般是Native App,Web技術只是起到補充做用。
AppCan和Rexsee都屬於多View混合型,它們能夠在HTML5沒法勝任的時候採用Native View來進行補充。這種方式雖然對HTML5作了必定性的彌補,可是一個界面中HTML5可能沒法勝任的僅僅是其中一部分,卻要把整個界面所有推翻,從新使用Native來實現,對於開發成本是極高的,因此實際使用中,不少開發者可能由於各類因素,特別是成本上的考慮會對HTML5的弊端進行妥協。這形成多View的混合型框架在實際應用中跟Web主體型並沒有太大的差別。這也是爲何有的開發者願意選擇其餘框架而不選擇多View混合型框架的緣由,它的Native View有如雞肋般的存在,讓開發者無能爲力。
集成難度小。開發難度和Native App基本至關。
表明APP產品:支付寶,陸金所,搜易貸,,
單View混合型:(體驗與原始至關 )
即在同一個View內,同時包括Native View和Web View。互相之間是覆蓋(層疊)的關係。這種Hybrid App的開發成本較高,開發難度較大,可是體驗較好。如百度搜索爲表明的單View混合型移動應用,既能夠實現充分的靈活性,又能實現較好的用戶體驗。
表明APP產品:手機百度
Web主體型:(體驗較差)
即移動應用的主體是Web View,主要以網頁語言編寫,穿插Native功能的Hybrid App開發類型。這種類型開發的移動應用體驗相對而言存在缺陷,但總體開發難度大幅下降,而且基本能夠實現跨平臺。
Web主體型的移動應用用戶體驗的好壞,主要取決於底層中間件的交互與跨平臺的能力。
這種方式因爲太過偏重於HTML5,用戶體驗性相對比較差,甚至會受困於瀏覽器之爭。
從分析可見,Hybrid App中的Web主體型只要可以解決用戶體驗差的問題,就能夠變成最佳Hybrid App解決方案類型。AppCan在技術架構上和PhoneGap相似是Web主體型中間件,可是經過結合了一些原生交互效果可以達到iOS、Android平臺都比較一致的用戶體驗。此外,AppCan對引擎進行了獨特處理,在分辨率及移動端的適配上更加出色。也有一些廠商,採用翻譯的方式,將HTML標籤解析成Native進行展現,徹底受限於自身的解析能力,損失了HTML5技術的最大優點:靈活,在其基礎上開發的App在基因上就帶着適配性能差的硬傷。
AppCan的技術徹底可以匹配政府及500強企業的需求,目前包括東方航空、國家電網等大企業都在使用AppCan的技術完成移動信息化的解決方案。投入標杆技術的建設證實,AppCan能夠完成跨行業、跨領域的解決方案,那麼開發者一樣能夠利用AppCan技術,實現移動創業並得到收入。
而與單純提供移動開發能力的廠商相比,AppCan在應用管理及服務上也頗爲用心,已經打造出涵蓋開發工具、應用創新、技術培訓、運營推廣四大環節的AppCan.cn一站式移動開發服務平臺。移動互聯網的紅利近在眼前,創業機會轉瞬即逝,開發者惟有謹慎選擇適合本身的技術、平臺,纔有望在激烈的競爭中嶄露頭角。
國外的appMobi、PhoneGap國內的AppCan和Rexsee都屬於Web主體型移動應用中間件。其中Rexsee不支持跨平臺開發。appMobi和PhoneGap除基礎的底層能力更可能是經過插件(Plugins)擴展的機制實現Hybrid。而AppCan除了插件機制,還提供了大量的單View混合型的接口來完善和彌補Web主體型Hybrid App體驗差的問題,接近Native App的體驗。
表明APP產品:平安銀行APP。
多View混合型,單View混合型,Web主體型優劣勢對比
多View混合型 |
單View混合型 |
Web主體型 |
|
常見主體 |
Native |
Native |
Web |
開發成本 |
中 |
高 |
低 |
用戶體驗 |
良 |
優 |
差 |
從分析可見,Hybrid App中的Web主體型只要可以解決用戶體驗差的問題,就能夠變成最佳Hybrid App解決方案類型。
國內外Hybrid App的開發框架衆多。如何選擇又成爲一個難題。下面對開發者比較關心的集中知名跨平臺開發移動應用中間件進行列表和對比,以便選擇最適合您的移動應用中間件。
PhoneGap是相對比較早進入公衆視線的一種選擇。可是,開發者簡單的基於PhoneGap來開發移動應用確定會發現結果和Web App比較差的用戶體驗相似。這也是爲何基於PhoneGap有實用性的移動應用主要集中在iOS上。但是PhoneGap這種現狀弱化了HTML5的跨平臺價值。
AppCan在技術架構上和PhoneGap相似是Web主體型中間件,可是經過結合了一些原生交互效果可以達到iOS、Android平臺都比較一致的用戶體驗。可是相比PhoneGap的開源,AppCan相對封閉的路線顯得過於謹慎。
Titanium是一種基於翻譯機制的跨平臺中間件,可以開發出具備Native體驗的移動應用,可是由於翻譯機制的限制致使移動應用開發不能像真正的HTML5開發同樣靈活。哪怕一個按鈕也不能像普通HTML同樣來編寫,而必須按照Titanium約定的特定格式。
Hybrid App這個領域雖然還處於比較初期的階段,可是已經有不少優秀的公司和技術團隊在致力於跨平臺開發移動應用中間件技術的研究,給了開發者衆多選擇。開發者能夠根據實際的項目需求來選擇中間件。Web App雖被瀏覽器廠商和搜索引擎公司所推崇,但存在用戶體驗差、盈利模式不明確等現階段沒法解決的問題,或最終夭折。Hybrid App正在被愈來愈多的公司和開發者所認同,勢必會成爲新世界的王。
一些混合框架:
Cordova/PhoneGap:側重於JS與原生的交互,開發簡單,但性能差,如觸摸時反應不靈敏。
AppCan:性能還行,使用簡單,但要提交代碼給AppCan的服務器才能打包,相信有追求的企業是不會把本身的代碼提交給第三方,把打包權利交給第三方的。
Ionic Framework:在Cordova的基礎上增長一些UI/JS方面的東西,樣式還不錯,但一樣具備Cordova的不足。
MUI:缺點是工程大了,反應就遲鈍了,不能和原生API很好的契合。資料少。出了bug都不知道去哪裏找解決方法。
js UI 框架
jQuery Mobile:上手簡單,組件豐富,但性能超級差,閃屏現象嚴重。
Senche Touch:簡單看過,沒有使用過,貌似UI很漂亮,學習成本高。
React Native:FB推出的,當年FB是最先嚐試Hybrid的,但性能超差,因而APP放棄了Hybrid,走原生的道路。在你們都不看好H5時,FB暗中深刻挖掘H5,三年以後推出了這個框架,很是推薦各位去學習其中的思想。
GMU:百度推出的,這個不錯。
js庫:
這個就多了,jQuery、Zepto、Swiper、iScroll、RequireJS、AngularJS……
Hybrid App,這種既有跨平臺開發週期短、成本低的基因,又能發揮Native App體驗和性能的優點,HybridApp混合式移動應用開發逐漸成爲企業移動開發的首選。
Hybrid App一般是基於第三方跨平臺移動應用引擎框架進行開發,在國內開發者中比較知名的有PhoneGap、Titanium和AppCan這些引擎框架通常使用HTML5和Javascript做爲編程語言,調用引擎封裝的底層功能如照相機、傳感器、通信錄、二維碼等。
HTML5和Javascript只是做爲一種解析語言,真正調用的都是NativeApp同樣封裝的底層功能,這是和Web App的最大區別和不一樣。由於使用了瀏覽器技術,因此Hybrid App一般具備跨平臺的特性,而且開發成本和WebApp接近,開發效率也遠高於Native App。
說實在的,從表面上看的話,很難區分一個App究竟是Native App仍是Hybrid App,但實際上咱們更多的是把Hybrid App當作是Webapp的一部分,由於他是一部分Native(比較少),絕大部分的web頁面(html5頁面)。經過手機抓包工具Fiddler是能夠區分一個App究竟是Native App仍是Hybrid App的。Hybrid App和Native App同樣都是須要用戶在各類App分發渠道上下載並安裝到手機上才能用的。Hybrid App的體驗固然是沒話說,比較棒的,有這Native App的所有優勢。html5很好的解決了跨平臺性的問題,也解決了開發成本太高的問題。網上有估計到2016年50%+的App將是Hybrid App。譬如如今也有許多很少的表明做,如:fb、掌上百度、以及剛上市的58客戶端。
One Web more native 能夠很好的形容Hybrid App這種開發模式。
做爲一個有着1年多Hybrid App開發經驗的屌絲攻城師來講,在這裏想給Hybrid App這種開發模式潑一潑冷水,說一說開發過程當中他的不足之處吧。
首先,一套web兼容n個Native是一件很難的事情,尤爲是對一些App更新特別頻繁的公司來講,更是苦難。Hybrid App中的js、css等靜態資源的管理就是一個很頭疼的問題。譬如咱們1.0版本後,1.1版本html頁面有修改變更,js、css資源文件就會有變更,那麼咱們的這些資源就得兼容之前的版本,那之前的版本要不要去加載最新版本的資源文件呢?是採用同步加載仍是異步加載呢?資源加載的過程當中若是加載的資源有一部分失敗了呢?老版本的包升級更新到新版本資源下載原子性的問題?像這種靜態資源文件需不須要內置到客戶端裏面呢?
固然Hybrid App做爲一個新型的開發模式,誰也不能保證一開始就想清楚全部的事情,任何新興事物都得在發展過程當中,才能逐漸看清楚將來。
若是做爲是徹底新開發Hybrid App,關於資源問題可採用以下方案:首先,靜態資源必須內置到客戶端裏面,包括一些重要的靜態頁面。這樣能提升App的流暢性,在如今國內移動網絡這麼差的狀況下,讓用戶去下載幾十K的資源簡直是災難性的。資源都配置一個版本號,資源更新採用同步加載和異步加載並行,對於一些不影響用戶功能使用的資源採用異步加載的方式實現,第一次進入頁面的時候仍是使用老的資源,異步去加載資源,若是資源加載完成,第二次進入的時候就使用新的資源文件。若是缺乏了這個資源,功能有問題,或者樣式有問題,那這些資源就要同步加載,同步加載能夠放在啓動客戶端後加載或者加載進入頁面時同步加載。還一個比較難的問題是老版本包資源更新的時候更新資源的原子性,若是某些資源加載失敗了,要怎麼處理?個人想法是隻有資源徹底加載成功後纔將本地的版本號修改,標記爲成功,那些失敗的資源在進入引入改資源的頁面或者啓動客戶端的時候會被再次的加載。
乍一看和Web App沒啥差異,但涉及到的技術成本、開發成本、學習成本比Web App高,它綜合了Web App的開發速度和Native App的高性能體驗。之因此說學習成本高,是由於開發高性能的Hybrid App有難度,網絡資料少。我是兩年半前開始接觸混合模式開發的,當時如何作好屏幕適配、提升UI響應速度、如何最大化使用原生功能等內容,網絡幾乎沒有資料。網上能搜索到的都是很粗略的東西,或者就是Hello World級別的東西,涉及到稍微細節一點的東西幾乎沒有。因爲本系列文章都只講Hybrid,故在此再也不囉嗦了。
三種開發模式各自的特色以下面的表格所示:
|
Native App |
Hybrid App |
Web App |
原生功能體驗 |
優秀 |
接近優秀 |
差 |
性能 |
很是快 |
快 |
慢 |
跨平臺開發成本 |
昂貴 |
合理 |
便宜 |
碎片化適配 |
很是嚴重 |
嚴重 |
嚴重 |
編程技術支持 |
短缺 |
很是短缺 |
通用人才 |
版本升級維護 |
保守 |
低延時 |
開放 |
安全 |
強 |
中 |
弱
|
因爲移動端是一個重視性能和用戶體驗的終端,大量採用框架存在一些問題:
一、 擴展、維護、定製成本,這個很是須要考慮,或許框架提供的UI風格和本身設計的UI風格差別大,致使設計圍繞框架轉,不符合產品的需求。
二、 既然是框架,強調的是覆蓋面廣度和功能的全面,會有不少無用的東西,帶來累贅;
三、 框架自己存在BUG,或許須要開發人員面對一些能力以外的問題。
總之,若是隻追求像山寨做坊同樣快速產出、不計性能的開發產品,那使用現成的框架是不二選擇。但若是追求性能和真正的產品,建議使用庫,不要使用框架。可是不少框架的實現思想都很優秀,雖然不建議使用,但咱們應該多接觸學習其中的思想,才能寫更好的代碼。僅僅建議而已,不中聽請忽略。
總結:
筆者認爲,真正的Hybrid App框架並不侷限於PhoneGap、Appcan這樣的傳統開發框架那麼簡單,它既不是在HTML5的外表下套個殼,也不是HTML5和Native的各自爲政。
作爲一種開發模式,Hybrid App框架技術也在不斷變革,就像烽火星空的ExMobi那樣具有強大的Native佈局能力和HTML5的靈活展示能力,可以讓Native和HTML5能夠友好共存,並以標籤化的方式更方便開發者的隨意調用和擴展。選擇具備強大技術實力的Hybrid App框架對開發者提供的不只僅是便捷,而是一種先進的開發模式和思惟方式。
並且,在很多CIO看來,Hybrid App框架不只僅是提供開發上的能力,它只是總體的企業移動戰略中的一部分,應用的管理、設備的管理、應用不一樣層面的安全須要以及靈活的部署模式也都是企業移動戰略中的核心部分,若是開發者所有本身實現將是很大的工做量,因此選擇一個平臺型的Hybrid App框架是頗有必要的。烽火星空的ExMobi就是這樣的一個基於Hybrid App的移動應用平臺,它從開發(IDE環境)、集成(IT系統對接、雲服務)、打包(各個操做系統的應用打包)、發佈(應用的運行)、管理(日誌管理,更新管理)上提供了一套完整的移動化應用解決方案。因此,建議開發者根據本身的實際狀況,選擇合適的Hybrid App框架。