「榕樹下·那年」移動app ( hybrid ) 開發總結

 
 
榕樹下網站自己的技術人員並很少,因此app開發的任務就到了母公司盛大文學這邊。
 
 
 
盛大文學無線業務中心負責此次具體開發任務。
 
 
 
一如既往的,開發的狀況是:時間緊,任務重,人手少
 
 

技術選型


爲了同時上線Android和IOS平臺,因此選擇了hybrid這種Native與HTML5混合的方式。
 
Native的優勢是效率相對較高,但缺點是開發速度相對較慢,不利於自更新;
HTML5的優勢是開發速度快,能夠實現自更新,跨平臺,缺點也是顯而易見,效率不高,加載速度慢;
因此:
  • 用Native解決效率問題,主要用於切換界面的框架,圖片瀏覽器組件等
  • 用HTML5解決開發上的時間問題,主要用來實現頁面佈局、渲染
 
後臺服務端API提供統一的JSON數據格式,能夠供Native與HTML5無縫使用,服務端能夠再也不關心客戶端究竟是HTML仍是Native,HTML也能夠隨時改爲Native
 
 
客戶端與服務端通訊數據交換統一使用JSON,這樣一來若有須要Native能夠換成HTML5,或者HTML5能夠換成Native
 
 
 

Hybrid的HTML5部分


 

我負責的就是HTML5這一部分,其實就是WEB頁,外行如今一見到炫酷的微信頁面或其它效果的頁面就以爲這是HTML5..
好吧,就叫HTML5吧。
 

Javascript

一、zepto.js
用於基本DOM操做與ajax選擇使用定製的zepto.js,定製zepto.js的緣由是我已經習慣了Deferred這種寫法
因此須要用到Deferred模塊。具體定製方法請參考 https://github.com/madrobby/zepto
 
二、artTemplate.js
用於模板的渲染,語法簡潔,效率高。 https://github.com/aui/artTemplate
 
三、cloudary.js
整個項目的web端框架,爲何叫cloudary,其實名字幾經更改,最後仍是用了盛大文學的網站域名 www.cloudary.com.cn
至於爲何是cloudary這個詞,好吧,誰知道當時是怎麼定的這個組合的英文詞的呢。。
它的做用:
  • 封裝、橋接JS與Native的通訊,對業務層提供統一的操做接口
  • 再次封裝zepto.js提供的的ajax方法,主要做用是可緩存接口數據,進行統一的錯誤處理
  • 框架層對頁面初始化完成後的業務處理
  • 提供全局的通用操做方法或接口,如:系統信息,存儲操做等
 
四、每一個頁面自身的業務邏輯直接寫在了頁面上,由於代碼並很少
 

CSS

用sass編寫CSS
幾個月以前還爲之寫了一個sass庫,叫sasshat,項目地址: https://github.com/willian12345/sasshat
 
 
應用sasshat後APP某些WEB界面實現的效果如:
 
 
 
 
 
 
下面這個是用web實現的動畫啓動頁
 
 
 
用了SASS後的好處:
  • 編寫CSS更加快速
  • 可適應頻繁的需求改動(—_—!)
  • 更快速的純CSS實現酷炫動畫
  • 更性感
 
 
 

該說說缺點了


 

一、加載速度慢
首次進入頁面更慢,頁面複雜度越高,須要的資源越多,加載資源慢,渲染DOM慢。
在移動端特別如此,隨着手機越低端,性能遞減越厲害
 
二、低端手機CSS3支持程度不一
有時候不得不放棄一些好用的CSS屬性,而改變另外的方案實現。由於某些Android2.X的手機真的很落後。
不得不爲這些手機去掉一些效果或者專門判斷後用普通圖片代替效果
 
三、跨平臺很美
web確實是跨平臺的,但webview內的瀏覽器CSS兼容比手機上瀏覽器內更很差。因此要實現全兼容只是目標。
要花的時間與精力不比用Native少,因此爲何不選擇用更合適的Native呢?
 
 
 
 

最後要說的


 

(APP現還未正式發佈。還在內測)
無圖無真像。
 
 
我在如今的公司仍是喜歡用本身寫的東西。
雖然市面上有不少mobile端的web框架可用,但選擇哪一款,要不要用,仍是要根據自身項目所處的環境:人力配製,技術水平,公司B格。
 
對於WEB開發人員來說,開發Hybrid形式的APP,還要取決於Native端開發者的水平或者對webview知識的熟悉程度。
對於通常技術人員來說,WEB不了Native,而Native也不瞭解web
 
 
 
 
 
 
======================================
轉載處請註明:博客園(池中物,王二狗)willian12345@126.com
相關文章
相關標籤/搜索