前言
簡單的聊一聊我開發了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或HTML5、CSS3、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的無編程快速應用開發
這是目前公司幾個系列項目，都是基於無編程的實現，之前還有幾個項目不過已經流產了，就不提了
這里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