前端極致之美 - Hybird混合應用的前景
原文 http://www.cnblogs.com/aaronjs/p/4255232.html
群里經常有人@我，群主你的工作是干嘛? 然后我會不厭其煩的解釋Hybird混合應用、平臺開發、無編程快速開發！
這篇文章的本意也不是要吹捧Hybird有多么強大，只是用自己的項目闡述下對于前端開發一個更深層次的見解
我想大部分腦海中都是這個概念 ：javascript只是一個腳本語言，無非就是做做頁面的效果，驗證下表單、做做ajax的無刷新
那么接下來的內容將要顛覆你的認知，前端原來也可以這樣強大！
開始我們先了解下目前前端的二個大的方向定位：
- 傳統的web開發
- WebApp開發
傳統的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這些技術那么是無法操控跟系統相關的功能的，比如我想調節設備聲音，我想調用本地的文件等等，那么這時候出了一個新的解決方案 - Hybird混合應用
Hybird的典型代表就是PhoneGap開發框架，后來被土豪Adobe收購了，簡單的說PhoneGap在支持web app開發的同時還能通過它的手段：類似原生語言一樣調用其自己的系統接口，其實現也是很惡心的通過截取消息，大家可以百度查找相關資料
關于Web App與Native App的好壞這里不做討論，存在即使道理，Hybrid的存在總有它的價值，那么我們做的一件事就是：如何實現這個Hybrid技術的最大價值？
那么相比Native開發web App開發最大的優勢：快速！
布局可能是最頭疼的問題之一，移動設備的尺寸那真叫一個“豐富”，要兼容各種尺寸會搞的你焦頭爛額的。在PC端我們常用 的手段就是固定布局、彈性布局。但是在移動端我們可以使用更新的技術，響應式布局媒體查詢等等，但是根據我個人的經驗：外部采用自適應布局模式，在不同設 備上可以自行縮放，中等布局可以采用em rem, 具體的圖片可以采用px，但是在我項目中最終采用是計算縮放比，讓所有的元素按照絕對尺寸進行縮放布局
說著說著就會離開話題很遠了，那么web App的的缺點其實是比較明顯的，性能相對原生的的體驗會差，至于差多少要看應用的具體設計了。比如我就做一個翻頁的效果，這樣來說Native 與 Hybird是看不出區別的，但是如果是做一個植物打僵尸，這樣對比就比較明顯了，所以基于目前Hybird的發開還是有很大的局限性的，我記得早2年淘 寶的客戶端就是基于web app開發的，有一段時間在安卓上的體驗非常差
web App的開發快速便捷，但是性能比Native還是差強人意，在系統接口的調用上也很薄弱，不管是web App還是Native都不是什么新技術了，項目在選擇開發的時候都會有各種考慮，到底是短平快的快餐式發開，還是高大上的原生編寫，那么怎么才能平衡這 些優劣，就要看各自項目的取舍了
那么問題來了，web App如何才能最恰到好處的利用起來？
如果我們想通過一個產品引導一個產業我想目前是很難了，馬云的時代不是每個人都能抓住的。如果一個不行，那么十個百個千 個呢?我們做成一個系列產品形成的產業鏈？是否可以打通一個行業的缺口呢？這個未知，人生就是有了未知才會有精彩，正是因為這個未知才讓我們有了這個動力 去追逐這個夢想。
一個應用開發的成本是非常大了，耗時耗力，稍微復雜點的應用都要牽涉到幾個部門的協調，按照目前的的開發周期，我想一個 成型的應用從設計開發到檢測到上架，少說也要1個月吧，而且還是一個團隊合作之后的開發周期，基于這種開發成本考慮就算是通過web App開發的方式也不能達到產業鏈的效果。那么我們就會萌生一種新的想法，可不可以不寫代碼就能做應用了？基于這樣的設想我們的項目的原型就出來了，基于PhoneGap的無編程快速應用開發
這是目前公司幾個系列項目，都是基于無編程的實現，之前還有幾個項目不過已經流產了，就不提了
這里3個方向的項目都是屬于加殼，其實底層的東西都是同一個實現，只是在不同的項目中被各種不同的合理利用，之前我在慕課網上的介紹寫到，我有幾百個蘋果App Store的應用展現，還真不是呵呵，確實是有（這個鏈接里面進去看看）。那么這些應用其實都是HTML5+CSS3+JS實現的，就是現在比較火熱的Hybird混合應用
什么是無編程？
這是項目的的一個核心，不需要直接編程就能實現做出各種精美，復雜的應用，而且是幾乎跨是有平臺的，目前來說可以直接通過網頁在線看，也可以生成APK、IPA應用文件在移動端安裝，也可以在桌面通過exe加殼運行，反正就是實現的代碼只有一份，可以跑基于WebView的任意平臺。
如何實現無編程？
簡單的來說用戶可以通過一套軟件，可以把具體的抽象設計給控件化，有點類似.net的控件一樣，自動生成代碼。
如何實現跨平臺？
跨平臺很簡單就是通過web App技術就可以
其實最重要的2個方向我們已經確定了，那么我們怎么才能實現無編程快速應用開發？
我們只需要把用戶想要操作的的行為告訴前端代碼就就可以了，這里其實就是一個編程的傳遞了，傳統的開發都是我們開發者引導用戶行為，那么現在的的方式就是讓制作者引導，而不是開發者處理了，我們開發者要做的一個事件就是，如何讓編輯者的邏輯設計能夠最終實現
用戶的抽象行為是可以用數據描述的，我們可以把用戶的行為寫到數據庫里面，然后前端代碼通過讀取數據庫來獲取這個行為，正好HTML5的Web Sql Database就能完全勝任這個工作的，那么我們現在整的設計原型就出來了：通過PPT抽象用戶的設計寫入到數據庫，前端通過讀取數據庫還原用戶的設計
我們可以看看設計者的一個編輯界面，基于ppt 的
數據庫:
前端代碼
在線預覽的效果
項目復雜嗎？
因為我只是前端的實現，不涉及其他語言，只針對我個人的理解。
整個前端目前總代碼應該是超過了7萬行，業務架構方面的代碼應該有2萬5左右，SVN的更新記錄就架構這一部分是超過了1萬的更新量
實現的功能？
- 支持幾乎所有平臺
- 支持各種分辨率、橫豎模式自適應縮放
- 支持在線預覽
- 支持翻頁線性切換
- 支持非線性的直接切換
- 支持頁面跳轉
- 支持DOM與Canvas模式的獨立與共存
- 支持14中事件編程與手勢交互
- 支持上百種動畫組合
- 支持視頻與音頻
- 支持路勁動畫
- 支持css3 canvas的精靈動畫
- 支持多層的視覺差效果
- 支持svg無損縮放
- 支持底層接口調用
- 支持腳本代碼注入
- 支持用戶自定義編程
- 還有什么不記得了懶得寫了。。。
這樣的前端項目，設計與實現上會涉及多少問題了？
關于設計
移動端的問題太多了，這么多年核心的架構重構了不下8次，我也累積了一堆的優化經驗
我們可是單頁面模擬多頁面切換的，所以WebView只有一個，那么傳統的都是通過網頁跳轉切換，我們只能通過左右滑動切換頁面，那么意味著我們要模擬出多個頁面來，其實目前也有swipe這樣的插件，但是針對我們這樣的模式swipe只能說是弱爆了。
- 如果有一個應用有500頁，如果依次生成所有的頁面，會很卡，可能還會閃退
- 移動端通過Web Sql Database獲取數據，如果是通過sql查詢1條數據查詢要100毫秒的樣子，那么我們一個頁面有的數據量有時候大到了幾百上千，這樣的應用可想而已
- 把每一個模擬的頁面看作一個容器，那么容器里面其實是有很多很多不同的對象的，可以有視頻，可以有音頻，可以有精靈，可有有各種交互，那么這些對象要如何觸發，如何控制，如何銷毀？
- 在我們每一次翻頁的時候，其實都要涉及很多的問題，一個新的頁面載入，一個當前頁面的暫停，一個久頁面的銷毀，因為我是模擬，這需要控制不同頁面的生命周期
- 單頁面應用，內存管理是一個最大的問題，因為不退出就不會銷毀，所以越復雜的應用越要有一個好的架構
其實問題還有很多，這里就不一一列出了，我們通過phonegap打包的應用就有幾百個App Store單頁面應用系列，我們還有自己的應用平臺，秒秒學 - 交互式軟件培訓 是基于這種模式開發的一種新的教學體驗
關于優化
針對這種大型的應用最重要的一個點，就是性能，我們優化的原則就是二八定律，從最消耗的地方著手
分別有:
- 節點是生成與繪制
- 大數據的讀取
所以通過一次平鋪是行不通的了，因為我們一個應用，而不是一個頁面，我要當然應用來認知，一個應用內部都是對象。
所以我們采用了動態算法，每次根據進來的位置動態生成2-3頁，在滑動的時候全動態處理，那么我項目最大的一個優化點就是，采用動態算法模擬多線程模擬創建 + 細分任務顆粒度達到了最佳的優化目的，這個多線程不是傳統上的定時器那么簡單的
大數據的處理，其實最開始采用了空間換時間的方法，通過一次把數據庫的數據取出來放到內存中的緩存表中，這樣小數據量還行，大數據量的話應用幾乎直接閃退，緩存是需要內存的，而且就算是哈希表，如果上千條在移動端也會被拉下來，具體參考我之前寫過一篇文章 移動混合應用HTML5數據查詢優化
整個設計其實都是采用了分層結構，不同層處理管理自己的行為，這樣涉及復雜交互的時候，只需要調用各自封裝好的接口就可以了
每一個對象都是有生命的，所以就存在一個對象的管理，我們以頁面為單位，里面有幾十上百的對象，那么都需要控制管理，包括對象與對象之間的通訊與調用，這里我們會引入很多設計模式來處理
事件有二套，一套是基于用戶編輯的自定義綁定，另一套是框架底層提供，設想下，如果一個對象不綁定事件，在它上面有手勢移動就意味著不能翻頁了，所以不同的事件會有不同的優先級的處理方案，這里也是參考了jQuery的事件機制
在切換頁面的時候，就是一個非常復雜的邏輯了，因為是動態的就會涉及創建與銷毀。所以就需要有一個控制器來管理整個事件的流程，一個頁面創建，一個暫停，一個運行，一個銷毀，每一個頁面容器內部的對象都會有不同的動作處理
除此之外，我們還有一大堆插件，動畫都可以選擇最佳的實現，包括iframe、widget、svg、canvas、webgL這些都會有對應的適配器去自動選擇
當然還有很多很多設計上的優化這里就不一一列舉了，項目最復雜的地方，我覺得就是把邏輯完全交給了編輯者了，那么我就需要在各種不同的情況下根據數據分析出設計的的意圖，并實現
結尾
可能有大部分人會看天書一樣，不知所然，畢竟這個確實都是跟實際的項目經驗有關系的，如果遇到了，可以參考
這個項目我架構這邊的需求就不下200個，其實前端的架構水還是很深的，我也從來不說自己是一個什么架構師之類的，我也只是一個普通的前端開發者，只是有一個好的項目讓我一步一步成長起來
好吧，寫到這里其實心中還有一股熱血涌上心頭，感覺這幾年自己還是做了點事情的，除了開發公司這個項目，博客上jquery源碼系列也完結了，慕課網上的教程也要完工了，明年也要開始寫一本自己的書，自己工作經歷的總結，希望對大家有幫助。