Tips:內容部分來源於網絡,未找到具體做者,請其見諒。前端
目前移動端信息呈現的載體大致分爲三類:Web App、Hybrid App、Native App。web
若是放在一年半之前,甚至是一年前,若是要作一個移動App,你們可能仍是會傾向於Native App,優點沒必要說了,無非是性能和用戶體驗。可是,隨着手機換機潮的到來,Android系統的更新換代在加快,Android 4.0以上系統在全球的分佈已經超過95%,手機硬件性能也有所提高,這些爲瀏覽器的渲染及腳本引擎的效率提供了基礎。所以,在App中增長對web技術的使用,不管是造成Hybrid App,仍是更純粹的Web App,都有了可用性的前提。瀏覽器
對於如今的移動開發者來講,可能Native App 已再也不是首選方案,硬件正在變好,選用最合適的技術方案,兼顧成本和可維護性成爲主要的考慮方向。緩存
對於Web App,HTML5 + CSS3 + JavaScript的三件武器幾乎一統天下。Zepto.js,jQuery等各類JS框架也獲得了快速的發展和應用,好比Zepto.js就一舉摒棄了對不少老瀏覽器的兼容,能夠比jQuery的部署體積更小,老牌的jQuery也在其2.X版本中果斷放棄了對IE六、七、8的支持,這些甩掉歷史包袱的舉動,正在加速技術發展,而AngularJS更是作到了極致。網絡
對於Hybrid App,PhoneGap自從轉給Apache基金會之後,已經完成了使命,換了一個Cordova的名稱,繼續接力。Cordova爲Native和Web打通了橋樑,使得JS腳本能夠訪問到設備的Native能力,經過這種結合,雙方發揮各自的優點,看上去是個不錯的選擇,也是當前階段可先的作法。並且這些Web部分能夠更靈活的進行更新,甚至以插件的方式供Native App管理,再結合對本地緩存的有效利用,其體驗不比Native差太多,是很好的架構方案。目前不少應用都採用了這種方案,固然是否使用Cordova另計。前端工程師
Hybrid App還有一種方案,就是由Facebook主導的React Native方案。該方案與Cordova不一樣,Cordova全是Web思惟,只是用JS橋接了一些設備特性。React的思路是用Web的思路寫界面,而不是用Native思路,但界面元素將被React框架轉化爲Native界面元素,從而達到最終的應用是Native化的目的。但該React Native框架目前還未發佈,從現有的信息來看,對Native控件的封裝會減小不少控件的接口,影響一些特殊功能的實現,另外仍然須要針對iOS、Android等不一樣平臺進行開發,平臺知識必不可少,對開發人員也是個挑戰。架構
Hybrid App,是一種開發模式,兼顧Web和Native的一種開發模式。有人說它把Web App扼殺在搖籃裏,有人說它把Native App引向一個新階段。我說,它是一把雙刃劍,千萬別闖進它的誤區。本文是筆者在實踐Hybrid App開發模式過程當中總結出的一些經驗教訓,供讀者參考。Hybrid App雖好,可萬萬不能倉促選擇,盲目運用。 app
智能手機日益普及,移動互聯網亂戰日趨白熱化,開發一個應用早就不是技術圈熱議的話題,iOS和Android上的App已經成了每一個互聯網產品的標配。「惟快不破」也是中被移動互聯網人尊爲鐵律,快速迭代,高效開發,低成本上線是每個App開發團隊追求的目標。框架
同時,隨着HTML 5的不斷升溫和智能手機硬件性能的提升,Hybrid App的概念應運而生。這種「Native搭臺,HTML 5唱戲」的Hybrid App開發模式一時間受到各個開發團隊追捧,快速進入了大量開發團隊,成爲主流開發模式。 性能
上面已經能夠看出,現階段Hybrid App開發模式已經有了無限寬廣的前景,它的好處自不用說(Web前端工程師0成本介入,不依賴版本的實時更新,快速實現跨平臺需求,等等)。而另外一個方面,2012年Hybrid App的踐行者Facebook決定大量棄用App中的HTML頁面,轉向更加Native化的方案。Facebook的這一舉措也給Hybrid App方案的敲響了警鐘,這彷佛並非一個完美的方案。下面主要談談使用時要注意些什麼。
不能爲了HTML5而Hybrid App
HTML 5在Hybrid App模式中是一個最常被提起的概念。HTML 5做爲一個HTML 4.0.1和XHTML 1.0的升級版,基於舊版本有更強大的表現功能,並加入了Local Storage等技術,確實爲Web頁面提供了更大的想象空間和更多的可能性。但HTML 5處在目前的發展階段,受到瀏覽器兼容性和手機硬件性能水平的影響,它所能提供的功能與Native仍然有很大差距。
因此,我認爲做爲工程師要明確一款App採用Hybrid App模式的根本緣由是什麼。做爲一款App其最根本的功能是知足使用者的需求,而並非服務某項新技術。所以當決定採用Hybrid App去構建一款應用時,應該從應用自己功能特色和整個團隊的開發資源配比統一考慮,是否有必要同時又有能力去駕馭一款「Native搭臺,HTML唱戲」的Hybrid App。相似「HTML 5的時代已經到來,若是咱們不這麼作就變土鱉了,錯過這場技術革新的大潮,終將被這個時代所淘汰」的話真不是一個有責任心的工程師應該發出的聲音。
忽略關鍵因素
在談到 Hybrid App的場合咱們更多說起的是它有諸多優勢,如何架構一個Hybrid App,怎麼讓Web和Native和諧共處,然而Web開發中會被忽略的一些因素少被提起,這些因素又偏偏常常是一個Web頁面可否正常運行在App中的決定性因素。
Web開發是基於PC的一種開發模式,開發者使用PC瀏覽器模擬App中的Web View進行調試。PC瀏覽器與手機Web View的區別是巨大的,能支配的CPU資源,最大佔有的內存,運行的網絡環境,鼠標操做與觸控操做的區別,瀏覽器對CSS/JS的解析和對事件處理,等等。
App工程師,不管是iOS仍是Android,最敏感的一個問題莫過於內存管理,而在Web開發則對這個問題沒有過多注意。這就常常致使同一個功能界面 Native 實現中會經過一些技術手段,把內存容量控制在操做系統容許的範圍內保證App正常運行。若是以Web方式接入App的頁面沒有一個明確的標準和嚴格的驗收機制,相應的Web實現則不會過多考慮這方面的問題,並且瀏覽器也沒有給前端工程師提供足夠的Api支持處理內存問題,致使在某些條件下形成App沒法正常運行,甚至Crash。
一樣的問題會出如今網絡環境方面,雖然如今 wifi 覆蓋愈來愈廣,3G網絡也日益普及,但 App 運行的網絡環境與PC相比仍然有着巨大差距,wifi 和蜂窩網絡的切換,基站變化等諸多因素都會致使網絡間歇性斷開。Web 開發老是默認有一個穩定的網絡環境,所以在對於不穩定網絡環境問題的處理上也有所欠缺。沒有明確的對於低速網絡或不穩定網絡訪問的處理,在不少狀況下這些頁面也會很是不給面子。
富交互致使體驗差
這裏所謂的體驗問題一分爲二:一是與手機平臺默認交互習慣不一致的體驗,二是與一樣功能Native界面存在的體驗差距。
不管在Android仍是iOS平臺上,都有各自的一套交互習慣,包括視覺風格,界面切換,操做習慣等,與Web習慣徹底不一樣。若是使用Web方式開發富交互的頁面,或多頁面功能就會出現這樣的問題。
以iOS界面切換爲例,系統風格是新界面自右向左推入,後退時界面自左向右推出,而舊界面保持狀態。Web開發的默認習慣則是刷新頁面,不管新載入頁面或是後退,都會對頁面進行刷新。所以使用Web模式開發多界面功能就面臨這樣的交互習慣差別,形成體驗上的損失。固然Web方式也可模擬Native的交互方式,但這樣的模擬首先提升了開發成本,有悖於最初的高效原則,從效果上看,也很難達到Native的流暢性。
另外一個方面,也是上述提到的與Native相比,一樣的功能在性能上存在巨大差距。Web界面上JS對HTML Node的操做須要消耗大量的CPU資源,手機CPU的性能還不能與PC相提並論,就算在智能手機之間,硬件水準也良莠不齊,一個能夠在iPhone 5上流暢運行的界面,跑到三星S III上極可能就卡住不動了。因此咱們常常能夠發現一些富交互頁面上的操做沒法達到使人滿意的流暢度,而流暢度也正是用戶評價一款App優劣的最直觀因素。
跨平臺
一次開發,跨平臺運行是Web的優點,這也是不少App採用Hybrid模式的重要緣由之一。兼容性問題在Web開發過程當中每每不被關注,但當下智能手機的軟硬件版本衆多,兼容性絕對是一個不容忽視的問題。
以Android手機爲例,諸多主流品牌都有各自定製過的操做系統,瀏覽器內核對JS和CSS的解析,事件處理等方面都存在區別。以HTC One爲例重疊在一塊兒的層在某些狀況下會對點擊事件透傳,而其餘多數平臺則不存在這個問題。而且目前移動平臺的開發框架尚未徹底成熟,能夠很好的解決兼容性問題。因此就要求開發者在開發過程當中要對兼容性作充分測試,對於某些特殊版本進行特殊處理。
即便在相對統一的iOS平臺,不一樣版本之間也存在較大差別。例如:在iOS 4.x版本中CSS甚至不支持position fix的屬性,4英寸屏幕的設備沒法很好的支持apple-mobile-web-app-capable屬性,等等。
交互一致性
交互一致性是一個很是容易被誤讀的概念,「一致性」常常被理解爲同一個應用在各類平臺和場景下要有一致性的體驗。我認爲在移動平臺開發過程當中,「一致性」應該是App視覺和交互習慣與其運行平臺的習慣保持一致。而Web開發「一次開發,跨平臺運行」的特性與此存在必定程度上的衝突。
以「返回上一頁面」的操做爲例,在iOS平臺上在頁面頂部始終存在一個44像素高的導航欄,左側有一個返回按鈕用於返回操做,而Android平臺則習慣使用設備提供的返回鍵操做。這個返回按鈕在iOS平臺能夠經過絕對地址的方式鏈接到任何其餘頁面,而在Android平臺返回按鈕和設備的返回鍵則可能指向不一樣的位置。
例如這樣的一個流程:首頁->列表->篩選->刷新過的列表,此時的返回操做被指望是導向首頁,則頁面上的返回按鈕能夠經過絕對連接的方式實現,而Android設備的返回鍵則只能返回上一個篩選頁面,再次返回是篩選前的列表頁。
Hybrid App方案是一把雙刃劍,一方面它平衡了Native App和Web頁面的優缺點,必定程度上解決了Native App開發過程當中迭代慢,版本依賴,Native開發資源不足的問題,但另外一個方面過分依賴Hybrid方案會形成Web前端開發成本快速上升,甚至形成App總體體驗降低,甚至形成功能缺失。
不要爲了Hybrid而Hybrid,控制好方案中Native與Web的邊界。