Hybrid App技術批量製做APP應用與跨平臺解決方案

前言

簡單的聊一聊我開發了4年之久的Hybrid App(混合模式移動應用)平臺開發，目前一直在持續開發與維護，支持無編程快速開發！

其本意也不是要吹捧前端有多麼強大，只是用本身的實際項目闡述下對於前端開發一個更深層次的看法

PS：這不是單一的APP應用，這是一個能夠快速批量製做app的一套跨平臺解決方案

由於我常常在家同步更新，因此在git上放了一份，並不是開源，僅參考學習，請勿亂傳播，謝謝配合（固然，沒有API，沒有文檔，估計ES6看起來也夠嗆）呵呵

 

定位

開始咱們先了解下目前前端的三個大的方向定位：

• 傳統的web方向
• webApp方向
• nodejs方向(這裏不討論)

傳統的web開發就不提了，前端開發者都是從這個過程走過來的。隨着移動端的迅猛發展，近幾年前端這個職業也被抄的火熱，移動web的兼容早期估計也是蛋碎了一批人了，我也是深受其害，還好電子產品更新換代的速度挺快的。因此不論是PC仍是移動端，web頁面至始至終都是經過瀏覽器打開的，那麼這樣的開發來講咱們仍是的能夠籠統的定義爲傳統的web開發者

自從Iphone和Android這兩個牛逼的手機操做系統發佈以來，在互聯網界今後就多了一個新的名詞-Web App(意爲基於WEB形式的應用程序)。咱們在iOS上開發APP，須要經過Objective-C那樣精細複雜的語言去開發，這對廣大的開發者而言是個不小的難題。值得慶幸的是，開發者們也能夠經過開發Web APP來達到曲線救國的目的。也就是說，能夠經過HTML、 CSS或者JavaScript來進行Web APP的開發。其實Web APP說白了就是一個針對Iphone、Android優化後的web站點，它使用的技術無非就是HTML或HTML五、CSS三、JavaScript，服務端技術JAVA、PHP、ASP，可是web APP的開發仍是有一個的根本問題，由於底層畢竟仍是html css js這些技術那麼是沒法操控跟系統相關的功能的，好比我想調節設備聲音，我想調用本地的文件等等，那麼這時候出了一個新的解決方案  - Hybrid App(混合模式移動應用)

Hybird的典型表明就是PhoneGap開發框架，後來被土豪Adobe收購了，簡單的說PhoneGap在支持web app開發的同時還能經過它的手段：相似原生語言同樣調用其本身的系統接口，其實現也是很噁心的經過截取消息，你們能夠百度查找相關資料

關於Web App與Native App的好壞這裏不作討論，存在即便道理，Hybrid的存在總有它的價值

 

web App優點

那麼相比Native開發web App開發最大的優點：快速！

佈局多是最頭疼的問題之一，移動設備的尺寸那真叫一個「豐富」，要兼容各類尺寸會搞的你焦頭爛額的。在PC端咱們經常使用的手段就是固定佈局、彈性佈局。可是在移動端咱們可使用更新的技術，響應式佈局媒體查詢等等，可是根據我我的的經驗：外部採用自適應佈局模式，在不一樣設備上能夠自行縮放，中等佈局能夠採用em rem, 具體的圖片能夠採用px，可是在我項目中最終採用是計算縮放比，讓全部的元素按照絕對尺寸進行縮放佈局

說着說着就會離開話題很遠了，那麼web App的的缺點實際上是比較明顯的，性能相對原生的的體驗會差，至於差多少要看應用的具體設計了。好比我就作一個翻頁的效果，這樣來講Native 與Hybrid是看不出區別的，可是若是是作一個植物打殭屍，這樣對比就比較明顯了，因此基於目前Hybird的發開仍是有很大的侷限性的，我記得早2年淘寶的客戶端就是基於web app開發的，有一段時間在安卓上的體驗很是差

web App的開發快速便捷，可是性能比Native仍是差強人意，在系統接口的調用上也很薄弱，不論是web App仍是Native都不是什麼新技術了，項目在選擇開發的時候都會有各類考慮，究竟是短平快的快餐式發開，仍是高大上的原生編寫，那麼怎麼才能平衡這些優劣，就要看各自項目的取捨了

那麼問題來了，web App如何才能最恰到好處的利用起來？

 

無編程開發

若是咱們想經過一個產品引導一個產業我想目前是很難了，馬雲的時代不是每一個人都能抓住的。若是一個不行，那麼十個百個千個呢?咱們作成一個系列產品造成的產業鏈？是否能夠打通一個行業的缺口呢？這個未知，人生就是有了未知纔會有精彩，正是由於這個未知才讓咱們有了這個動力去追逐這個夢想。

一個應用開發的成本是很是大了，耗時耗力，稍微複雜點的應用都要牽涉到幾個部門的協調，按照目前的的開發週期，我想一個成型的應用從設計開發到檢測到上架，少說也要1個月吧，並且仍是一個團隊合做以後的開發週期，基於這種開發成本考慮就算是經過web App開發的方式也不能達到產業鏈的效果。那麼咱們就會萌生一種新的想法，可不能夠不寫代碼就能作應用了？基於這樣的設想咱們的項目的原型就出來了，基於PhoneGap的無編程快速應用開發

這是目前公司幾個系列項目，都是基於無編程的實現，以前還有幾個項目不過已經流產了，就不提了

• App單頁面應用系列        
• 秒秒學 - 交互式軟件培訓
• 讀酷兒童圖書館 - 兒童閱讀應用

這裏3個方向的項目都是屬於加殼，其實底層的東西都是同一個實現，只是在不一樣的項目中被各類不一樣的合理利用，以前我在慕課網上的介紹寫到，我有幾百個蘋果App Store的應用展示，還真不是呵呵，確實是有（這個連接裏面進去看看）。那麼這些應用其實都是HTML5+CSS3+JS實現的，就是如今比較火熱的Hybrid混合應用

 

什麼是無編程？

• 這是項目的的一個核心，不須要直接編程就能實現作出各類精美，複雜的應用，並且是幾乎跨是有平臺的
• 目前來講能夠直接經過網頁在線看，也能夠生成APK、IPA應用文件在移動端安裝，也能夠在桌面經過exe加殼運行
• 實現的代碼只有一份，能夠跑基於WebView的任意平臺。

 

如何實現無編程？

• 簡單的來講用戶能夠經過一套軟件，能夠把具體的抽象設計給控件化，有點相似.net的控件同樣，自動生成代碼。

 

如何實現跨平臺？

• 跨平臺很簡單就是經過web App技術就能夠

 

如何實現？

其實最重要的2個方向咱們已經肯定了，那麼咱們怎麼才能實現無編程快速應用開發？

• 咱們只須要把用戶想要操做的的行爲告訴前端代碼就就能夠了
• 這裏其實就是一個編程的傳遞了，傳統的開發都是咱們開發者引導用戶行爲，那麼如今的的方式就是讓製做者引導，而不是開發者處理了，咱們開發者要作的一個事件就是，如何讓編輯者的邏輯設計可以最終實現

• 用戶的抽象行爲是能夠用數據描述的，咱們能夠把用戶的行爲寫到數據庫裏面，而後前端代碼經過讀取數據庫來獲取這個行爲，正好HTML5的Web Sql Database就能徹底勝任這個工做的，那麼咱們如今整的設計原型就出來了：經過PPT抽象用戶的設計寫入到數據庫，前端經過讀取數據庫還原用戶的設計

 

咱們能夠看看設計者的一個編輯界面，基本office ppt 的擴展

ppt模版中多出了2個新的模塊

 

 

 

 

經過ppt把記錄用戶行爲並生成數據庫

 

 

前端經過讀取數據，經過H5+CSS3+JS這些技術來還原用戶的行爲

 

讀數據

 

根據數據處理，好比音頻（自動適配最合適的方法）

 

 

 

在線預覽的效果

 

---

項目複雜嗎

由於我只是前端的實現，不涉及其餘語言，只針對我我的的理解。

整個前端目前總代碼應該是超過了10萬行，業務架構方面的代碼應該有3-5萬行左右

 

SVN的更新記錄就架構這一部分是超過了1萬的更新量

 

 

 

實現的功能

• 支持幾乎全部支持CSS3的平臺
• 支持各類分辨率、橫豎模式自適應縮放
• 支持在線預覽
• 支持翻頁線性切換
• 支持非線性的直接切換
• 支持頁面跳轉
• 支持DOM與Canvas模式的獨立與共存
• 支持14中事件編程與手勢交互
• 支持上百種動畫組合
• 支持視頻與音頻
• 支持路勁動畫
• 支持css3 canvas的精靈動畫
• 支持多層的視覺差效果
• 支持svg無損縮放
• 支持底層接口調用
• 支持腳本代碼注入
• 支持用戶自定義編程
• 還有什麼不記得了懶得寫了。。。

 

 

你們關心的問題來了：這樣的前端項目，設計與實現上會涉及多少問題了？

我簡單說一句：真的複雜，由於把邏輯交給了用戶了，用戶給能夠一個對象上增長多個任意的事件、動做、動畫、音頻等等組合，每一個組合之間還能夠相互配合實現更多的動做動畫

 

關於設計

移動端的問題太多了，這麼多年核心的架構重構了不下8次，我也累積了一堆的優化經驗

咱們但是單頁面模擬多頁面切換的，因此WebView只有一個，那麼傳統的都是經過網頁跳轉切換，咱們只能經過左右滑動切換頁面，那麼意味着咱們要模擬出多個頁面來，其實目前也有swipe這樣的插件，可是針對咱們這樣的模式swipe只能說是弱爆了。

• 若是有一個應用有500頁，若是依次生成全部的頁面，會很卡，可能還會閃退
• 移動端經過Web Sql Database獲取數據，若是是經過sql查詢1條數據查詢要100毫秒的樣子，那麼咱們一個頁面有的數據量有時候大到了幾百上千，這樣的應用可想而已
• 把每個模擬的頁面看做一個容器，那麼容器裏面實際上是有不少不少不一樣的對象的，能夠有視頻，能夠有音頻，能夠有精靈，可有有各類交互，那麼這些對象要如何觸發，如何控制，如何銷燬？
• 在咱們每一次翻頁的時候，其實都要涉及不少的問題，一個新的頁面載入，一個當前頁面的暫停，一個久頁面的銷燬，由於我是模擬，這須要控制不一樣頁面的生命週期，每個活動對象的狀態控制
• 單頁面應用，內存管理是一個最大的問題，由於不退出就不會銷燬，因此越複雜的應用越要有一個好的架構

其實問題還有不少，這裏就不一一列出了，咱們經過phonegap打包的應用就有幾百個App Store單頁面應用系列，咱們還有本身的應用平臺appone、讀酷兒童圖書館，秒秒學 - 交互式軟件培訓 是基於這種模式開發的一種新的教學體驗

 

關於優化

針對這種大型的應用最重要的一個點，就是性能，咱們優化的原則就是二八定律，從最消耗的地方着手

分別有:

• 節點是生成與繪製
• 大數據的讀取

那麼我總結的優化與結構組織的方式有：

• 經過一次平鋪全部的內容頁是行不通的了，由於咱們一個應用，而不是一個頁面，我要已應用來認知，一個應用內部都是對象。
• 因此咱們採用了動態算法，每次根據進來的位置動態生成2-3頁，在滑動的時候全動態處理，那麼我項目最大的一個優化點就是，採用動態算法模擬多線程模擬建立 + 細分任務顆粒度達到了最佳的優化目的，這個多線程不是傳統上的定時器那麼簡單的
• 大數據的處理，其實最開始採用了空間換時間的方法，經過一次把數據庫的數據取出來放到內存中的緩存表中，這樣小數據量還行，大數據量的話應用幾乎直接閃退，緩存是須要內存的，並且就算是哈希表，若是上千條在移動端也會被拉下來，具體參考我以前寫過一篇文章 移動混合應用HTML5數據查詢優化
• 整個設計其實都是採用了分層結構，不一樣層處理管理本身的行爲，這樣涉及複雜交互的時候，只須要調用各自封裝好的接口就能夠了
• 每個對象都是有生命的，因此就存在一個對象的管理，咱們以頁面爲單位，裏面有幾十上百的對象，那麼都須要控制管理，包括對象與對象之間的通信與調用，這裏咱們會引入不少設計模式來處理
• 事件有二套，一套是基於用戶編輯的自定義綁定，另外一套是框架底層提供，設想下，若是一個對象不綁定事件，在它上面有手勢移動就意味着不能翻頁了，因此不一樣的事件會有不一樣的優先級的處理方案，這裏也是參考了jQuery的事件機制
• 在切換頁面的時候，就是一個很是複雜的邏輯了，由於是動態的就會涉及建立與銷燬。因此就須要有一個控制器來管理整個事件的流程，一個頁面建立，一個暫停，一個運行，一個銷燬，每個頁面容器內部的對象都會有不一樣的動做處理
• 除此以外，咱們還有一大堆插件，動畫均可以選擇最佳的實現，包括iframe、widget、svg、canvas、webgL這些都會有對應的適配器去自動選擇

固然還有不少不少設計上的優化這裏就不一一列舉了，項目最複雜的地方，我以爲就是把邏輯徹底交給了編輯者了，那麼我就須要在各類不一樣的狀況下根據數據分析出設計的的意圖，並實現

 

結尾

可能有大部分人會看天書同樣，不知所然，畢竟這個確實都是跟實際的項目經驗有關係的，若是遇到了，能夠參考

這個項目我架構這邊的需求就不下200個，其實前端的架構水仍是很深的

Integration of the latest technology point node/es6/gulp/webpack/rollup/eslint/karma and so on

• development: Based on ES6
• test: Based on the webpack+express+rollup+gulp build, there is a hot replacement function
• release: Based on gulp+rollup single file package
• test: Based on karma+mocha+chai