Hybrid app 發展歷程

　　距離上一篇 《基於微信 js-sdk 的簡單應用》已經快一年了，說來真是慚愧。上次不久以後便換了工做，一直處於比較忙的狀態。其次後面酣暢一段時間都沒有從事移動相關的工做。直到今年3月份開始，臨時借調去支持其餘項目組又開始接觸到移動項目中去。

　　今天要講的仍是hybrid , 至於緣由，往往談到移動互聯網，談到hybrid ， 我老是欣喜的。猶記得2013年夏天，hybrid 概念纔剛剛興起不久，對移動互聯網毫無所知的我去參加了H5工程師的實習招聘；固然最終面試沒有經過，雖然在學校的項目經歷，對方很承認，然而對方主要業務方向即是移動互聯網；面試官認真的介紹了Native app, Web app 以及 Hybrid app 的區別和各自優缺點；瞬間點燃了我要去作移動開發的決心。

　　第一階段：誕生

　　因爲深受Native開發成本，迭代週期之痛和Web app 體驗之殤，hybrid 一誕生便廣受歡迎，迅速成名。然而當時的hybrid 大多的webview 之流 ， 所以 phonegap / cordova 幾乎只要聽過hybrid 的人都知道， JQuery , Extjs , 也紛紛推出了移動版本的 JQ Mobile , 和 Sencha Touch ,使得Hybrid 的開發成本迅速下降，而體驗有所提示。

　　第二階段：融合

　　webview爲主的Hybrid 解決了不少兼容性問題，提高了必定的用戶體驗。而後webview 在動畫上有着自然的缺陷，而且提供給H5使用的端能力很是有限；既然H5實現動畫很是卡頓，那爲什麼不把動畫交給Native , H5只負責每一個頁面中的內容。因而，一個SPA應用又被切成的多頁存在於多個webview容器中。web容器來負責頁面之間的切換效果，即便網絡終端，容器仍然能夠提供一些錯誤處理能力，不至於頁面總體白屏，而且不可操做。第二個端能力即是上次提到相似微信jssdk 的中間層了。更原始一點咱們也能夠直接和Native 協商一些 scheme 協議 和回調，來直接和native 通訊，然而這實際操做中會致使H5很難維護。 jssdk 其實是指一段本地化的js文件，也叫js-bridge, 即 native 和 h5 之間通訊的橋樑 。 bridge 對H5 暴露一些簡單和統一的 api ，使得h5 和 Native  之間的通訊變得很是簡單。

 

　　第三階段：離線

　　移動場景和PC 一個很大的不一樣即是網絡環境，PC場景下大可能是家庭寬帶，辦公環境等等，網速一般比較快。而移動端除了4g, 還有不少3g,2g網絡，網速成爲用戶體驗一個很大的瓶頸；離線化正式爲了解決資源加載問題。經過資源離線化，能夠解決首頁白屏，等一系列因資源加載慢致使的用戶體驗問題，離線化以後對NA的要求會提升，資源包緩存更新策略，網絡請求，設備，位置信息等，H5 對native 的依賴會更加明顯，相對H5部分的開發則實際變得更加簡單。附上糯米組件化平臺化演進之路

　　第四階段：React Native

　　react 和 react native 的出現甚至比Hybrid 的出現更使人驚喜和興奮。不只僅是新的庫和工具的升級，而是開發思路和理念的升級。虛擬dom ; Learn once, write anywhere 等。都讓人眼前一亮。這個階段在手淘和其餘一些公司也都有在使用了，我廠native 團隊也在積極研究react native 的runtime , 爭取早入集成到現有的app 當中；react native 的不一樣在於，徹底脫離的webview 的方式, 以一種全新的方式來讓前端工程師能夠快速寫出可比native體驗的 app 。

 

　　這僅僅是我從一個前端工程師角度所看到的hybrid這些年的一些變化，正如 Hybrid 是native + webapp 的混合產物，hybrid的發展，不只僅是前端工程師的推進，更須要native 工程師支持。如何讓那個咱們的Hybrid應用能快速拆解組合，也是native 和 前端共同去作的事情。就如今來說，手淘，糯米，手百，這些大流量app ,都在朝着平臺化的方向發展，可以快速接入H5 應用，並提供相應能力；而對於H5應用，也可能同時接入到手百 和糯米的平臺當中；平臺須要保證高度的擴展性來知足不一樣H5的需求 ， 而H5則須要最大化的下降本身在不一樣組件平臺中的遷移成本。 native 和 H5 則變成了容器與內容的關係。