APP三種開發模式--之--HybridApp解決方案
原文:http://www.cnblogs.com/yeahui/p/5026587.html
1.1. APP三種開發模式
智慧手機之普及不用多說,手機APP滲投到各個行業:電商(淘寶、京東等)、金融(各手機行業、P2P借貸等)、醫療(智慧醫療)、交通(滴滴、Uber等)、教育(慕課網等)、餐飲(餓了嗎、美團等)……反正只要是個企業,無論規模大小,都已經訂製或將要訂製自己的APP。這麼多APP無外乎就三種模式:Native App、Web App、Hybrid App。
1.1.1. Native App
Native App,原生APP,使用原生(即Android或iOS)開發的APP。兩年多以前這非常流行,到現在為止,原生開發人員數量眾多,一抓一大票,技術成熟,好多培訓機構都抱著老掉牙的API翻來覆去的講——尤其是Android。Sorry,說錯話了……使用原生開發有其優勢:應用的效能好,適配起來相對容易。學習成本要看人,個人覺得技術點不多,門檻相對稍高,但入門後學習起來就很輕鬆——網路資料實在是太多了。
但原生APP最頭疼的有三個問題:
1、無法跨平臺:Android和iOS都需要開發各自平臺的版本——開發成本高;
2、升級麻煩:每次升級都要下載安裝包,Android還好,反正不需要稽核,下載就下載吧,但iOS就麻煩了,釋出每個版本還得經過App Store的稽核,這導致第三個問題;
3、Android和iOS很難同步釋出。
1.1.2. Web App
所謂的Web App,就是把手機當做一個瀏覽器(Android使用WebView,iOS使用UIWebView),做幾個頁面掛在伺服器端,類似於一個小網站。這樣說雖然不太貼切,但實際上給人的感覺就是這樣的。雖然開發成本大大降低,但頁面訪問速度慢、操作體驗差。於是第三種模式誕生了。
1.1.3. Hybrid App
乍一看和Web App沒啥差別,但涉及到的技術成本、開發成本、學習成本比Web App高,它綜合了Web App的開發速度和Native App的高效能體驗。之所以說學習成本高,是因為開發高效能的Hybrid App有難度,網路資料少。我是兩年半前開始接觸混合模式開發的,當時如何做好螢幕適配、提高UI響應速度、如何最大化使用原生功能等內容,網路幾乎沒有資料。網上能搜尋到的都是很粗略的東西,或者就是Hello World級別的東西,涉及到稍微細節一點的東西幾乎沒有。由於本系列文章都只講Hybrid,故在此不再囉嗦了。
三種開發模式各自的特點如下面的表格所示:
Native App |
Hybrid App |
Web App |
|
原生功能體驗 |
優秀 |
接近優秀 |
差 |
效能 |
非常快 |
快 |
慢 |
跨平臺開發成本 |
昂貴 |
合理 |
便宜 |
碎片化適配 |
非常嚴重 |
嚴重 |
嚴重 |
程式設計技術支援 |
短缺 |
非常短缺 |
通用人才 |
版本升級維護 |
保守 |
低延時 |
開放 |
安全 |
強 |
中 |
弱 |
1.2. Hybrid App所需技術
Hybrid App由於需要保證執行效能與開發速度,需要如下技術支援,本系列博文均會按照Demo的開發順序依次描述本人的開發心得和教訓,希望能起到一個拋磚引玉的作用。
1.2.1. Native技術
Native技術主要用於提供原生支援,要做到跨平臺,就需要掌握部分Android和iOS的知識,除了多執行緒,檔案儲存等基礎知識,Android需要非常熟練的掌握WebView、WebSettings、WebChromeClient、WebClient四大物件。iOS需要非常熟練掌握UIWebView物件。
1.2.2. Web技術
1、 HTML5
熟練掌握Html5的各個標籤,如何編寫最優的文件結構。
2、 CSS
熟練掌握CSS2和CSS3的新特性,能按照效果圖編寫最高效能的樣式。
使用SCSS生成CSS,將CSS可程式設計化。
實現業務邏輯控制。個人理解JavaScript主要包含兩大內容:DOM程式設計和麵向物件程式設計。大部分JS開發人員就只掌握DOM程式設計,諸如document.getElementById()等,但面向物件是很重要的一個方面。
4、 效能和開發
模組化程式設計:編寫可複用的組建;
CSS渲染:瞭解瀏覽器的CSS渲染引擎才能編寫更高效率的樣式;
JS解析:瞭解瀏覽器的JS解析引擎才能優化JS指令碼;
HTTP協議:熟練掌握HTTP請求的各個內容;
AJAX:和伺服器端的互動大都採用AJAX。
1.3. 流行框架
1.3.1. Hybrid 框架
Cordova/PhoneGap:側重於JS與原生的互動,開發簡單,但效能差,如觸控時反應不靈敏。
AppCan:效能還行,使用簡單,但要提交程式碼給AppCan的伺服器才能打包,相信有追求的企業是不會把自己的程式碼提交給第三方,把打包權利交給第三方的。
Ionic Framework:在Cordova的基礎上增加一些UI/JS方面的東西,樣式還不錯,但同樣具有Cordova的不足。
1.3.2. UI/JS框架
jQuery Mobile:上手簡單,元件豐富,但效能超級差,閃屏現象嚴重。
Senche Touch:簡單看過,沒有使用過,貌似UI很漂亮,學習成本高。
React Native:FB推出的,當年FB是最早嘗試Hybrid的,但效能超差,於是APP放棄了Hybrid,走原生的道路。在大家都不看好H5時,FB暗中深入挖掘H5,三年之後推出了這個框架,非常推薦各位去學習其中的思想。
GMU:百度推出的,這個不錯。
1.3.3. UI/JS庫
這個就多了,jQuery、Zepto、Swiper、iScroll、RequireJS、AngularJS……
1.3.4. 個人建議
由於移動端是一個重視效能和使用者體驗的終端,大量採用框架存在一些問題:
1、 擴充套件、維護、定製成本,這個非常需要考慮,或許框架提供的UI風格和自己設計的UI風格差異大,導致設計圍繞框架轉,不符合產品的需求。
2、 既然是框架,強調的是覆蓋面廣度和功能的全面,會有很多無用的東西,帶來累贅;
3、 框架本身存在BUG,或許需要開發人員面對一些能力之外的問題。
總之,如果只追求像山寨作坊一樣快速產出、不計效能的開發產品,那使用現成的框架是不二選擇。但如果追求效能和真正的產品,建議使用庫,不要使用框架。但是很多框架的實現思想都很優秀,雖然不建議使用,但我們應該多接觸學習其中的思想,才能寫更好的程式碼。僅僅建議而已,不中聽請忽略。
1.4. 系列大綱
本系列博文將按照我近三年來開發Hybrid App過程中的體會進行編寫,以一個APP完整開發為線索,形成一套完整的混合模式開發的解決方案。
1、 JS和原生互動架構
2、 WEB端基礎知識準備
3、 UI適配方案
4、 UI元件開發及封裝
5、 JS模組化開發
6、 升級、部署方案