榕樹下網站本身的技術人員並不多，所以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
1、zepto.js
用於基本DOM操作與ajax選擇使用定製的zepto.js，定製zepto.js的原因是我已經習慣了Deferred這種寫法
所以需要用到Deferred模組。具體定製方法請參考https://github.com/madrobby/zepto
2、artTemplate.js
用於模板的渲染，語法簡潔，效率高。https://github.com/aui/artTemplate
3、cloudary.js
整個專案的web端框架，為什麼叫cloudary，其實名字幾經更改，最後還是用了盛大文學的網站域名 www.cloudary.com.cn
至於為什麼是cloudary這個詞，好吧，誰知道當時是怎麼定的這個組合的英文詞的呢。。
它的作用：
- 封裝、橋接JS與Native的通訊，對業務層提供統一的操作介面
- 再次封裝zepto.js提供的的ajax方法，主要作用是可快取介面資料，進行統一的錯誤處理
- 框架層對頁面初始化完成後的業務處理
- 提供全域性的通用操作方法或介面，如：系統資訊，儲存操作等
4、每個頁面自身的業務邏輯直接寫在了頁面上，因為程式碼並不多
CSS
用sass編寫CSS
幾個月之前還為之寫了一個sass庫，叫sasshat，專案地址：https://github.com/willian12345/sasshat
應用sasshat後APP某些WEB介面實現的效果如：
下面這個是用web實現的動畫啟動頁
用了SASS後的好處：
- 編寫CSS更加快速
- 可適應頻繁的需求改動（—_—!）
- 更快速的純CSS實現酷炫動畫
- 更性感
該說說缺點了
1、載入速度慢
首次進入頁面更慢，頁面複雜度越高，需要的資源越多，載入資源慢，渲染DOM慢。
在移動端特別如此，隨著手機越低端，效能遞減越厲害
2、低端手機CSS3支援程度不一
有時候不得不放棄一些好用的CSS屬性，而改變另外的方案實現。因為某些Android2.X的手機真的很落後。
不得不為這些手機去掉一些效果或者專門判斷後用普通圖片代替效果
3、跨平臺很美
web確實是跨平臺的，但webview內的瀏覽器CSS相容比手機上瀏覽器內更不好。所以要實現全相容只是目標。
要花的時間與精力不比用Native少，所以為什麼不選擇用更合適的Native呢？
最後要說的
（APP現還未正式釋出。還在內測）
無圖無真像。
我在現在的公司還是喜歡用自己寫的東西。
雖然市面上有很多mobile端的web框架可用，但選擇哪一款，要不要用，還是要根據自身專案所處的環境：人力配製，技術水平，公司B格。
對於WEB開發人員來講，開發Hybrid形式的APP，還要取決於Native端開發者的水平或者對webview知識的熟悉程度。
對於一般技術人員來講，WEB不了Native,而Native也不瞭解web
======================================
轉載處請註明：部落格園(池中物,王二狗)willian12345@126.com